Уже были статьи про основы гита (0, 1, 2), были и статьи про внутреннее устройство репозитория. Сегодня поговорим, как простому смертному работать с гитом на автопилоте и не морочить себе голову.
Во-первых, шорткаты (в порядке убывания популярности):
alias gst='git-status'
alias ga='git-add'
alias gc='git-commit -m'
alias gp='git pull && git push'
alias gull='git pull'
alias gush='git push'
alias gb='git-branch'
alias gco='git-checkout'
alias gd='git-diff'
Во-вторых, отображение текущей ветки в командной строке:
Выглядит так:
(Как установить: ericgoodwin.com/2008/4/10/auto-completion-with-git)
Типичный поток работы в одной ветке
1) Что-то пописали, прогнали тесты
2) $ gst — увидели, какие файлы новые, какие обновленные.
3) $ ga a b c — добавили новые и обновленные файлы в индекс.
4) $ gc 'something is done' — записали коммит в репозиторий
5) Снова что-то написали, снова закоммитили.
6) $ gp — слили чужие изменения, залили свои изменения. Если вдруг возник конфликт, вам об этом напишут, будете мерджить.
Чтобы просто подтянуть обновления, набираем $ gull (git pull).
Локальные ветки
Принцип: одна фича — одна ветка. Один багфикс (если предполагается длиннее двух коммитов) — одна ветка. Один эксперимент — одна ветка. Одна фича внутри эксперимента — ветка от ветки. Ну, вы уловили идею.
Зачем оно нужно? Представьте, что вы начали день с фичи А, а к вам подошли и сказали, что нужно зафиксить Б. А через пять минут выяснилось, что для того, чтобы по-человечески зафиксить Б, нужно прикрутить и проверить Ц. Если каждую из этих задач держать в отдельных ветках, то голова не пойдет кругом, и работа не встанет поперек горла.
Набираем:
master ~/project $ gco -b my-feature
Получаем:
my-feature ~/project $
Список всех веток: $ gb
Переключиться на другую ветку: $ gco some-branch
Не забывайте, что вы всегда можете подлить какую-нибудь ветку в текущую с помощью git merge other-branch.
Жизненные ситуации с ветками
1) Исправление бага/добавление фичи. Делаем ветку, все тестируем, подливаем в нее master: gull && git merge master, снова тестируем, выходим в мастер (gco master), подливаем ветку (git merge my-branch), тестируем, заливаем мастер (gush) и удаляем ветку (gb -D my-branch).
2) Публикация ветки для совместной работы: gush origin my-branch:refs/heads/my-branch
Удаление ветки: gush origin :refs/heads/my-branch (внимание на пробел перед двоеточием)
3) Вы сидите в одной ветке и сделали что-то, что хотели бы закоммитить в другую ветку. Если вы еще не закоммитили, то делаем git reset HEAD для уже добавленных файлов (через ga/git-add), потом git-stash, выходим в нужную ветку, делаем git-stash apply и далее действуем так, как будто мы прямо тут все и меняли.
4) Вы сделали коммит в некоторую экспериментальную ветку, который имеет смысл залить в мастер, но git merge my-branch не подходит, потому что после этого коммита были еще несколько экспериментальных коммитов.
На этот случай есть git-cherry-pick. Вначале, посмотрите git-log и скопируйте номер нужного коммита. Далее, вы должны закоммитить все изменения в той ветке, в которую будете кидать выдернутый коммит. Затем, делаете git-cherry-pick и разруливаете конфликты, если возникли.
У меня такая ситуация была именно с добавлением коммита в мастер, поэтому после этих хирургических манипуляций мне нужно было подлить мастер в локальную ветку. Поскольку cherry-pick всего лишь применяет дифф (номер коммита становится другим), то ветка не знает, что внесенное изменение у нее уже есть, и не может нормально его смерджить. Поэтому, при мердже мастера в ветку вы гарантированно получите глупые конфликты а-ля «строчка АБВ конфликтует с АБВ».
Если кто-нибудь знает, как избежать конфликтов в такой ситуации (и сэкономить 5 минут времени), поделитесь опытом.
Скучные нравоучения напоследок
1) Коммиты должны быть мелкими. Дифф на пять экранов должен быть исключением, а не правилом.
2) На первых порах не морочьте себе голову с rebase и «чистотой» линии коммитов. Это беспокоит только последних эстетов или Линуса (который мерджит десяток веток в день). Читать git-log и игнорировать банальные merge commits нет никакой проблемы.
3) Читайте git-log после pull, ругайте своих коллег за невразумительные описания коммитов.
4) Изучите .git/config :-)
В следующий раз нужно написать пару слов о комфортной работе с git-submodule и git-svn.
Во-первых, шорткаты (в порядке убывания популярности):
alias gst='git-status'
alias ga='git-add'
alias gc='git-commit -m'
alias gp='git pull && git push'
alias gull='git pull'
alias gush='git push'
alias gb='git-branch'
alias gco='git-checkout'
alias gd='git-diff'
Во-вторых, отображение текущей ветки в командной строке:
export PS1='`__git_ps1 "%s"` \w \$ '
Выглядит так:
lazy-args-in-futures ~/Work/io/oleganza-io.git $
(Как установить: ericgoodwin.com/2008/4/10/auto-completion-with-git)
Типичный поток работы в одной ветке
1) Что-то пописали, прогнали тесты
2) $ gst — увидели, какие файлы новые, какие обновленные.
3) $ ga a b c — добавили новые и обновленные файлы в индекс.
4) $ gc 'something is done' — записали коммит в репозиторий
5) Снова что-то написали, снова закоммитили.
6) $ gp — слили чужие изменения, залили свои изменения. Если вдруг возник конфликт, вам об этом напишут, будете мерджить.
Чтобы просто подтянуть обновления, набираем $ gull (git pull).
Локальные ветки
Принцип: одна фича — одна ветка. Один багфикс (если предполагается длиннее двух коммитов) — одна ветка. Один эксперимент — одна ветка. Одна фича внутри эксперимента — ветка от ветки. Ну, вы уловили идею.
Зачем оно нужно? Представьте, что вы начали день с фичи А, а к вам подошли и сказали, что нужно зафиксить Б. А через пять минут выяснилось, что для того, чтобы по-человечески зафиксить Б, нужно прикрутить и проверить Ц. Если каждую из этих задач держать в отдельных ветках, то голова не пойдет кругом, и работа не встанет поперек горла.
Набираем:
master ~/project $ gco -b my-feature
Получаем:
my-feature ~/project $
Список всех веток: $ gb
Переключиться на другую ветку: $ gco some-branch
Не забывайте, что вы всегда можете подлить какую-нибудь ветку в текущую с помощью git merge other-branch.
Жизненные ситуации с ветками
1) Исправление бага/добавление фичи. Делаем ветку, все тестируем, подливаем в нее master: gull && git merge master, снова тестируем, выходим в мастер (gco master), подливаем ветку (git merge my-branch), тестируем, заливаем мастер (gush) и удаляем ветку (gb -D my-branch).
2) Публикация ветки для совместной работы: gush origin my-branch:refs/heads/my-branch
Удаление ветки: gush origin :refs/heads/my-branch (внимание на пробел перед двоеточием)
3) Вы сидите в одной ветке и сделали что-то, что хотели бы закоммитить в другую ветку. Если вы еще не закоммитили, то делаем git reset HEAD для уже добавленных файлов (через ga/git-add), потом git-stash, выходим в нужную ветку, делаем git-stash apply и далее действуем так, как будто мы прямо тут все и меняли.
4) Вы сделали коммит в некоторую экспериментальную ветку, который имеет смысл залить в мастер, но git merge my-branch не подходит, потому что после этого коммита были еще несколько экспериментальных коммитов.
На этот случай есть git-cherry-pick. Вначале, посмотрите git-log и скопируйте номер нужного коммита. Далее, вы должны закоммитить все изменения в той ветке, в которую будете кидать выдернутый коммит. Затем, делаете git-cherry-pick и разруливаете конфликты, если возникли.
У меня такая ситуация была именно с добавлением коммита в мастер, поэтому после этих хирургических манипуляций мне нужно было подлить мастер в локальную ветку. Поскольку cherry-pick всего лишь применяет дифф (номер коммита становится другим), то ветка не знает, что внесенное изменение у нее уже есть, и не может нормально его смерджить. Поэтому, при мердже мастера в ветку вы гарантированно получите глупые конфликты а-ля «строчка АБВ конфликтует с АБВ».
Если кто-нибудь знает, как избежать конфликтов в такой ситуации (и сэкономить 5 минут времени), поделитесь опытом.
Скучные нравоучения напоследок
1) Коммиты должны быть мелкими. Дифф на пять экранов должен быть исключением, а не правилом.
2) На первых порах не морочьте себе голову с rebase и «чистотой» линии коммитов. Это беспокоит только последних эстетов или Линуса (который мерджит десяток веток в день). Читать git-log и игнорировать банальные merge commits нет никакой проблемы.
3) Читайте git-log после pull, ругайте своих коллег за невразумительные описания коммитов.
4) Изучите .git/config :-)
В следующий раз нужно написать пару слов о комфортной работе с git-submodule и git-svn.
