Git

Материалы взяты с сайта http://learngitbranching.js.org/

git commit — совершаем commit, сохранение в текущей ветки

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


git commit —amend — Изменение последнего коммита


git branch [name] — создание ветки по имени newImage, до этого была ветка master

Ветка newImage теперь указывает на коммит C1


git checkout [name] — переключение на ветку newImage и  commit ее


git merge [name] — Вот у нас две ветки, каждая содержит по одному уникальному коммиту. Это означает, что ни одна из веток не содержит полный набор «работ», выполненных в этом репозитории. Можно исправить эту ситуацию, выполнив слияние.

Мы сделаем merge ветки bugFix в ветку master

Что мы видим? Во-первых, ветка master теперь указывает на коммит, у которого два родителя. Если проследовать по стрелкам от этого коммита, вы пройдёте через каждый коммит в дереве прямиком к началу. Это означает, что теперь в ветке master содержатся все изменения репозитория.

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

И вот мы видим, что цвет ветки master подмешан к каждому коммиту, а ветки bugFix — нет. Это можно поправить.

Смерджим ветку master в ветку bugFix

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

Теперь все коммиты одного цвета, что означает, что каждая ветка содержит все изменения репозитория!


git rebase [name] — У нас здесь снова две ветки. Обрати внимание, что выбрана ветка bugFix (отмечена звёздочкой)

Хочется сдвинуть наши изменения из bugFix прямо на вершину ветки master. Благодаря этому всё будет выглядеть, как будто эти изменения делались последовательно, хотя на самом деле — параллельно.

Теперь изменения из bugFix находятся в конце ветки master и являют собой линейную последовательность коммитов.

Обрати внимание, что коммит С3 до сих пор существует где-то, а С3′ — это его «копия» в ветке master

Единственная проблема — ветка master не обновлена до последних изменений. Это легко исправить.

Вот мы выбрали ветку master. Вперёд — сделаем rebase на bugFix

Так как master был предком bugFix, git просто сдвинул ссылку на master вперёд.

 


HEAD — это символическое имя текущего выбранного коммита — это, по сути, тот коммит, над которым мы в данным момент работаем.

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

Обычно HEAD указывает на имя ветки (например, bugFix). Когда вы делаете коммит, статус ветки bugFix меняется и это изменение видно через HEAD.


git checkout [name] — Detaching HEAD Отделение (detaching) HEAD означает лишь присвоение его не ветке, а конкретному коммиту. Посмотрим, что было до отделения:

Относительные ссылки — 

master^ означает «первый предок ветки master«.

master^^ означает предок предка ветки master

git branch -f [name] [name] — Перемещение ветки (branch forcing), переставляет например master на commit с указанным хешом, вместо хеша можно использовать относительные ссылки

Относительная ссылка дала нам возможность просто сослаться на C1, а branch forcing (-f) позволил быстро переместить указатель ветки на этот коммит.


git reset [name] — git reset отменяет изменения, перенося ссылку на ветку назад, на более старый коммит. Это своего рода «переписывание истории»; git reset перенесёт ветку назад, как будто некоторых коммитов вовсе и не было.

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


git revert [name] — Чтобы отменить изменения и поделиться отменёнными изменениями с остальными, надо использовать git revert.

появился новый коммит. Дело в том, что новый коммит C2′ просто содержит изменения, полностью противоположные тем, что сделаны в коммите C2.

После revert можно сделать push и поделиться изменениями с остальными.


git cherry-pick <Commit1> <Commit2> <…> — Это очень простой и прямолинейный способ сказать, что ты хочешь копировать несколько коммитов на место, где сейчас находишься (HEAD). Вот репозиторий, где есть некие изменения в ветке side, которые мы хотим применить и в ветку master.


git rebase -i [name]~4 — появится окно интерактивного rebase. Переставь несколько коммитов (или удали кое-какие) — переставил местами С2 и С3, С4 удалил


git tag [name] [hash] – ссылаться постоянно на конкретный коммит.

Создадим тег на C1, который будет нашей версией 1

Мы назвали тег 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).


git fetch — извлекать данные из удалённого репозитория.

git fetch — связывается с указанным удалённым репозиторием и забирает все те данные проекта, которых у вас ещё нет, при этом…
у вас должны появиться ссылки на все ветки из этого удалённого репозитория (например, o/master)
Фактически, git fetch синхронизирует локальное представление удалённых репозиториев с тем, что является актуальным на текущий момент времени.
Не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент.


git pull — скачивания (fetching) изменений с удалённой ветки и объединения (merging)


git push — отвечает за загрузку ваших изменений в указанный удалённый репозиторий, а также включение ваших коммитов в состав удалённого репозитория.

удалённый репозиторий получил новый коммит C2, ветка master на удалённом репозитории теперь указывает на C2, и наше собственное локальное отображение удалённого репозитория (o/master) изменилось соответственно. Всё синхронизировалось!