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 — .
3.2 Ветвление в Git — Основы ветвления и слияния
Давайте рассмотрим простой пример рабочего процесса, который может быть полезен в вашем проекте. Ваша работа построена так:
- Вы работаете над сайтом.
- Вы создаете ветку для реализации новой функциональности в соответствии с пользовательской историей.
- Вы работаете в этой ветке.
В этот момент вы получаете сообщение, что обнаружена критическая ошибка, требующая скорейшего исправления. Ваши действия:
- Переключиться на основную ветку.
- Создать ветку для добавления исправления.
- После тестирования слить ветку, содержащую исправление, с основной веткой.
- Переключиться назад в ветку для реализации пользовательской истории и продолжить работать.
Основы ветвления
Предположим, вы работаете над проектом и уже имеете несколько коммитов.
Рисунок 18. Простая история коммитов
Вы выбрали задачу #53 из какая-там-у-вас-система-отслеживания-задач. Чтобы создать ветку и сразу переключиться на неё, можно выполнить команду git checkout с параметром -b :
$ git checkout -b iss53 Switched to a new branch "iss53"
Это то же самое, что и:
$ git branch iss53 $ git checkout iss53
Рисунок 19. Создание нового указателя ветки
Вы работаете над сайтом и делаете коммиты. Это приводит к тому, что ветка iss53 движется вперед, так как вы переключились на неё ранее ( HEAD указывает на неё).
$ vim index.html $ git commit -a -m 'Create new footer [issue 53]'
Рисунок 20. Ветка iss53 движется вперед
И тут вы получаете сообщение об обнаружении на сайте уязвимости, и эту уязвимость устранить нужно немедленно. Благодаря Git вам не придётся ни пытаться реализовать исправление вместе с изменениями, которые вы сделали в ходе разработки iss53 , ни прилагать усилия для отката этих изменений и возвращения к исходному состоянию перед началом разработки исправления. Все, что вам нужно — переключиться на ветку master .
Имейте в виду, что если рабочий каталог или индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки. Лучше всего переключаться из чистого рабочего состояния проекта: все изменённые файлы добавить в индекс и сделать коммит. Есть способы обойти это (припрятать изменения (stash) или добавить их в последний коммит (amend)), но об этом мы поговорим позже в разделе Припрятывание и очистка главы 7. Теперь предположим, что вы зафиксировали все свои изменения и можете переключиться на ветку master :
$ git checkout master Switched to branch 'master'
С этого момента ваш рабочий каталог имеет точно такой же вид, какой был перед началом работы над задачей #53, и вы можете сосредоточиться на работе над исправлением. Важно запомнить: когда вы переключаете ветки, Git возвращает состояние рабочего каталога к тому виду, какой он имел в момент последнего коммита в переключаемую ветку. Он добавляет, удаляет и изменяет файлы автоматически, чтобы состояние рабочего каталога соответствовало тому, когда был сделан последний коммит.
Теперь вы можете перейти к написанию исправления. Давайте создадим новую ветку, в которой реализуем исправление.
$ git checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'Fix broken email address' [hotfix 1fb7853] Fix broken email address 1 file changed, 2 insertions(+)
Рисунок 21. Ветка hotfix основана на ветке master
Вы можете прогнать тесты, чтобы убедиться, что ваше уязвимость в самом деле исправлена. И если это так — выполнить слияние ветки hotfix с веткой master для включения изменений в продукт. Это делается командой git merge :
$ git checkout master $ git merge hotfix Updating f42c576..3a0874c Fast-forward index.html | 2 ++ 1 file changed, 2 insertions(+)
Заметили фразу «fast-forward» в этом слиянии? Git просто переместил указатель ветки вперед, потому что коммит C4 , на который указывает слитая ветка hotfix , был прямым потомком коммита C2 , на котором вы находились до этого. Другими словами, если коммит сливается с тем, до которого можно добраться, двигаясь по истории вперёд, Git упрощает слияние, просто перенося указатель ветки вперед, потому что в этом случае нет никаких разнонаправленных изменений, которые нужно было бы свести воедино. Это называется «fast-forward».
Теперь ваши изменения включены в коммит, на который указывает ветка master , и исправление можно внедрять.
Рисунок 22. master перемотан до hotfix
После внедрения вашего архиважного исправления вы готовы вернуться к работе над тем, что были вынуждены отложить. Но сначала нужно удалить ветку hotfix , потому что она больше не нужна — ветка master указывает на то же самое место. Для удаления ветки выполните команду git branch с параметром -d :
$ git branch -d hotfix Deleted branch hotfix (3a0874c).
Теперь вы можете переключиться обратно на ветку iss53 и продолжить работу над задачей #53:
$ git checkout iss53 Switched to branch "iss53" $ vim index.html $ git commit -a -m 'Finish the new footer [issue 53]' [iss53 ad82d7a] Finish the new footer [issue 53] 1 file changed, 1 insertion(+)
Рисунок 23. Продолжение работы над iss53
Стоит обратить внимание на то, что все изменения из ветки hotfix не включены в вашу ветку iss53 . Если их нужно включить, вы можете влить ветку master в вашу ветку iss53 командой git merge master , а можете отложить слияние этих изменений до завершения работы, и затем влить ветку iss53 в master .
Основы слияния
Предположим, вы решили, что работа по проблеме #53 закончена и её можно влить в ветку master . Для этого нужно выполнить слияние ветки iss53 точно так же, как вы делали это с веткой hotfix ранее. Все, что нужно сделать — переключиться на ветку, в которую вы хотите включить изменения, и выполнить команду git merge :
$ git checkout master Switched to branch 'master' $ git merge iss53 Merge made by the 'recursive' strategy. index.html | 1 + 1 file changed, 1 insertion(+)
Результат этой операции отличается от результата слияния ветки hotfix . В данном случае процесс разработки ответвился в более ранней точке. Так как коммит, на котором мы находимся, не является прямым родителем ветки, с которой мы выполняем слияние, Git придётся немного потрудиться. В этом случае Git выполняет простое трёхстороннее слияние, используя последние коммиты объединяемых веток и общего для них родительского коммита.
Рисунок 24. Использование трёх снимков при слиянии
Вместо того, чтобы просто передвинуть указатель ветки вперёд, Git создаёт новый результирующий снимок трёхстороннего слияния, а затем автоматически делает коммит. Этот особый коммит называют коммитом слияния, так как у него более одного предка.
Рисунок 25. Коммит слияния
Теперь, когда изменения слиты, ветка iss53 больше не нужна. Вы можете закрыть задачу в системе отслеживания ошибок и удалить ветку:
$ git branch -d iss53
Основные конфликты слияния
Иногда процесс не проходит гладко. Если вы изменили одну и ту же часть одного и того же файла по-разному в двух объединяемых ветках, Git не сможет их чисто объединить. Если ваше исправление ошибки #53 потребовало изменить ту же часть файла что и hotfix , вы получите примерно такое сообщение о конфликте слияния:
$ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.
Git не создал коммит слияния автоматически. Он остановил процесс до тех пор, пока вы не разрешите конфликт. Чтобы в любой момент после появления конфликта увидеть, какие файлы не объединены, вы можете запустить git status :
$ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add . " to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a")
Всё, где есть неразрешённые конфликты слияния, перечисляется как неслитое. В конфликтующие файлы Git добавляет специальные маркеры конфликтов, чтобы вы могли исправить их вручную. В вашем файле появился раздел, выглядящий примерно так:
contact : email.support@github.com
please contact us at support@github.com
>>>>>>> iss53:index.html
Это означает, что версия из HEAD (вашей ветки master , поскольку именно её вы извлекли перед запуском команды слияния) — это верхняя часть блока (всё, что над ======= ), а версия из вашей ветки iss53 представлена в нижней части. Чтобы разрешить конфликт, придётся выбрать один из вариантов, либо объединить содержимое по-своему. Например, вы можете разрешить конфликт, заменив весь блок следующим:
please contact us at email.support@github.com
В этом разрешении есть немного от каждой части, а строки >>>>>> полностью удалены. Разрешив каждый конфликт во всех файлах, запустите git add для каждого файла, чтобы отметить конфликт как решённый. Добавление файла в индекс означает для Git, что все конфликты в нём исправлены.
Если вы хотите использовать графический инструмент для разрешения конфликтов, можно запустить git mergetool , который проведет вас по всем конфликтам:
$ git mergetool This message is displayed because 'merge.tool' is not configured. See 'git mergetool --tool-help' or 'git help config' for more details. 'git mergetool' will now attempt to use one of the following tools: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge Merging: index.html Normal merge conflict for 'index.html': : modified file : modified file Hit return to start merge resolution tool (opendiff):
Если вы хотите использовать инструмент слияния не по умолчанию (в данном случае Git выбрал opendiff , поскольку команда запускалась на Mac), список всех поддерживаемых инструментов представлен вверху после фразы «one of the following tools». Просто введите название инструмента, который хотите использовать.
Примечание
Мы рассмотрим более продвинутые инструменты для разрешения сложных конфликтов слияния в разделе Продвинутое слияние главы 7.
После выхода из инструмента слияния Git спросит об успешности процесса. Если вы ответите скрипту утвердительно, то он добавит файл в индекс, чтобы отметить его как разрешённый. Теперь можно снова запустить git status , чтобы убедиться в отсутствии конфликтов:
$ git status On branch master All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: index.html
Если это вас устраивает и вы убедились, что все файлы, где были конфликты, добавлены в индекс — выполните команду git commit для создания коммита слияния. Комментарий к коммиту слияния по умолчанию выглядит примерно так:
Merge branch 'iss53' Conflicts: index.html # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # All conflicts fixed but you are still merging. # # Changes to be committed: # modified: index.html #
Если вы считаете, что коммит слияния требует дополнительных пояснений — опишите как были разрешены конфликты и почему были применены именно такие изменения, если это не очевидно.
Работа с ветками в Git (git branch)
Инструкция о том, как работать с ветками в Git. Расскажем, как закоммитить изменения и запушить в новую ветку, как удалить ветку или изменить ее — и это не все.
Эта инструкция — часть курса «Введение в Git».
Смотреть весь курс
Введение
Ветвление стало неотъемлемой частью командной разработки, потому что оно дает возможность работать над разными версиями исходного кода. Основной идеей ветвления является отклонение от основного кода и продолжение работы независимо от него. Также это удобно в тестировании отдельного функционала, потому что позволяет работать над новой частью кода, не беспокоясь о поломке чего-то в рабочей версии. В этой инструкции расскажем о том, как работать с ветками в Git.
Основные понятия: о ветке Git и master
Под веткой принято понимать независимую последовательность коммитов в хронологическом порядке. Однако конкретно в Git реализация ветки выполнена как указатель на последний коммит в рассматриваемой ветке. После создания ветки уже новый указатель ссылается на текущий коммит.
Имя основной ветки Git-проекта по умолчанию — master (однако зачастую бывает main, например, в GitHub), она появляется сразу при инициализации репозитория. Эта ветка ничем не отличается от остальных и также ее можно переименовать, но по договоренности master принято считать главной веткой в проекте.
Что делает git branch
Команда git branch — главный инструмент для работы с ветвлением. С ее помощью можно добавлять новые ветки, перечислять и переименовывать существующие и удалять их.
Способы создания веток и переключения между ними
Чтобы в Git добавить ветку мы используем:
$ git branch
После данной операции ветка уже была создана, но вы по-прежнему находитесь в прежней ветке. Если вы планируете переместиться на другую ветку, в том числе только что созданную, необходимо написать checkout:
$ git checkout
Для того чтобы определить, где сейчас находится разработчик, Git использует специальный указатель HEAD, ссылающийся на текущую локальную ветку. В результате checkout HEAD переместится на иную ветку.
Как с помощью git branch создать ветку и перейти в нее
Чаще всего при создании новой ветки git пользователю необходимо сразу же переключиться на нее. В таком случае стоит использовать:
$ git checkout branch
Это будет равносильно:
$ git branch
$ git checkout
И также мы получим тот же результат при использовании git checkout с ключом -b:
$ git checkout -b
Если пользователю нужно получить список определенного множества веток, то тогда можно воспользоваться ключами. Одними из самых распространенных будут:
- -r — при использовании этого ключа мы получим список удаленных веток,
- -a — используя этот параметр, в выводе будут удаленные и локальные ветки.
О команде git checkout
При выполнении этой команды Git требуется осуществить определенный порядок действий, чтобы переходить на ветку, которую мы указали. Для этого программа выполняет следующий алгоритм:
Проверка, что указанная нами ветка существует в проекте
Этот этап необходим, так как в ином случае программа не сможет переключиться на ветвь, которая не определена. Для большего понимания нужно вспомнить, что такое ветка в git. Учитываем, что фактически задание ветки — это запись коммита, на который она ссылается. Внутри Git наличие конкретной ветки проверяется наличием одноименного файла в конкретной директории.
Переключение указателя HEAD на новую ветку
Необходимо сместить указатель, чтобы Git понимал, где сейчас идет работа.
Изменение рабочей версии таким образом, чтобы новая ветка ей полностью соответствовала
Сама концепция работы ветвления заключается в том, что в разных ветках находятся разные версии кода, над которыми работа ведется отдельно друг от друга. Тогда необходимо изменить рабочую копию. Git берет последний коммит и восстанавливает все изменения.
После завершения всех перечисленных выше действий можно считать, что мы полностью переключились. Также с помощью checkout можно извлечь отдельный файл (или папку) из другой ветки и получить его, предварительно перейдя в ту ветку, куда вы собираетесь перенести файл. Для этого выполняем:
$ git checkout --
Основы ветвления и слияния
Ветвление позволяет разделять рабочий процесс, оптимизировать тестирование и написание нового кода. Однако после того, как разработчик убедился, что написанный им кусок кода готов и его можно отправить к остальной части итоговой версии, удобно переместить его в основную ветку. Такой подход дает возможность получить к концу разработки проекта целый продукт в одном месте.
Для этого в Git предусмотрено слияние — перенос изменений с одной ветки на другую. Однако сливаемая ветка (под этим определением мы подразумеваем ветку, у которой берем изменения для «вливания» их в другую ветвь) никак не меняется и остается в прежнем состоянии. Такие преобразования мы получаем, применив git merge:
$ git merge
Операция может привести к появлению конфликтов при попытке слить ветки. Это вызвано тем, что изменения удаляют или переписывают информацию в существующих файлах. При попытке некорректного слияния Git останавливает выполнение команды, чтобы вы могли разрешить конфликт.
Также стоит упомянуть о существовании ключей, предназначенных специально для работы с конфликтами:
- —abort — прерывает слияние и возвращает все к началу
- —continue — продолжает слияние после разрешения конфликта
Решить конфликт можно двумя способами:
- Вручную разрешить файловый конфликт. Для этого нужно самим изменить файлы, с которыми возникли проблемы. Мы получим файлы такими, какими и представляли их при попытке слияния.
- Выбрать более подходящий файл, а от второго отказаться.
Управление ветками с помощью git branch
Эта команда может немного больше, чем просто в git создавать ветки из текущей. Если запустить ее без параметров:
$ git branch
При выполнении этой строки мы получим список существующих веток, где символом * будет отмечена ветка, где вы сейчас находитесь. Это может выглядеть так:
first_branch * master second_branch
С помощью параметра -v можно получить последний сохраненный коммит в каждой ветке.
$ git branch -v first_branch 8fa301b Fix math * master 225cc2d Merge branch 'first_branch' second_branch c56ee12 Refactor code style
Так же существуют опции —merged и —no-merged, с помощью которых можно отфильтровать полученную последовательность веток. То есть мы получим список ответвлений, которые уже были слиты, или, наоборот, ветки, которые еще не прошли через слияние с другими. Выведем ветки, которые уже были слиты с текущей:
$ git branch --merged first_branch * master
Как закоммитить изменения в новую ветку
После создания новой ветки, перехода в нее и совершения всех запланированных преобразований, нужно сделать коммит в эту же ветку, чтобы сохранить все изменения. Команды для выполнения этих действий ничем не отличаются от команд для создания коммитов в ветке мастер.
$ git add
$ git commit -m ''
После выполнения последовательности этих команд мы закоммитили изменения в нужной версии программы.
Как запушить в новую ветку
Если мы хотим запушить нашу ветку, то для этого нужно написать:
$ git push origin
Теперь ветка запушена. Если до этого мы уже пушили ее, то произойдет отправка новых коммитов.
В отличии от команды git checkout, при выполнении пуша нет проверки на существование указанной ветки. Это будет значить, что при написании несуществующей ветки git создаст ее автоматически.
Как переименовать ветку
В процессе разработки могут возникнуть ситуации, когда человек хочет по-другому называть уже созданную ветку. Это может быть связано с разными причинами (например, разрабатываемый в данной версии функционал не соответствует названию). Чтобы переименовать ветку применяем:
$ git branch -m
Однако здесь нужно быть аккуратными, чтобы не перегрузить проект ненужными ветками. Если запушить переименованную ветку, то на сервере появится ветка с новым именем, но и ветка со старым названием тоже останется. Чтобы избежать такой проблемы, необходимо удалить ветку локально и на сервере.
Как удалить ветку
Удаление веток не такой простой процесс, как может показаться. Можно случайно удалить несохраненные изменения в исходном коде, что приведет к нежелательным последствиям. Поэтому здесь нужно действовать осторожно. С операцией удаления над ветками справляется уже привычная команда git branch с параметром -d:
$ git branch -d
Для корректного удаления нужно помнить несколько правил, чтобы не получить ошибки:
- Нельзя удалить ветку, в которой вы находитесь. Git выкинет ошибку и не произведет удаление. Следовательно, нужно перейти на другую ветку.
- Git не позволит удалить ветку, у которой есть несохраненные изменения. Так мы избегаем ситуации, когда часть написанного кода будет безвозвратно утеряна. Если же мы уверены, что изменения в этой версии не нужны и их можно смело удалять, то вместо флага -d используем -D:
$ git branch -D
Соблюдая все условия, нам удастся удалить указанную ветвь.
Работа с ветками на практике
В инструментах для разработки на языках часто есть встроенный функционал, позволяющий работать напрямую с Git. Например, в таких средах разработки как IntelliJ IDEA, PyCharm, PhpStorm, CLine, Rider очень удобно и понятно, как правильно оперировать с разными ветками. Для примера разберем работу в одной из таких сред.
Как работать с ветками в PhpStorm
Справа в нижнем углу расположены вкладки для работы с Git, где и происходит вся настройка ветвления. На этой панели расположено название текущей ветки. При желании создать новую нужно нажать на этот пункт и выбрать New Branch. Для смены ветки — выбрать из списка искомую и кликнуть на Checkout. Для удаления и переименования предусмотрены кнопки Delete и Rename соответственно.
Работа в специальном приложении почти ничем не отличается от работы в консоли, поэтому все полученные знания можно применять независимо от выбранного способа.
Получение информации о состоянии веток
Как просмотреть состояния файлов ветки
Отметим, что при переходе на другую версию, незакоммиченные изменения перенесутся на ветку, куда мы перейдем. Поэтому перед переключением необходимо убедиться, что изменения в текущей ветки уже закоммичены. Для этого подходит git status:
$ git status
Выполнение этой операции позволит просмотреть файлы, расположенные в ветке, где мы находимся. Как раз с помощью нее можно отслеживать незакоммиченные изменения, чтобы случайно не перенести их в другое место. Пустой вывод этой команды показывает то, что в ветке не присутствуют измененные файлы и мы можем без опасений продолжать с ней работу. А иначе необходимо закоммитить все нужные исправления.
Как просмотреть истории коммитов ветки
Неоднократно в процессе разработки нужно посмотреть на журнал изменений: для отслеживания развития проекта или для определения коммита, к которому следует вернуться. В таких ситуациях выручает команда git log:
$ git log --
У данной команды есть множество ключей, используя которые можно получить более конкретную информацию:
- — (равноценно -n= ) — показывает последние n коммитов,
- —pretty= (доступные такие значения, как oneline, short, medium, full и другие) ****— форматированный вывод истории,
- -p — выводятся изменения, содержащиеся в коммите,
- —graph — представляет дерево взаимосвязей коммитов в виде ASCII-графа — такой метод использования позволяет получить графическое представление ветвей прямо в консоли,
- —all — на выходе мы получаем историю всех коммитов для всех существующих веток,
- —decorate — показывает, на что ссылаются указатели.
Если нам нужно посмотреть историю для конкретной ветви, то поможет выполнение:
$ git log ..
Структура веток в Git представлена в виде графа. Когда мы получаем коммиты определенной ветки, передвигаясь «вверх» по графу, мы должны остановиться в тот момент, когда дойдем до коммита, который будет меньше указателя родителя ветки. При выполнении этого условия когда ветка, чья история коммитов нас интересует, добирается до своего родителя, вывод прекращается, и мы получаем корректный ответ.
Как просмотреть различия между коммитами
Достаточно часто в ходе разработки какого-либо продукта у разработчика может возникнуть потребность посмотреть разницу между двумя коммитами, прежде чем заливать что-то. Для этого существует git diff:
$ git diff
Для этой операции также предусмотрены несколько ключей:
- —diff-filter= — с помощью этого параметра, изменяя значения меток, можно задать, обновления между какими файлами мы хотим увидеть. Рассмотрим некоторые возможные значения меток:
- D — покажет удаленные файлы,
- M — мы получим файлы, модифицированные после последнего коммита.
Заключение
Git обладает множеством преимуществ по сравнению с другими системами контроля версий как раз из-за легковесной работы с ветвлением. Такая гибкость помогает максимально оптимизировать процесс разработки. А само ветвление сильно упрощает разработку проекта. Ветки обеспечивают безопасный совместный доступ к коду для разных людей. Ведь именно они дают возможность пластично и изящно работать над созданием нового продукта.
Как установить Git на Windows
Шпаргалка по консольным командам Git
Git — система контроля версий (файлов). Что-то вроде возможности сохраняться в компьютерных играх (в Git эквивалент игрового сохранения — коммит). Важно: добавление файлов к «сохранению» двухступенчатое: сначала добавляем файл в индекс ( git add ), потом «сохраняем» ( git commit ).
Любой файл в директории существующего репозитория может находиться или не находиться под версионным контролем (отслеживаемые и неотслеживаемые).
Отслеживаемые файлы могут быть в 3-х состояниях: неизменённые, изменённые, проиндексированные (готовые к коммиту).
Ключ к пониманию
Ключ к пониманию концепции git — знание о «трех деревьях»:
- Рабочая директория — файловая система проекта (те файлы, с которыми вы работаете).
- Индекс — список отслеживаемых git-ом файлов и директорий, промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов).
- Директория .git/ — все данные контроля версий этого проекта (вся история разработки: коммиты, ветки, теги и пр.).
Коммит — «сохранение» (хранит набор изменений, сделанный в рабочей директории с момента предыдущего коммита). Коммит неизменен, его нельзя отредактировать.
У всех коммитов (кроме самого первого) есть один или более родительских коммитов, поскольку коммиты хранят изменения от предыдущих состояний.
Простейший цикл работ
- Редактирование, добавление, удаление файлов (собственно, работа).
- Индексация/добавление файлов в индекс (указание для git какие изменения нужно будет закоммитить).
- Коммит (фиксация изменений).
- Возврат к шагу 1 или отход ко сну.
Указатели
- HEAD — указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.
- ORIG_HEAD — указатель на коммит, с которого вы только что переместили HEAD (командой git reset . , например).
- Ветка ( master , develop etc.) — указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.
- Теги — простые указатели на коммиты. Не перемещаются.
Настройки
Перед началом работы нужно выполнить некоторые настройки:
git config --global user.name "Your Name" # указать имя, которым будут подписаны коммиты git config --global user.email "e@w.com" # указать электропочту, которая будет в описании коммитера
Если вы в Windows:
git config --global core.autocrlf true # включить преобразование окончаний строк из CRLF в LF
Указание неотслеживаемых файлов
Файлы и директории, которые не нужно включать в репозиторий, указываются в файле .gitignore . Обычно это устанавливаемые зависимости ( node_modules/ , bower_components/ ), готовая сборка build/ или dist/ и подобные, создаваемые при установке или запуске. Каждый файл или директория указываются с новой строки, возможно использование шаблонов.
Консоль
Длинный вывод в консоли: Vim
Вызов некоторых консольных команд приводит к необходимости очень длинного вывода в консоль (пример: вывод истории всех изменений в файле командой git log -p fileName.txt ). При этом прямо в консоли запускается редактор Vim. Он работает в нескольких режимах, из которых Вас заинтересуют режим вставки (редактирование текста) и нормальный (командный) режим. Чтобы попасть из Vim обратно в консоль, нужно в командном режиме ввести :q. Переход в командный режим из любого другого: Esc.
Если нужно что-то написать, нажмите i — это переход в режим вставки текста. Если нужно сохранить изменения, перейдите в командный режим и наберите :w.
Vim (некоторые команды)
# Нажатия кнопок ESC — переход в командный режим i — переход в режим редактирования текста ZQ (зажат Shift, поочередное нажатие) — выход без сохранения ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти ```bash # Нажатия кнопок ESC — переход в командный режим i — переход в режим редактирования текста ZQ (зажат Shift, поочередное нажатие) — выход без сохранения ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти # Ввод в командном режиме :q! — выйти без сохранения :wq — сохранить файл и выйти :w filename.txt — сохранить файл как filename.txt
Консольные команды
Создать новый репозиторий
git init # создать новый проект в текущей директории git init folder-name # создать новый проект в указанной директории
Клонирование репозитория
# клонировать удаленный репозиторий в одноименную директорию git clone https://gitflic.ru/project/donhuaze/udalyator.git # клонировать удаленный репозиторий в директорию «FolderName» git clone https://gitflic.ru/project/donhuaze/udalyator.git FolderName # клонировать репозиторий в текущую директорию git clone https://gitflic.ru/project/donhuaze/udalyator.git .
Просмотр изменений
git status # показать состояние репозитория (отслеживаемые, изменённые, новые файлы и пр.) git diff # сравнить рабочую директорию и индекс (неотслеживаемые файлы ИГНОРИРУЮТСЯ) git diff --color-words # сравнить рабочую директорию и индекс, показать отличия в словах (неотслеживаемые файлы ИГНОРИРУЮТСЯ) git diff index.html # сравнить файл из рабочей директории и индекс git diff HEAD # сравнить рабочую директорию и коммит, на который указывает HEAD (неотслеживаемые файлы ИГНОРИРУЮТСЯ) git diff --staged # сравнить индекс и коммит с HEAD git diff master feature # посмотреть что сделано в ветке feature по сравнению с веткой master git diff --name-only master feature # посмотреть что сделано в ветке feature по сравнению с веткой master, показать только имена файлов git diff master. feature # посмотреть что сделано в ветке feature с момента (коммита) расхождения с master
Добавление изменений в индекс
git add . # добавить в индекс все новые, изменённые, удалённые файлы из текущей директории и её поддиректорий git add text.txt # добавить в индекс указанный файл (был изменён, был удалён или это новый файл) git add -i # запустить интерактивную оболочку для добавления в индекс только выбранных файлов git add -p # показать новые/изменённые файлы по очереди с указанием их изменений и вопросом об отслеживании/индексировании
Удаление изменений из индекса
git reset # убрать из индекса все добавленные в него изменения (в рабочей директории все изменения сохранятся), антипод git add git reset readme.txt # убрать из индекса изменения указанного файла (в рабочей директории изменения сохранятся)
Отмена изменений
git checkout text.txt # ОПАСНО: отменить изменения в файле, вернуть состояние файла, имеющееся в индексе git reset --hard # ОПАСНО: отменить изменения; вернуть то, что в коммите, на который указывает HEAD (незакомиченные изменения удалены из индекса и из рабочей директории, неотслеживаемые файлы останутся на месте) git clean -df # удалить неотслеживаемые файлы и директории
Коммиты
git commit -m "Name of commit" # зафиксировать в коммите проиндексированные изменения (закоммитить), добавить сообщение git commit -a -m "Name of commit" # проиндексировать отслеживаемые файлы (ТОЛЬКО отслеживаемые, но НЕ новые файлы) и закоммитить, добавить сообщение
Отмена коммитов и перемещение по истории
Все коммиты, которые уже были отправлены в удалённый репозиторий, должны отменяться новыми коммитами ( git revert ), дабы избежать проблем с историей разработки у других участников проекта.
git revert HEAD --no-edit # создать новый коммит, отменяющий изменения последнего коммита без запуска редактора сообщения git revert b9533bb --no-edit # то же, но отменяются изменения, внесённые коммитом с указанным хешем (b9533bb)
Все команды, приведённые ниже можно выполнять ТОЛЬКО если коммиты еще не были отправлены в удалённый репозиторий.
# ВНИМАНИЕ! Опасные команды, можно потерять незакоммиченные изменения git commit --amend -m "Название" # «перекоммитить» изменения последнего коммита, заменить его новым коммитом с другим сообщением (сдвинуть текущую ветку на один коммит назад, сохранив рабочую директорию и индекс «как есть», создать новый коммит с данными из «отменяемого» коммита, но новым сообщением) git reset --hard @~ # передвинуть HEAD (и ветку) на предыдущий коммит, рабочую директорию и индекс сделать такими, какими они были в момент предыдущего коммита git reset --hard 75e2d51 # передвинуть HEAD (и ветку) на коммит с указанным хешем, рабочую директорию и индекс сделать такими, какими они были в момент указанного коммита git reset --soft @~ # передвинуть HEAD (и ветку) на предыдущий коммит, но в рабочей директории и индексе оставить все изменения git reset --soft @~2 # то же, но передвинуть HEAD (и ветку) на 2 коммита назад git reset @~ # передвинуть HEAD (и ветку) на предыдущий коммит, рабочую директорию оставить как есть, индекс сделать таким, каким он был в момент предыдущего коммита (удобнее, чем git reset --soft @~, если индекс нужно задать заново) # Почти как git reset --hard, но безопаснее: не получится потерять изменения в рабочей директории git reset --keep @~ # передвинуть HEAD (и ветку) на предыдущий коммит, сбросить индекс, но в рабочей директории оставить изменения, если возможно (если файл с изменениями между коммитами менялся, будет выдана ошибка и переключение не произойдёт)
Временно переключиться на другой коммит
git checkout b9533bb # переключиться на коммит с указанным хешем (переместить HEAD на указанный коммит, рабочую директорию вернуть к состоянию, на момент этого коммита) git checkout master # переключиться на коммит, на который указывает master (переместить HEAD на коммит, на который указывает master, рабочую директорию вернуть к состоянию на момент этого коммита)
Переключиться на другой коммит и продолжить работу с него
Потребуется создание новой ветки, начинающейся с указанного коммита.
git checkout -b new-branch 5589877 # создать ветку new-branch, начинающуюся с коммита c хешем 5589877 (переместить HEAD на указанный коммит, рабочую директорию вернуть к состоянию, на момент этого коммита, создать указатель на этот коммит (ветку) с указанным именем)
Восстановление изменений
git checkout 5589877 index.html # восстановить в рабочей директории указанный файл на момент указанного коммита (и добавить это изменение в индекс) (git reset index.html для удаления из индекса, но сохранения изменений в файле)
Копирование коммита (перенос коммитов)
git cherry-pick 5589877 # скопировать на активную ветку изменения из указанного коммита, закоммитить эти изменения git cherry-pick master~2..master # скопировать на активную ветку изменения из master (2 последних коммита) git cherry-pick -n 5589877 # скопировать на активную ветку изменения из указанного коммита, но НЕ КОММИТИТЬ (подразумевается, что мы сами потом закоммитим) git cherry-pick master..feature # скопировать на активную ветку изменения из всех коммитов ветки feature с момента её расхождения с master (похоже на слияние веток, но это копирование изменений, а не слияние), закоммитить эти изменения; это может вызвать конфликт git cherry-pick --abort # прервать конфликтный перенос коммитов git cherry-pick --continue # продолжить конфликтный перенос коммитов (сработает только после решения конфликта)
Удаление файла
git rm text.txt # удалить отслеживаемый неизменённый файл и проиндексировать это изменение git rm -f text.txt # удалить отслеживаемый изменённый файл и проиндексировать это изменение git rm -r log/ # удалить всё содержимое отслеживаемой директории log/ и проиндексировать это изменение git rm ind* # удалить все отслеживаемые файлы с именем, начинающимся на «ind» в текущей директории и проиндексировать это изменение git rm --cached readme.txt # удалить из отслеживаемых индексированный файл (ФАЙЛ ОСТАНЕТСЯ НА МЕСТЕ) (часто используется для нечаянно добавленных в отслеживаемые файлов)
Перемещение/переименование файлов
Для git не существует переименования. Переименование воспринимается как удаление старого файла и создание нового. Факт переименования может быть определен только после индексации изменения.
git mv text.txt test_new.txt # переименовать файл «text.txt» в «test_new.txt» и проиндексировать это изменение git mv readme_new.md folder/ # переместить файл readme_new.md в директорию folder/ (должна существовать) и проиндексировать это изменение
История коммитов
Выход из длинного лога вывода: q .
git log master # показать коммиты в указанной ветке git log -2 # показать последние 2 коммита в активной ветке git log -2 --stat # показать последние 2 коммита и статистику внесенных ими изменений git log -p -22 # показать последние 22 коммита и внесенную ими разницу на уровне строк git log --graph -10 # показать последние 10 коммитов с ASCII-представлением ветвления git log --since=2.weeks # показать коммиты за последние 2 недели git log --after '2018-06-30' # показать коммиты, сделанные после указанной даты git log index.html # показать историю изменений файла index.html (только коммиты) git log -5 index.html # показать историю изменений файла index.html, последние 5 коммитов (только коммиты) git log -p index.html # показать историю изменений файла index.html (коммиты и изменения) git log -G'myFunction' -p # показать все коммиты, в которых менялись строки с myFunction (в кавычках регулярное выражение) git log -L '//','//':index.html # показать изменения от указанного до указанного регулярных выражений в указанном файле git log --grep fix # показать коммиты, в описании которых есть буквосочетание fix (регистрозависимо, только коммиты текущей ветки) git log --grep fix -i # показать коммиты, в описании которых есть буквосочетание fix (регистроНЕзависимо, только коммиты текущей ветки) git log --grep 'fix(ing|me)' -P # показать коммиты, в описании которых есть совпадения для регулярного выражения (только коммиты текущей ветки) git log --pretty=format:"%h - %an, %ar : %s" -4 # показать последние 4 коммита с форматированием выводимых данных git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short # мой формат вывода, висящий на алиасе оболочки git log master..branch_99 # показать коммиты из ветки branch_99, которые не влиты в master git log branch_99..master # показать коммиты из ветки master, которые не влиты в branch_99 git log master. branch_99 --boundary -- graph # показать коммиты из указанных веток, начиная с их расхождения (коммит расхождения будет показан)
git show 60d6582 # показать изменения из коммита с указанным хешем git show HEAD~ # показать данные о предыдущем коммите в активной ветке git show @~ # аналогично предыдущему git show HEAD~3 # показать данные о коммите, который был 3 коммита назад git show my_branch~2 # показать данные о коммите, который был 2 коммита назад в указанной ветке git show @~:index.html # показать контент указанного файла на момент предыдущего (от HEAD) коммита git show :/"подвал" # показать самый новый коммит, в описании которого есть указанное слово (из любой ветки)
Кто написал строку
git blame README.md --date=short -L 5,8 # показать строки 5-8 указанного файла и коммиты, в которых строки были добавлены
История изменений указателей (веток, HEAD)
git reflog -20 # показать последние 20 изменений положения указателя HEAD git reflog --format='%C(auto)%h %<|(20)%gd %C(blue)%cr%C(reset) %gs (%s)' -20 # то же, но с указанием давности действий
Ветки
git branch # показать список веток git branch -v # показать список веток и последний коммит в каждой git branch new_branch # создать новую ветку с указанным именем на текущем коммите git branch new_branch 5589877 # создать новую ветку с указанным именем на указанном коммите git branch -f master 5589877 # переместить ветку master на указанный коммит git branch -f master master~2 # переместить ветку master на 2 коммита назад git checkout new_branch # перейти в указанную ветку git checkout -b new_branch # создать новую ветку с указанным именем и перейти в неё git checkout -B master 5589877 # переместить ветку с указанным именем на указанный коммит и перейти в неё git merge hotfix # влить в ветку, в которой находимся, данные из ветки hotfix git merge hotfix -m "Горячая правка" # влить в ветку, в которой находимся, данные из ветки hotfix (указано сообщение коммита слияния) git merge hotfix --log # влить в ветку, в которой находимся, данные из ветки hotfix, показать редактор описания коммита, добавить в него сообщения вливаемых коммитов git merge hotfix --no-ff # влить в ветку, в которой находимся, данные из ветки hotfix, запретить простой сдвиг указателя, изменения из hotfix «останутся» в ней, а в активной ветке появится только коммит слияния git branch -d hotfix # удалить ветку hotfix (используется, если её изменения уже влиты в главную ветку) git branch --merged # показать ветки, уже слитые с активной git branch --no-merged # показать ветки, не слитые с активной git branch -a # показать все имеющиеся ветки (в т.ч. на удаленных репозиториях) git branch -m old_branch_name new_branch_name # переименовать локально ветку old_branch_name в new_branch_name git branch -m new_branch_name # переименовать локально ТЕКУЩУЮ ветку в new_branch_name git push origin :old_branch_name new_branch_name # применить переименование в удаленном репозитории git branch --unset-upstream # завершить процесс переименования
Теги
git tag v1.0.0 # создать тег с указанным именем на коммите, на который указывает HEAD git tag -a -m 'В продакшен!' v1.0.1 master # создать тег с описанием на том коммите, на который смотрит ветка master git tag -d v1.0.0 # удалить тег с указанным именем(ами) git tag -n # показать все теги, и по 1 строке сообщения коммитов, на которые они указывают git tag -n -l 'v1.*' # показать все теги, которые начинаются с 'v1.*'
Временное сохранение изменений без коммита
git stash # временно сохранить незакоммиченные изменения и убрать их из рабочей директории git stash pop # вернуть сохраненные командой git stash изменения в рабочую директорию
Удалённые репозитории
Есть два распространённых способа привязать удалённый репозиторий к локальному: по HTTPS и по SSH. Если SSH у вас не настроен (или вы не знаете что это), привязывайте удалённый репозиторий по HTTPS (адрес привязываемого репозитория должен начинаться с https://).
git remote -v # показать список удалённых репозиториев, связанных с локальным git branch -r # показать удаленные ветки git branch -a # показать все ветки(локальные и удаленные) git remote remove origin # убрать привязку удалённого репозитория с сокр. именем origin git remote add origin https://gitflic.ru/project/donhuaze/udalyator.git # добавить удалённый репозиторий (с сокр. именем origin) с указанным URL git remote rm origin # удалить привязку удалённого репозитория git remote show origin # получить данные об удалённом репозитории с сокращенным именем origin git fetch origin # скачать все ветки с удаленного репозитория (с сокр. именем origin), но не сливать со своими ветками git fetch origin master # то же, но скачивается только указанная ветка git checkout --track origin/donhua_branch # создать локальную ветку github_branch (данные взять из удалённого репозитория с сокр. именем origin, ветка github_branch) и переключиться на неё git push origin master # отправить в удалённый репозиторий (с сокр. именем origin) данные своей ветки master git pull origin # влить изменения с удалённого репозитория (все ветки) git pull origin master # влить изменения с удалённого репозитория (только указанная ветка)
Конфликт слияния
Предполагается ситуация: есть ветка master и есть ветка feature . В обеих ветках есть коммиты, сделанные после расхождения веток. В ветку master пытаемся влить ветку feature ( git merge feature ), получаем конфликт, т.к. в обеих ветках есть изменения одной и той же строки в файле index.html .
При возникновении конфликта, репозиторий находится в состоянии прерванного слияния. Нужно оставить в конфликтующих местах файлов только нужный код, проиндексировать изменения и закоммитить.
git merge feature # влить в активную ветку изменения из ветки feature git merge-base master feature # показать хеш последнего общего коммита для двух указанных веток git checkout --ours index.html # оставить в конфликтном файле (index.html) состояние ветки, В КОТОРУЮ мы вливаем (в примере — из ветки master) git checkout --theirs index.html # оставить в конфликтном файле (index.html) состояние ветки, ИЗ КОТОРОЙ мы вливаем (в примере — из ветки feature) git checkout --merge index.html # показать в конфликтном файле (index.html) сравнение содержимого сливаемых веток (для ручного редактирования) git checkout --conflict=diff3 --merge index.html # показать в конфликтном файле (index.html) сравнение содержимого сливаемых веток плюс то, что было в месте конфликта в коммите, на котором разошлись сливаемые ветки
git reset --hard # прекратить это прерванное слияние, вернуть рабочую директорию и индекс как было в момент коммита, на который указывает HEAD, а я пойду немного поплачу git reset --merge # прекратить это прерванное слияние, но оставить изменения, не закоммиченные до слияния (для случая, когда слияние делается не на чистом статусе) git reset --abort # то же, что и строкой выше
«Перенос» ветки
Можно «переместить» ответвление какой-либо ветки от основной на произвольный коммит. Это нужно для того, чтобы в «переносимой» ветке появились какие-либо изменения, внесённые в основной ветке (уже после ответвления переносимой).
Нельзя «переносить» ветку, если она уже отправлена на удалённый репозиторий.
git rebase master # перенести все коммиты (создать их копии) активной ветки так, будто активная ветка ответвилась от master на нынешней вершине master (часто вызывает конфликты) git rebase --onto master feature # перенести коммиты активной ветки на master, начиная с того места, в котором активная ветка отделилась от ветки feature git rebase --abort # прервать конфликтный rebase, вернуть рабочую директорию и индекс к состоянию до начала rebase git rebase --continue # продолжить конфликтный rebase (сработает только после разрешения конфликта и индексации такого разрешения)
Как отменить rebase
git reflog feature -2 # смотрим лог перемещений ветки, которой делали rebase (в этом примере — feature), видим последний коммит ПЕРЕД rebase, на него и нужно перенести указатель ветки git reset --hard feature@ # переместить указатель ветки feature на один коммит назад, обновить рабочую директорию и индекс
Разное
git archive -o ./project.zip HEAD # создать архив с файловой структурой проекта по указанному пути (состояние репозитория, соответствующее указателю HEAD)
Примеры
Собираем коллекцию простых и сложных примеров работы.
Начало работы
Создание нового репозитория, первый коммит, привязка удалённого репозитория с gthub.com, отправка изменений в удалённый репозиторий.
# указана последовательность действий: # создана директория проекта, мы в ней git init # создаём репозиторий в этой директории touch readme.md # создаем файл readme.md git add readme.md # добавляем файл в индекс git commit -m "Старт" # создаем коммит git remote add origin https://gitflic.ru/project/donhuaze/udalyator.git # добавляем предварительно созданный пустой удаленный репозиторий git push -u origin master # отправляем данные из локального репозитория в удаленный (в ветку master)
«Внесение изменений» в коммит
Только если коммит ещё не был отправлен в удалённые репозиторий.
# указана последовательность действий: subl inc/header.html # редактируем и сохраняем разметку «шапки» git add inc/header.html # индексируем измененный файл git commit -m "Убрал телефон из шапки" # делаем коммит # ВНИМАНИЕ: коммит пока не был отправлен в удалённый репозиторий # сознаём, что нужно было еще что-то сделать в этом коммите. subl inc/header.html # вносим изменения git add inc/header.html # индексируем измененный файл (можно git add .) git commit --amend -m "«Шапка»: выполнена задача №34" # заново делаем коммит
Работа с ветками
Есть master (публичная версия сайта), выполняем масштабную задачу (переверстать «шапку»), но по ходу работ возникает необходимость подправить критичный баг (неправильно указан контакт в «подвале»).
# указана последовательность действий: git checkout -b new-page-header # создадим новую ветку для задачи изменения «шапки» и перейдём в неё subl inc/header.html # редактируем разметку «шапки» git commit -a -m "Новая шапка: смена логотипа" # делаем коммит (работа еще не завершена) # тут выясняется, что есть баг с контактом в «подвале» git checkout master # возвращаемся к ветке master subl inc/footer.html # устраняем баг и сохраняем разметку «подвала» git commit -a -m "Исправление контакта в подвале" # делаем коммит git push # отправляем коммит с быстрым критическим изменением в master в удалённом репозитории git checkout new-page-header # переключаемся обратно в ветку new-page-header для продолжения работ над «шапкой» subl inc/header.html # редактируем и сохраняем разметку «шапки» git commit -a -m "Новая шапка: смена навигации" # делаем коммит (работа над «шапкой» завершена) git checkout master # переключаемся в ветку master git merge new-page-header # вливаем в master изменения из ветки new-page-header git branch -d new-page-header # удаляем ветку new_page_header
Работа с ветками, слияние и откат к состоянию до слияния
Была ветка fix , в которой исправляли баг. Исправили, влили fix в master . но тут выяснилось, что это исправление ломает какую-то функциональность, Нужно откатить master к состоянию без слияния (наличие бага менее критично, чем порча функциональности).
# находимся в ветке fix, баг уже «исправлен» git checkout master # переключаемся на master git merge fix # вливаем изменения из fix в master # видим проблему: часть функциональности сломалась git checkout fix # переключаемся на fix (пока мы в master, git не даст ее двигать) git branch -f master ORIG_HEAD # передвигаем ветку master на коммит, указанный в ORIG_HEAD (тот, на который указывала master до вливания fix)
Работа с ветками, конфликт слияния
Есть ветка master (публичная версия сайта), в двух параллельных ветках ( branch-1 и branch-2 ) было отредактировано одно и то же место одного и того же файла, первую ветку ( branch-1 ) влили в master, попытка влить вторую вызывает конфликт.
# указана последовательность действий: git checkout master # переключаемся на ветку master git checkout -b branch-1 # создаём ветку branch-1, основанную на ветке master subl . # редактируем и сохраняем файлы git commit -a -m "Правка 1" # коммитим git checkout master # возвращаемся к ветке master git checkout -b branch-2 # создаём ветку branch-2, основанную на ветке master subl . # редактируем и сохраняем файлы git commit -a -m "Правка 2" # коммитим git checkout master # возвращаемся к ветке master git merge branch-1 # вливаем изменения из ветки branch-1 в текущую ветку (master), удача (автослияние) git merge branch-2 # вливаем изменения из ветки branch-2 в текущую ветку (master), КОНФЛИКТ автослияния # Automatic merge failed; fix conflicts and then commit the result. subl . # выбираем в конфликтных файлах те участки, которые нужно оставить, сохраняем git commit -a -m "Устранение конфликта" # коммитим результат устранения конфликта
Синхронизация репозитория-форка с мастер-репозиторием
Есть некий репозиторий на github.com, он него нами был сделан форк, добавлены какие-то изменения. Оригинальный (мастер-)репозиторий был как-то обновлён. Задача: стянуть с мастер-репозитория изменения (которые там внесены уже после того, как мы его форкнули).
# указана последовательность действий: git remote add upstream https://gitflic.ru/project/donhuaze/udalyator.git # добавляем удаленный репозиторий: сокр. имя — upstream, URL мастер-репозитория git fetch upstream # стягиваем все ветки мастер-репозитория, но пока не сливаем со своими git checkout master # переключаемся на ветку master своего репозитория git merge upstream/master # вливаем стянутую ветку master удалённого репозитория upstream в свою ветку master
Ошибка в работе: закоммитили в мастер, но поняли, что нужно было коммитить в новую ветку
ВАЖНО: это сработает только если коммит еще не отправлен в удалённый репозиторий.
# указана последовательность действий: # сделали изменения, проиндексировали их, закоммитили в master, но ЕЩЁ НЕ ОТПРАВИЛИ (не делали git push) git checkout -b new-branch # создаём новую ветку из master git checkout master # переключаемся на master git reset HEAD~ --hard # сдвигаем указатель (ветку) master на 1 коммит назад git checkout new-branch # переключаемся обратно на новую ветку для продолжения работы
Нужно вернуть содержимое файла к состоянию, бывшему в каком-либо коммите (известен хеш коммита)
# указана последовательность действий: git checkout f26ed88 -- index.html # восстановить в рабочей директории состояние указанного файла на момент указанного коммита, добавить это изменение в индекс git commit -am "Navigation fixs" # сделать коммит
При любом действии с github (или другим удалённым сервисом) запрашивается логин и пароль
Речь именно о запросе пары логин + пароль, а не ключевой фразы. Происходит это потому, что git по умолчанию не сохранит пароль для доступа к репозиторию по HTTPS.
.gitattributes
* text=auto *.html diff=html *.css diff=css *.scss diff=css