Git, работа с ветками - WebDesignStudio1
Per aspera ad astra


Параметры поиска

Выбор рубрики
Поиск по


Сортировать


Порядок отображения



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

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

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

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

Конечно, существует еще множество нюансов коллективной разработки. Например, каждый член команды при самостоятельной работе над своим «куском» проекта, чтобы не засорять основной репозиторий временными задачами, работает с локальным репозиторием и лишь закончив этот «кусок» вливает его в основной репозиторий. Как правило, сценарий совместной работы в 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

Все, что выше маркера ======= — это вариант файла из текущей ветки, все что ниже его — это вариант того же файла из сливаемой ветки. Как видно из примера, содержимое тега