Git, работа с ветками

Справочник по командам Git для работы с ветками, приводится краткое описание команд. Даны основы коллективной работы над проектом

Общие принципы коллективной разработки в Git.

Будет справедливым заметить, что основной компонент эффективности Git это работа с ветками. Концепция веток позволяет эффективно работать командой разработчиков над проектом. Существует достаточно много сценариев коллективной разработки, важно понять принцип и создать или выбрать наиболее удобный. В большинстве случаев в Git работают следующим образом.

Во-первых, существует основная ветвь разработки, где содержатся оттестированные модули. Другими словами здесь находится отработанная и стабильная версия проекта.
Для дальнейшего развития разработки создается рабочая ветка, где код может быть сырой или незавершенный. Когда код рабочей ветки отработан и протестирован, его вливают из рабочей в основную ветку.
Отдельные ветки создаются для решения каких-либо локальных задач или разрешения проблем, после их выполнения, содержимое локальной ветки вливается в рабочую, а сама ветка удаляется.

Конечно, существует еще множество нюансов коллективной разработки. Например, каждый член команды при самостоятельной работе над своим «куском» проекта, чтобы не засорять основной репозиторий временными задачами, работает с локальным репозиторием и лишь закончив этот «кусок» вливает его в основной репозиторий. Как правило, сценарий совместной работы в Git диктуется спецификой проекта и поставленной задачей, вариантов море и они требуют отдельного разговора. Мы же перечислим команды для работы ветками.

Команды git для работы с ветками.

git branch – выводит список веток, текущая подсвечена символом * .

git branch имя_ветки – создает новую ветку, но не переходит на нее.

git checkout имя_ветки — переходит на указанную ветку.

Таким образом, чтобы создать новую ветку «имя_ветки» и перейти на нее, надо выполнить две команды:

git branch имя_ветки
git checkout имя_ветки

Эти две команды можно заменить одной, использовав параметр команды:

git checkout -b имя_ветки — создает ветку и переходит на нее.

Теперь можно работать над проектом в своей рабочей папке, Git при этом отслеживает новую ветку имя_ветки, куда вы перешли. Ваши коммиты будут отправляться на вновь созданную ветку. Таким образом, вы создали новую ветку разработки в локальном репозитории. Если есть необходимость отправить свои наработки из локальной новой ветки в удаленный репозиторий, выполните команду push:

git push origin имя_ветки

где origin — имя удаленного репозитория

Для того, добавить свои доработки, которые вы делали в отдельной ветке с основной, надо объединить ветки одну с другой. Например, доработки сделаны в ветке numb7, а основная ветка проекта dev. Для этого надо выполнить:

git checkout dev — перейти на ветку dev

git merge numb7 — выполнить команду слияния файлов из ветки numb7 в ветку dev

В результате создается новое состояние проекта, указатели веток master и numb7 будут указывать на это новое состояние. Вы при этом останетесь на текущей ветке, т.е dev. Если работ на ветке numb7 больше не предполагается и ничего интересного в ней нет, то ее можно удалить командой:

git branch -d имя_ветки — удаляет ветку в локальном репозитории.

Если после предыдущей команды выполнить

git push origin : имя_ветки

где origin – имя удаленного репозитория,

то будет удалена ветка «имя_ветки» в удаленном репозитории. Этой командой мы отправляем пустую ветку в удаленный репозиторий, в результате ветка «имя_ветки» затирается. Но нагляднее использовать команду удаления ветки в удаленном репозитории:

git push origin – – delete имя_ветки — удаление ветки имя_ветки в удаленном репозитории origin

Возможна ситуация, когда надо убрать ветку с тупиковой работой, которая просто не «пошла». Такую ветку обычной командой git branch -d имя_ветки Git не удалит, он бережет ваши наработки. Если вы уверены, что код не потребуется, то используйте команду

git branch -D имя_ветки — удаляет локальную ветку с не сохраненными изменениями.

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

Конфликты при слиянии веток.

При слиянии веток возможны конфликты, когда git не может самостоятельно и однозначно объединить ветки проекта. В этом случае слияние приостанавливается, новое состояние не создается, а выдается сообщение о конфликте, и Git предлагает вам самостоятельно устранить причину конфликта. При этом вы можете получить подобное сообщение:

CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result

Чтобы уточнить, где произошел конфликт, надо выполнить команду git status, которая укажет конфликтующие(unmerged) файлы. Кроме этого git добавляет в конфликтующие файлы специальные маркеры, которые помогут разобраться с причиной конфликта, например:

<<<<<<< HEAD:index.html

=======

>>>>>>> numb7:index.html

Все, что выше маркера ======= — это вариант файла из текущей ветки, все что ниже его — это вариант того же файла из сливаемой ветки. Как видно из приведенного примера, в конфликтующих файлах представлены разные версии одной и той же строки, поэтому git не может самостоятельно решить, какую строку выбрать. Надо вручную отредактировать строки, чтобы не было разных правок одной строки. Разобраться вполне возможно.
После устранения всех конфликтов надо выполнить команду индексирования для каждого конфликтующего файла:

Информация о ветках

Если проект большой, то не мудрено запутаться в ветках. Чтобы это не произошло чаще используйте такие команды:

git branch — выводит список веток репозитория.

git branch -v — показывает последний коммит по каждой ветке.

git branch – – no-merged — выводит ветки, которые не были слиты с другими.

git branch – – merged — выводит список слитых веток.

git remote show origin — отображает список веток в удаленном репозитории origin.