Git: Branches

Branch, или ветка одна из самых удобных и, соответственно, востребованных фич.

С помощью ветвления можно не только реализовать классическое деление на dev, staging и production, но и организовать командную работу.

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

Мы хотим внести изменения в данное решение, для этого мы создадим новую ветку командой git checkout -b dev и проверим результат командой git branch –list :

Screen Shot 2015-11-30 at 14.11.20

 

Обратите внимание, звёздочкой отмечена ветка в которой мы сейчас находимся, переключится на другую ветку можно командой git checkout :

Screen Shot 2015-11-30 at 14.16.42

 

Итак, вернёмся обратно в ветку dev и добавим к проекту ещё один файл:

Screen Shot 2015-11-30 at 14.24.24

 

Посмотрим содержимое dev ветки командой ls -la , переключимся в ветку master и убедимся что в ней файла devFile1.txt нету:

Screenshot at Nov 30 14-26-48

 

Синхронизируем нашу локальную ветку с “основным репозиторием” используя знакомую команду git push (комментарий по синтаксису – git push  <REMOTENAME> <LOCALBRANCHNAME>:<REMOTEBRANCHNAME>):

Screen Shot 2015-11-30 at 14.29.46

 

Проверим результат:

Screen Shot 2015-11-30 at 14.31.00

Screen Shot 2015-11-30 at 14.32.49

 

Предположим, наш эксперимент в ветке dev закончился удачно и теперь нам нужно распространить изменения на production который у нас в master ветке (в мастер, фактически, добавится файл devFile1.txt).

Для этого инициируем процесс, который называется branch merge.

Переключимся в ветку master и выполним git merge –no-ff dev (–no-ff необходимо для генерации merge commit, dev – указываем содержимое какой ветки будет сливать с master):

Screen Shot 2015-11-30 at 14.39.03

 

Убедимся что файл, который раньше был только в dev, сейчас уже и в master:

Screenshot at Nov 30 14-42-01

 

Разумеется, если файл уже был в master, затем был дополнен (изменён) в dev, затем dev был смерджен в master, то в master будет обновлённая версия файла.

 

Кроме того, можно посмотреть наглядную картинку в SourceTree:

Screen Shot 2015-11-30 at 14.43.03

 

Рассмотрим чуть более сложный, но более распространённый сценарий, когда наш проект передаётся после окончания разработки на тестирование (staging) и только потом в production (master).

Создадим ветку stg, добавим файл в ветку dev, сделаем merge dev в stg, проведём тестирование, и если все ок, то сделаем merge stg в master:

git checkout -b stg
git checkout dev
echo "devFile4 content" > devFile4.txt
git add devFile4.txt
git commit --message "Adding new file to dev branch"
git checkout stg
git merge --no-ff dev
git checkout master
git merge --no-ff stg
git push --all origin

Screen Shot 2015-11-30 at 15.33.14

Screen Shot 2015-11-30 at 15.36.14

 

Надеюсь из этого материала понятно, насколько ответственно нужно подходить к процессу merge веток.

К счастью используя BitBucket у администратора есть возможность настроить права доступа к веткам:

Screen Shot 2015-12-01 at 14.14.32

 

Оглавление цикла статей по Git.

Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.