НЕ МОЛЧИ!!!    Сделай что-нибудь, чтобы остановить войну России в Украине.
...бойтесь людей равнодушных - именно с их молчаливого согласия происходят все самые ужасные преступления на свете.   ("Репортаж с петлёй на шее")

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

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

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

git_branch

Git позволяет достаточно просто и удобно работать командой над проектом. Существует достаточно сценариев коллективной разработки, важно понять принцип и создать или выбрать наиболее удобный.

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

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

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

git branch – выводит список веток, текущая подсвечена символом * .
git branch имя_ветки – создает новую ветку, но не переходит на нее.
git checkout имя_ветки — переходит на указанную ветку.
 

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

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

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

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

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

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

Для того, чтобы объединить ветки одну с другой, например, master и numb7, надо перейти на ветку master и выполнить команду

git merge numb7 — объединяет текущую ветку с веткой numb7.
 

В результате создается новое состояние проекта, а указатели веток master и numb7 будут указывать на это новое состояние. Вы при этом останетесь на текущей ветке, т.е master. Если работ на ветке 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 не может самостоятельно разрешить конфликт. Разобраться вполне возможно.
После устранения всех конфликтов надо выполнить команду индексирования для каждого конфликтующего файла: