Технический евангелист
53,6
рейтинг
6 февраля 2015 в 07:04

Разработка → Вышел git 2.3

Приветствую вас, коллеги! Сегодня утром гитхаб опубликовал подробную статью о свежевышедшой версии git. Забрать ее, как обычно, можно на официальном сайте, а под катом — краткий перевод что нового и интересного: push-to-deploy, ручное управление параметрами SSH, способ предотвратить зависание cron скриптов с клиентом git и многое другое.



Push to deploy



Возможность сконфигурировать удаленный репозиторий таким образом, что полученный push автоматически делает checkout (при условии что на этом компьютере не было локальных изменений, конечно же). Эта функция удобна для тестового и внутреннего deploy: не нужно устанавливать дополнительные скрипты, push на сервер автоматически меняет его файлы в рабочей копии, а не только добавляет их в репозиторий.

Авторы предупреждают, что использовать эту функциональность для deploy production серверов не рекомендуется, так как есть ряд побочных явлений:
  • Рядом с файлами рабочей копии будет директория .git, сокрытием которой от веб сервера нужно будет отдельно озаботиться.
  • Файлы рабочей копии обновятся не все сразу в рамках одной транзакции, а по одному, так что на короткий промежуток времени файлы сервера могут оказаться в неконсистентном состоянии.
  • Если после обновления файлов сервер требует сборки, то все равно нужно использовать скрипты.


Быстрое клонирование с учетом уже клонированного локального репозитория



Новый ключ --dissociate позволяет во время клонирования забирать нужные файлы из указанного с помощью --reference локального репозитория: это позволяет сильно сократить время клонирования и нагрузку на сеть, если копия нужного репозитория уже есть где-то на диске:

git clone --reference ../oldclone --dissociate https://github.com/gitster/git.git


Более консервативное поведение git push по умолчанию



Помните, в последнее время при пуше веток гит постоянно рекомендовал установить «push.default», намекая что скоро поведение по умолчанию поменяется? Оно поменялось. Теперь, если имя локальной ветки отличается от имени upstream ветки, то git откажется делать push без указания remote, чтобы защитить вас от push не в ту ветку:

git checkout -b experimental origin/master
git commit -a -m 'Experimental changes'
git push # Вот это теперь не сработает - разработчик явно хочет сделать push в 'experimental', а не в 'master'.


Параметры подключения к SSH теперь можно задать вручную



С помощью переменной окружения GIT_SSH_COMMAND теперь можно точно сконфигурировать как git будет использовать ssh. Наконец-то можно легко делать разные приватные ключи для разных репозиториев без модификации user-wide "~/.ssh/config":

GIT_SSH_COMMAND='ssh -i git_id' git clone host:repo.git


Возможность отключить ввод пользователя при автоматизации



Установив переменную окружения GIT_TERMINAL_PROMPT в 0 можно отключить ввод пользователя. Это полезно, когда git вызывается из скрипта автоматизации и ввод пользователя не подразумевается — теперь при ошибках авторизации git не будет запрашивать логин/пароль и тем самым подвешивать cron скрипт.

По мелочи


  • Уменьшена ненужная перезапись файлов при сheckout чтобы файлы рабочей копии поменьше находились в неконсистентном состоянии при push-to-deploy.
  • «git branch -d» (удаление ветки) и «git branch -m» (переименование ветки) теперь поддерживают ключ "--force".


Все



Если я что пропустил, неправильно понял или неправильно перевел — пишите.
Grigory Petrov @eyeofhell
карма
208,7
рейтинг 53,6
Технический евангелист
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (35)

  • +5
    Наконец-то можно легко делать разные приватные ключи для разных репозиториев:
    GIT_SSH_COMMAND='ssh -i git_id' git clone host:repo.git
    

    ИМХО, «старый» способ с ~/.ssh/config куда проще и удобнее.

    • +11
      Для end user — да. Для автоматизации — не очень. Если у нас есть скрипт который хочет сходить на несколько десятков репозиториев, то для этого скрипта менять user-wide конфигурацию всего ssh как-то не по феншую. Дописал это в новости, спасибо!
      • +1
        Как по мне, то ситуация надуманная: меняется не вся конфигурация, а только для конкретных репаков.
        С другой стороны, сделали штатную возможность и молодцы — помню как народ ради этого изголялся и писал свои врапперы.

        PS спасибо за новость и перевод.
    • 0
      Как .ssh/config поможет с двумя разными ключами на гитхабе/битбакете?
      • 0
        Элементарно. Хоть 2, хоть 100500.
        Вам пример нужен?
        • 0
          Нужен.

          Проект первый: git@bitbucket.org:foo/foo, используется key1
          Проект второй: git@bitbucket.org:bar/bar, используется key2

          Как такое задать через .ssh/config?
          • 0
            Вот пример.
            Если не осилите сами переделать под свои нужды, дайте знать.
            • 0
              С алиасами-то понятное дело, но это придется bitbicket.org в remote url поменять на алиас. Это неудобно при параллельном использовании написанных на Java IDE (JetBrains IDEA и подобных), которые не умеют читать .ssh/config. Можно прописать в /etc/hosts, конечно, но это совсем ужасный хак, да и IP-адрес Битбакета может измениться. Вариант с GIT_SSH_COMMAND удобнее и легко заворачивается в алиас.
              • +2
                Это неудобно при параллельном использовании написанных на Java IDE (JetBrains IDEA и подобных), которые не умеют читать .ssh/config.
                WAT?
                IntelliJ IDEA supports a standard method of using multiple ssh keys, by means of creating .ssh/config file.

                Вариант с GIT_SSH_COMMAND удобнее и легко заворачивается в алиас.
                Действительно: что может быть удобнее заворачивания алиаса в алиас.
                • 0
                  В моем старом сторме под osx не работает. Повод попробовать обновиться, да.
      • 0
        На сколько я помню в .ssh/config можно задать алиасы для конфигов.
        • 0
          Не совсем так, но в целом верно: алиасы задаются не конфигам, а хостам.
        • +2
          ~/.ssh/config:
          # GitHub 
          Host project1.github.com
              HostName github.com
              PreferredAuthentications publickey
              IdentityFile /path/to/key1
          
          Host project2.github.com
              HostName github.com
              PreferredAuthentications publickey
              IdentityFile /path/to/key2
          

          после этого достаточно либо сделать:
          git clone git@project1.github.com:repo1
          git clone git@project2.github.com:repo2
          

          либо поменять remote.url в .git/config для уже склонированных репо.
          • +1
            Так же можно использовать User чтобы для одного Host подхватывались разные ключи для разных юзеров.

            Host github.com
                User foo
                PreferredAuthentications publickey
                IdentityFile /path/to/key-foo
            
            Host github.com
                User bar
                PreferredAuthentications publickey
                IdentityFile /path/to/key-bar
            
            • +1
              Поправка, github.com выбран в качестве примера. Github просит логиниться всегда от пользователя git.
  • +2
    Жаль что Windows версия сильно отстает от своего апстрима.
    Ни то что 2.3, там даже 2.0 не пахнет (
    • +1
      Latest source Release
      2.3.0
      Release Notes (2015-02-05)
      Downloads for Windows

      Особенно обидно такое видеть на главной странице GIT.
      С радостью жмакаеш «скачать» и получаешь 1.9.5 :(
      • +6
        вот именно.
        даже главный контрибутор гита под винду msys-git не очень шевелится.
        не могу найти какие либо записки по поводу таких задержек разработки.
        хотя там чет советовали брать самому компилить — под виндой? увольте…
        • +2
          Они переделывает там всю внутреннею структуру насколько понял, из за этого к тому же меняется сайт и инсталятор. Они также долго переносили часть специально для Windows кода в основной репозиторий git'а чтобы упростить поддержку его.

          У них и новый web сайт git-for-windows.github.io. Вот milestone для первого релиза Git for Windows (теперь будет так называться вместо Msysgit)
  • +1
    Спасибо за новость! На Мак всё встало из исходников как надо!
    • +2
      brew же, зачем «из исходников»?
      • 0
        brew ставит только 2.2.2.
        • 0
          так сегодня/завтра обновится.
          • +1
            Для меня проще собирать самому. На вкус и цвет как говорится.
            • +1
              Дело ж хозяйское))
              Правда профита в этом (за исключением редких случаев) не вижу.
            • +4
              Вот и brew уже обновили))
          • 0
            Уже обновился.
  • +2
    Ну через хуки можно было и раньше настроить деплой после пуша, и более того, можно указывать внешнюю директорию, чтобы в корне не лежал .git.
    • +1
      Все верно, об этом написано: «не нужно устанавливать дополнительные скрипты». Функцональность в осносном для быстрых тестовых деплоев и внутренней автоматизации где не хочется плодить скрипты в больших количествах.
  • +1
    А кстати, что там сейчас с TortoiseGit (под виндой)? Раньше было все аналогично TortoiseSVN и TortoiseHg, а начиная с какого-то момента он перестал встраиваться в контекстное меню (или только у меня так?), зато сам git начал встраивать туда какие-то пункты…
  • 0
    Я правильно понимаю, что push to deploy — это возможность пуша в не-bare репозиторий?
    А git branch -d --force тоже самое, что и git branch -D раньше?
    • 0
      Я могу ошибаться, а разве были какие-то проблемы с push'ем в не-bare репозиторий? Насколько я помню, bare репозиторий нужен чтобы не хранить лишние файлы working copy на сервер где никто с этими файлами не работает. Или там какая-то еще механика?

      До 2.3 можно настроить варнинги и запретить пушить в текущую ветку не-bare репозитория с помощью "'receive.denyCurrentBranch" — чтобы не повредить незакомиченные изменения, так как поменяется HEAD.

      Да, --force делает то же самое что и -D, это написано в справке.
      • 0
        Ну да, точнее по-умолчанию он и запрещал пушить в бранч, «зачекаученный» в удаленном не-бэр репозитории.
        Я понял, прикольная фича получилась. Даже наверное не столько для деплоя, сколько для совместной работы — пушишь свои изменения коллеге прямо в репо, он их сразу использует (если у вас разные репозитории).
  • +1
    git clone --reference ../oldclone --dissociate https://github.com/gitster/git.git
    


    Киллер-фича для ядер линукса и многих других проектов-мамонтов.

    # Вот это теперь не сработает — разработчик явно хочет сделать push в 'experimental', а не в 'master'.
    git push


    Поставьте пожалуйста коммент на одной строчке с командой, чтобы точно определить «Вот это»
    • 0
      Готово, спасибо!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.