Git как вести 2 ветки

Как работать с двумя ветками одновременно(гитхаб)?

Пример:я сделал форк проекта Ф. Получил задание А и сделал три коммита и пуша А1,А2 и А3. Потом получил задание В-нужно сделать коммиты и пушы на начальный Ф,допустим,В1,В2 и В3.Потом сделать ещё коммит и пуш А4.И в итоге предоставить два пул реквеста : 1)Ф->А1->А2->А3->А4 2)Ф->В1->В2->В3. Как это сделать ,если можно подробно : команда (что делает). Спасибо.

Отслеживать
задан 25 сен 2013 в 10:32
21 2 2 бронзовых знака

Ух. Мой вам совет, скачайте вот [эту][1] книгу и прочтите с 1 по 4 главу(для начала) [1]: s3.amazonaws.com/github/downloads/GArik/progit/progit.ru.pdf

25 сен 2013 в 11:21
Самый распространенный и самый бесполезный ответ,зачем он здесь?
25 сен 2013 в 11:29

Тяжелый случай, но если вы бы воспользовались моим советом, то, о ужас, обнаружили бы ответ на свой вопрос, а заодно и подтянули бы знания по работе с СКВ.(или просто могли воспользоваться поиском по PDF) Тут вам не школа(«неполный ответ» ха-ха-ха), @misha-nesterenko потратил свое личное время набрав этот ответ и никто ничем вам тут не обязан. При этом вы я явно некомпетентны в области IT (повидал уже таких мнимых «гениев»). Однако я надеюсь, что вы осилите 3 главу от первоисточника, а не будите дальше мучить людей своим неумением читать. Спасибо за внимание.

3.1 Ветвление в Git — О ветвлении в двух словах

Почти каждая система контроля версий в той или иной форме поддерживает ветвление. Используя ветвление, Вы отклоняетесь от основной линии разработки и продолжаете работу независимо от неё, не вмешиваясь в основную линию. Во многих системах контроля версий создание веток — это очень затратный процесс, часто требующий создания новой копии каталога с исходным кодом, что может занять много времени для большого проекта.

Некоторые люди, говоря о модели ветвления Git, называют её «киллер-фича», что выгодно выделяет Git на фоне остальных систем контроля версий. Что в ней такого особенного? Ветвление Git очень легковесно: операция создания ветки выполняется почти мгновенно, переключение между ветками туда-сюда, обычно, также быстро. В отличие от многих других систем контроля версий, Git поощряет процесс работы, при котором ветвление и слияние выполняется часто, даже по несколько раз в день. Понимание и владение этой функциональностью дает вам уникальный и мощный инструмент, который может полностью изменить привычный процесс разработки.

О ветвлении в двух словах

Для точного понимания механизма ветвлений, необходимо вернуться назад и изучить то, как Git хранит данные.

Как вы можете помнить из Что такое Git?, Git не хранит данные в виде последовательности изменений, он использует набор снимков (snapshot).

Когда вы делаете коммит, Git сохраняет его в виде объекта, который содержит указатель на снимок (snapshot) подготовленных данных. Этот объект так же содержит имя автора и email, сообщение и указатель на коммит или коммиты непосредственно предшествующие данному (его родителей): отсутствие родителя для первоначального коммита, один родитель для обычного коммита, и несколько родителей для результатов слияния двух и более веток.

Предположим, у вас есть каталог с тремя файлами и вы добавляете их все в индекс и создаёте коммит. Во время индексации вычисляется контрольная сумма каждого файла (SHA-1 как мы узнали из Что такое Git?), затем каждый файл сохраняется в репозиторий (Git называет такой файл блоб — большой бинарный объект), а контрольная сумма попадёт в индекс:

$ git add README test.rb LICENSE $ git commit -m 'Initial commit'

Когда вы создаёте коммит командой git commit , Git вычисляет контрольные суммы каждого подкаталога (в нашем случае, только основной каталог проекта) и сохраняет его в репозитории как объект дерева каталогов. Затем Git создаёт объект коммита с метаданными и указателем на основное дерево проекта для возможности воссоздать этот снимок в случае необходимости.

Ваш репозиторий Git теперь хранит пять объектов: три блоб объекта (по одному на каждый файл), объект дерева каталогов, содержащий список файлов и соответствующих им блобов, а так же объект коммита, содержащий метаданные и указатель на объект дерева каталогов.

Рисунок 9. Коммит и его дерево

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

Рисунок 10. Коммит и его родители

Ветка в Git — это простой перемещаемый указатель на один из таких коммитов. По умолчанию, имя основной ветки в Git — master . Как только вы начнёте создавать коммиты, ветка master будет всегда указывать на последний коммит. Каждый раз при создании коммита указатель ветки master будет передвигаться на следующий коммит автоматически.

Примечание

Ветка «master» в Git — это не какая-то особенная ветка. Она точно такая же, как и все остальные ветки. Она существует почти во всех репозиториях только лишь потому, что её создаёт команда git init , а большинство людей не меняют её название.

Рисунок 11. Ветка и история коммитов

Создание новой ветки

Что же на самом деле происходит при создании ветки? Всего лишь создаётся новый указатель для дальнейшего перемещения. Допустим вы хотите создать новую ветку с именем testing . Вы можете это сделать командой git branch :

$ git branch testing

В результате создаётся новый указатель на текущий коммит.

Рисунок 12. Две ветки указывают на одну и ту же последовательность коммитов

Как Git определяет, в какой ветке вы находитесь? Он хранит специальный указатель HEAD . Имейте ввиду, что в Git концепция HEAD значительно отличается от других систем контроля версий, которые вы могли использовать раньше (Subversion или CVS). В Git — это указатель на текущую локальную ветку. В нашем случае мы всё ещё находимся в ветке master . Команда git branch только создаёт новую ветку, но не переключает на неё.

Рисунок 13. HEAD указывает на ветку

Вы можете легко это увидеть при помощи простой команды git log , которая покажет вам куда указывают указатели веток. Эта опция называется —decorate .

$ git log --oneline --decorate f30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface 34ac2 Fix bug #1328 - stack overflow under certain conditions 98ca9 Initial commit

Здесь можно увидеть указывающие на коммит f30ab ветки: master и testing .

Переключение веток

Для переключения на существующую ветку выполните команду git checkout . Давайте переключимся на ветку testing :

$ git checkout testing

В результате указатель HEAD переместится на ветку testing .

Рисунок 14. HEAD указывает на текущую ветку

Какой в этом смысл? Давайте сделаем ещё один коммит:

$ vim test.rb $ git commit -a -m 'made a change'

Рисунок 15. Указатель на ветку HEAD переместился вперёд после коммита

Интересная ситуация: указатель на ветку testing переместился вперёд, а master указывает на тот же коммит, где вы были до переключения веток командой git checkout . Давайте переключимся назад на ветку master :

$ git checkout master

Примечание
git log не показывает все ветки по умолчанию

Если выполнить команду git log прямо сейчас, то в её выводе только что созданная ветка «testing» фигурировать не будет.

Ветка никуда не исчезла; просто Git не знает, что именно она вас интересует, и выводит наиболее полезную по его мнению информацию. Другими словами, по умолчанию git log отобразит историю коммитов только для текущей ветки.

Для просмотра истории коммитов другой ветки необходимо явно указать её имя: git log testing Чтобы посмотреть историю по всем веткам — выполните команду с дополнительным флагом: git log —all .

Рисунок 16. HEAD перемещается когда вы делаете checkout

Эта команда сделала две вещи: переместила указатель HEAD назад на ветку master и вернула файлы в рабочем каталоге в то состояние, на снимок которого указывает master . Это также означает, что все вносимые с этого момента изменения будут относиться к старой версии проекта. Другими словами, вы откатили все изменения ветки testing и можете продолжать в другом направлении.

Примечание
Переключение веток меняет файлы в рабочем каталоге

Важно запомнить, что при переключении веток в Git происходит изменение файлов в рабочем каталоге. Если вы переключаетесь на старую ветку, то рабочий каталог будет выглядеть так же, как выглядел на момент последнего коммита в ту ветку. Если Git по каким-то причинам не может этого сделать — он не позволит вам переключиться вообще.

Давайте сделаем ещё несколько изменений и создадим очередной коммит:

$ vim test.rb $ git commit -a -m 'made other changes'

Теперь история вашего проекта разошлась (см Разветвлённая история). Вы создали ветку и переключились на неё, поработали, а затем вернулись в основную ветку и поработали в ней. Эти изменения изолированы друг от друга: вы можете свободно переключаться туда и обратно, а когда понадобится — объединить их. И всё это делается простыми командами: branch , checkout и commit .

Рисунок 17. Разветвлённая история

Все описанные действия можно визуализировать с помощью команды git log . Для отображения истории коммитов, текущего положения указателей веток и истории ветвления выполните команду git log —oneline —decorate —graph —all .

$ git log --oneline --decorate --graph --all * c2b9e (HEAD, master) Made other changes | * 87ab2 (testing) Made a change |/ * f30ab Add feature #32 - ability to add new formats to the central interface * 34ac2 Fix bug #1328 - stack overflow under certain conditions * 98ca9 initial commit of my project

Ветка в Git — это простой файл, содержащий 40 символов контрольной суммы SHA-1 коммита, на который она указывает; поэтому операции с ветками являются дешёвыми с точки зрения потребления ресурсов или времени. Создание новой ветки в Git происходит так же быстро и просто как запись 41 байта в файл (40 знаков и перевод строки).

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

Давайте посмотрим, почему и вам имеет смысл делать так же.

Примечание
Одновременное создание новой ветки и переключение на неё

Как правило, при создании новой ветки вы хотите сразу на неё переключиться — это можно сделать используя команду git checkout -b .

Примечание

Начиная с Git версии 2.23, вы можете использовать git switch вместо git checkout , чтобы:

• Переключиться на существующую ветку: git switch testing-branch .
• Создать новую ветку и переключиться на неё: git switch -c new-branch . Флаг -c означает создание, но также можно использовать полный формат:` —create`.
• Вернуться к предыдущей извлечённой ветке: git switch — .

#4 — Работа с ветками. Объединение веток

Ветки в Git существуют для комфортной работы нескольких сотрудников над одним проектом. При помощи веток вы можете создавать ответвления от главного проекта и реализовать лишь нужный для вас функционал. В уроке вы познакомитесь с Git Branch и Git Merge (слияние веток).

Видеоурок

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

Каждая такая копия проекта называется веткой – она изолирована от других и имеет собственную историю.

Наличие веток позволяет обезопасить проект, сравнивать различные версии, вести параллельную разработку.

Создание ветки

Для создания ветки используется команда git branch name , где name это название ветки, которую вы хотите создать.

Чтобы перейти на ветку используйте команду git checkout name , где name это название ветки, на которую вы хотите перейти. Чтобы перейти на основную ветку пропишите слово «master».

Объединение веток

Для объединения веток используйте команду git merge name , где name это ветку, которую вы хотите присоединить к главной ветке.

Задание к уроку

Необходимо оформить подписку на проект, чтобы получить доступ ко всем домашним заданиям

Большое задание по курсу

Вам необходимо оформить подписку на сайте, чтобы иметь доступ ко всем большим заданиям. В задание входит методика решения, а также готовый проект с ответом к заданию.
PS: подобные задания доступны при подписке от 1 месяца

Git для начинающих. Урок 9.
Слияния или мерджи веток

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

Ветка master — еще раз

Мастер — это основная ветка проекта, в которую заливается только рабочий проверенный код. Новый функционал в конце концов оказывается в мастере. В этой ветке находится тот же самый код, что и на боевом сайте

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

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

Что такое мердж или слияние веток

Это перенос кода из одной ветки в другую. Например, когда мы заканчиваем работу над веткой, например, сделали новый функционал или поправили багу, мы сливаем ее в мастер. В мастере код проверяется еще раз и выкладывается на боевой сервер.

Сливать друг в друга можно любые ветки. Технически, с точки зрения git нет никакой разницы, сливается ветка с новым функционалом в мастер или наоборот. Для нас мастер — это основная ветка разработки, а для git это просто ветка.

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

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

Следует четко различать мердж своей ветки в мастер и мердж мастера в свою ветку.

Мердж ветки в мастер

Выполняется после завершения работы над своей веткой при помощи команды git merge. Чтобы вмерджить ветку в мастер, нужно сначала перейти в мастер, а затем выполнить git merge branch_name.

 $ git checkout master $ git merge news 

При этом возможны разные ситуации

Поговорим о них подробнее

Пока мы работали над веткой, в мастере не появилось новых коммитов

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

 $ git merge news Updating f32b91e..33ea897 Fast-forward index.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) $ git push origin master $ git branch -d news 

Git понимает, что это новый код, который можно просто положить поверх старого. Это простая ситуация и git не задает никаких вопросов.

Не забудьте сразу запушить изменения, чтобы их увидели коллеги, и удалить локальную ветку header, если она больше не нужна.

Теперь другая ситуация.

Пока мы работали над веткой, в мастере появились коммиты от коллег

Сначала переключаемся на мастер

 $ git checkout master Switched to branch 'master' Your branch is up-to-date with 'origin/master'. 

Почему «is up-to-date»? Потому что мы еще не сделали git pull. Делаем

 $ git pull --rebase origin master 

Мерджим свою ветку в мастер

 $ git merge news-styles 

И не забываем запушить изменения

 $ git push origin master 

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

Принципиально ничего не изменится, но лучше сначала сделать актуальной ветку мастер, а уже потом заливать свои изменения. А еще лучше держать актуальной свою ветку относительно мастера. Это значит, что стоит почаще подтягивать мастер в свою ветку. Таким образом мы в своей ветке будем работать с актуальным кодом и у нас меньше риска что-нибудь поломать. А если поломаем, то лучше чинить это в своей ветке, а не в мастере.

Как вмерджить мастер в свою ветку

Сначала идем в мастер, подтягиваем изменения с сервера, то есть делаем git pull. Затем переключаемся в свою ветку и делаем git merge master

 $ git checkout master $ git pull --rebase origin master $ git checkout news-redesign $ git merge master 

Затем проверяем, что ничего не поломалось и продолжаем работать.

Мердж коммиты

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

Посмотрим список коммитов и найдем мердж-коммит с хэшем 051f754

 $ git log --oneline 051f754 Merge branch 'news' . 

Посмотрим его содержимое

 $ git show 051f754 commit 051f75475cb1dca3cd08c1c7367a3308671ccf7b Merge: 0a3a6a3 2346be5 Author: Alexandr Shestakov Date: Sat Feb 8 14:10:39 2020 +0300 Merge branch 'news' 

То есть информация только о том, что в мастер была залита ветка news. Сами изменения в файлах, которые мы делали в ветке news, лежат в других коммитах.

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

Плюс в том, что у нас есть возможность выбора — git позволяет обходиться без таких коммитов вообще. Тогда история коммитов будет содержать только изменения в коде, а не операции с ветками. Это достигается механизмом ребейза, но это тема, которая выходит за рамки первой курса. Ребейз, его плюсы и минусы, мы подробно рассмотрим во второй части курса.

Также можете почитать мою старую статью — Отличия мерджа от ребейза.
В ней нет видеоурока, но наглядно объясняется на скриншотах.

Мерджи всегда проходят так гладко?

К сожалению, нет

В этом уроке мы намеренно упрощали ситуацию и рассматривали случаи, когда наши коллеги делают изменения в других участках кода. То есть мы с ними даже не пересекались. В реальной жизни так происходит не всегда. Иногда мы правим одни и те же участки кода и тогда при их слиянии git не может понять, чей вариант правильный. Это называется возникновения конфликта.

Подробнее о конфликтах и их разрешении мы поговорим в следующем уроке.

Что могу посоветовать

• Не забывайте, что мастер — это продакшен, это рабочая версия кода, которую не стоит ломать
• В мастер не сливается незаконченная работа, только полностью рабочий и проверенный функционал
• Перед мерджем своей ветки в мастер, подтягивайте изменения в мастер с сервера
• После мерджа в мастер, не забывайте пушить эти изменения
• Подтягивайте мастер в свою ветку почаще
• Мердж-коммиты несут информацию только о факте слияния веток. Договоритесь в команде, насколько они вам нужны
• Познакомьтесь с механизмом ребейза, он позволяет вести чистую историю без мердж-коммитов

Спасибо за внимание и до встречи!

Все уроки курса

• Вводный урок
• 1. Установка и базовая настройка git
• 2. Создание и клонирование репозитория git
• 3. Делаем первые изменения, git status и git diff
• 4. Коммиты и история коммитов, git commit, git log и git show
• 5. Подробнее об истории коммитов. Путешествие по истории
• 6. Работа с сервером, git push и git pull
• 7. Ветки — главная фишка git, git branch и git checkout
• 8. Работа с ветками на сервере, git fetch
• 9. Слияния или мерджи веток, git merge
• 10. Конфликты и их разрешение
• Платная часть курса. Презентация
• * 11. Работа с gitignore и git exclude
• * 12. Буфер обмена git, git stash
• * 13. Копирование коммитов, git cherry-pick
• * 14. Отмена и редактирование последнего коммита
• * 15. Отмена произвольного коммита, git revert
• 16. Склеивание коммитов, git rebase —interactive и git reflog
• * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
• * 18. Работа с git rebase. Отличия от merge
• * 19. Что такое git push —force и как с ним работать
• * 20. Ищем баги с помощью git, git bisect
• * 21. Как и зачем работать с тегами git
• * 22. Процессы: github flow и git flow
• * 23. Псевдонимы в git
• 24. Мердж-реквесты
• * 25. Форки