Skip to content

Instantly share code, notes, and snippets.

@Mehonoshin
Forked from dmexe/gist:1508019
Last active January 20, 2018 21:39
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Mehonoshin/9871192 to your computer and use it in GitHub Desktop.
Save Mehonoshin/9871192 to your computer and use it in GitHub Desktop.
Git workflow

После установки

Указываем свое имя и почту

git config --global user.name "Your Name Comes Here"
git config --global user.email you@yourdomain.example.com

Настраиваем себе shell чтобы показывал как минимум текущий бранч, а лучше ставим себе zsh и oh-my-zsh с гит плагином. Далее все примеры подразумевают что вы пользуетесь oh-my-zsh

Работа над тикетами

После получения тикета создаем под него бранч (в мастере никогда не работаем) с именем -<title>, например 22-messages или 73-votes

$ gco master 
$ gco -b 22-messages

После этого вы находитесь в копии master, всю работу делаем только в этом бранче. После того как сделали что то полезное, сохраняем это на сервере

$ gc -am "(#22) сделал фичу"
$ ggpush

Если ggpush выдал ошибку, скорее всего у вас устаревшая копия бранча (кто то другой сделал комиты), нужно забрать свежие изменения с сервера, забираем их и сохраняем изменения на сервере поторно

$ gup
$ ggpush

Синхронизация с master

Записываем себе где нибудь правило. По приходу на работу и перед тем как уйти с работы, а так же по завершении работы над тикетом, обязательно в своем рабочем бранче сделать:

$ gcm
$ gup
$ gco my_branch
$ g rebase master

и если будут конфликты - обязательно их поправить.

rebase master и конфликты

Сама операция git rebase нужна для поддержания рабочей ветки в актуальном состоянии. По мимо вас, обычно, над приложением работает еще несколько человек и если постоянно не синхронизироваться с master, за то время, пока будете работать над очередной фичей, в мастере накопится куча изменений. При попытке залить комиты из рабочего бранча, будет скорее всего очень много конфликтов, иногда придется тратить весь рабочий день на их разрешение (были прецеденты).

Во время git rebase могут возникнуть конфликты, git об этом напишет, исправлять это так:

получаем новые изменения с сервера:

$ gup

запустили rebase:

$ g rebase master

получили конфликт в файле

открываем в любимом редакторе файл, и ищем подобный текст

<<<<<<< HEAD
client
=======
upstream
>>>>>>> d918d23958841041e2f75b9cbfafc93e9a9a1321

из этого оставляем текст client или upstream, служебные метки удаляем, ищем в файле конфликты дальше и исправляем, если все поправили не забываем сохранить файл

выполняем команду:

$ ga filename_with_conflicts

продолжаем rebase командой:

$ g rebase --continue

получили конфликт в файле

...

и так пока оно не синхронизируется

После того как сделали синхронизацию master, обязательно выполняем:

$ ggpush --force-with-lease

При получении изменений с сервера командой gup, тоже могут возникнуть конфликты, исправлять так же:

$ gup
... конфликт
$ vim file_with_conflicts
... исправляем и сохраняем файл
$ ga file_with_conflicts
$ g rebase --continue
...
$ ggpush

Полезные команды

  • git stash - сохраняет не закомиченные изменения, для того что бы их применить нужно выполнить git stash apply
  • git diff - показывает незакомиченные изменения в файлах
  • git cherry branch1 branch2 -v - показывает отличия бранчей
  • git show - покажет изменения в последнем комите
  • git show commitId - покажет изменения в комите commitId
  • git push origin :branch1 - удаляет на сервере бранч branch1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment