Материалы взяты с сайта http://learngitbranching.js.org/
git commit — совершаем commit, сохранение в текущей ветки
|
1 |
git commit |
Мы только что внесли изменения в репозиторий и сохранили их как коммит. У коммита, который мы только что сделали, есть родитель, С1, который указывает на предыдущий коммит.
git commit —amend — Изменение последнего коммита
git branch [name] — создание ветки по имени newImage, до этого была ветка master
|
1 |
git branch newImage |
Ветка newImage теперь указывает на коммит C1
|
1 |
git commit |
git checkout [name] — переключение на ветку newImage и commit ее
|
1 2 |
git checkout newImage git commit |
git merge [name] — Вот у нас две ветки, каждая содержит по одному уникальному коммиту. Это означает, что ни одна из веток не содержит полный набор «работ», выполненных в этом репозитории. Можно исправить эту ситуацию, выполнив слияние.
Мы сделаем merge ветки bugFix в ветку master
|
1 |
git merge bugFix |
Что мы видим? Во-первых, ветка master теперь указывает на коммит, у которого два родителя. Если проследовать по стрелкам от этого коммита, вы пройдёте через каждый коммит в дереве прямиком к началу. Это означает, что теперь в ветке master содержатся все изменения репозитория.
Во-вторых, обрати внимание, как изменились цвета коммитов. Мы ввели цветовую дифференциацию, чтобы помочь пониманию. У каждой ветки — свой цвет. Каждый коммит становится того цвета, какого его ветка. Если в нём изменения сразу двух веток — он становится цветом, смешанным из цветов родительских веток.
И вот мы видим, что цвет ветки master подмешан к каждому коммиту, а ветки bugFix — нет. Это можно поправить.
Смерджим ветку master в ветку bugFix
|
1 2 |
git checkout bugFix git merge master |
Так как ветка bugFix была предшественницей master, Git не делал ничего, только сдвинул bugFix на тот же коммит, где находится master
Теперь все коммиты одного цвета, что означает, что каждая ветка содержит все изменения репозитория!
git rebase [name] — У нас здесь снова две ветки. Обрати внимание, что выбрана ветка bugFix (отмечена звёздочкой)
Хочется сдвинуть наши изменения из bugFix прямо на вершину ветки master. Благодаря этому всё будет выглядеть, как будто эти изменения делались последовательно, хотя на самом деле — параллельно.
|
1 |
git rebase master |
Теперь изменения из bugFix находятся в конце ветки master и являют собой линейную последовательность коммитов.
Обрати внимание, что коммит С3 до сих пор существует где-то, а С3′ — это его «копия» в ветке master
Единственная проблема — ветка master не обновлена до последних изменений. Это легко исправить.
Вот мы выбрали ветку master. Вперёд — сделаем rebase на bugFix
|
1 |
git rebase bugFix |
Так как master был предком bugFix, git просто сдвинул ссылку на master вперёд.
HEAD — это символическое имя текущего выбранного коммита — это, по сути, тот коммит, над которым мы в данным момент работаем.
HEAD всегда указывает на последний коммит из вашего локального дерева. Большинство команд Git, изменяющих рабочее дерево, начнут с изменения HEAD.
Обычно HEAD указывает на имя ветки (например, bugFix). Когда вы делаете коммит, статус ветки bugFix меняется и это изменение видно через HEAD.
git checkout [name] — Detaching HEAD Отделение (detaching) HEAD означает лишь присвоение его не ветке, а конкретному коммиту. Посмотрим, что было до отделения:
|
1 |
git checkout C1 |
Относительные ссылки —
master^ означает «первый предок ветки master«.
master^^ означает предок предка ветки master
|
1 |
git checkout master^ |
|
1 |
git checkout HEAD~4 |
git branch -f [name] [name] — Перемещение ветки (branch forcing), переставляет например master на commit с указанным хешом, вместо хеша можно использовать относительные ссылки
|
1 |
git branch -f master HEAD~3 |
Относительная ссылка дала нам возможность просто сослаться на C1, а branch forcing (-f) позволил быстро переместить указатель ветки на этот коммит.
git reset [name] — git reset отменяет изменения, перенося ссылку на ветку назад, на более старый коммит. Это своего рода «переписывание истории»; git reset перенесёт ветку назад, как будто некоторых коммитов вовсе и не было.
|
1 |
git reset HEAD~1 |
Reset отлично работает на локальных ветках, в локальных репозиториях. Но этот метод переписывания истории не сработает на удалённых ветках, которые используют другие пользователи.
git revert [name] — Чтобы отменить изменения и поделиться отменёнными изменениями с остальными, надо использовать git revert.
|
1 |
git revert HEAD |
появился новый коммит. Дело в том, что новый коммит C2′ просто содержит изменения, полностью противоположные тем, что сделаны в коммите C2.
После revert можно сделать push и поделиться изменениями с остальными.
git cherry-pick <Commit1> <Commit2> <…> — Это очень простой и прямолинейный способ сказать, что ты хочешь копировать несколько коммитов на место, где сейчас находишься (HEAD). Вот репозиторий, где есть некие изменения в ветке side, которые мы хотим применить и в ветку master.
|
1 |
git cherry-pick C2 C4 |
git rebase -i [name]~4 — появится окно интерактивного rebase. Переставь несколько коммитов (или удали кое-какие) — переставил местами С2 и С3, С4 удалил
|
1 |
git rebase -i HEAD~4 |
git tag [name] [hash] – ссылаться постоянно на конкретный коммит.
Создадим тег на C1, который будет нашей версией 1
|
1 |
git tag v1 C1 |
Мы назвали тег v1 и заставили его ссылаться на C1 явным образом. Если конкретный коммит не указан, гит пометит тегом HEAD
git describe <ref> — Git describe.
Где ref — это что-либо, что указывает на конкретный коммит. Если не указать ref, то git будет считать, что указано текущее положение (HEAD).
Вывод команды выглядит примерно так:
<tag>_<numCommits>_g<hash>
Где tag – это ближайший тег в истории изменений, numCommits – это на сколько далеко мы от этого тега, а hash – это хеш коммита, который описывается.
Команда git describe master выведет:
v1_2_gC2
Тогда как git describe side выведет:
v2_1_gC4
git clone — это команда, которая создаст локальную копию удалённого репозитория (например, с GitHub).
|
1 |
git clone |
git fetch — извлекать данные из удалённого репозитория.
git fetch — связывается с указанным удалённым репозиторием и забирает все те данные проекта, которых у вас ещё нет, при этом…
у вас должны появиться ссылки на все ветки из этого удалённого репозитория (например, o/master)
Фактически, git fetch синхронизирует локальное представление удалённых репозиториев с тем, что является актуальным на текущий момент времени.
Не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент.
|
1 |
git fetch |
git pull — скачивания (fetching) изменений с удалённой ветки и объединения (merging)
|
1 |
git pull |
git push — отвечает за загрузку ваших изменений в указанный удалённый репозиторий, а также включение ваших коммитов в состав удалённого репозитория.
|
1 |
git push |
удалённый репозиторий получил новый коммит C2, ветка master на удалённом репозитории теперь указывает на C2, и наше собственное локальное отображение удалённого репозитория (o/master) изменилось соответственно. Всё синхронизировалось!
