Правила хорошего тона при работе с git в многопользовательском окружении Данное повествование подразумевает знакомство читателей с такими командами git как: add, pull, push, commit.

В случае многопользовательской работы с репозиторием зачастую получается такая ситуация: сделали мы git pull, правим код, коммитим, хотим пропихнуть код в общий репозиторий, а тут-то нам и говорят: фигу вам, а не push — там уже всё поменялось. В итоге приходится делать git pull, получается вынужденный автоматический merge и с этим уродливым merge (который был по сути и необязателен!) мы запихиваем наши изменения обратно в общий репозиторий. История изменений получается не самая красивая.

Ниже будет рассказано о том, как же можно избежать подобных конфузов и прослыть знатоком git kung-fu. Рассовываем всё по карманам или git stash

Существует замечательная команда: git stash. Дословно, stash — припрятывать, тайник. Команда позволяет сохранять локальные незакоммиченные изменения, сбрасывая при этом состояние рабочей копии до HEAD’а. То есть, сказав git stash мы “припрятываем” все локальные изменения, получая чистую рабочую копию, в которую можно смело делать git pull не опасаясь возникновения ненужных merge’й.

После получения из репозитория-origin’а всех новых изменений мы можем смело “достать” “припрятанные” изменения и наложить их на текущую рабочую копию командой git stash apply.

Убедившись в успешном наложении изменений, можно сделать долгожданный git add -u, git commit и git push, после чего (или сразу после git stash apply) можно со спокойной совестью грохать сохранённые изменения командой git stash drop.

Более подробно о команде stash:

git stash : добавить текущие незакоммиченные изменения в стек изменений и сбросить текущую рабочую копию до HEAD’а репозитория;

git stash list : показать все изменения в стеке;

git stash show : показать последнее измененеие в стеке (патч);

git stash apply : применить последнее изменение из стека к текущей рабочей копии;

git stash drop : удалить последнее изменение в стеке;

git stash pop : применить последнее изменение из стека к текущей рабочей копии и удалить его из стека;

git stash clear : очистить стек изменений.

Полный синтаксис смотреть командой git help stash (или man git-stash). Не стесняемся ветвиться

Ещё более удобной возможностью одновременной работы над множеством разных фич является использованием бранчей в git. Бранчи там реализованы просто божественно, использовать их — одно удовольствие.

Как это делаю я: когда надо закрыть какой-нибудь баг, или реализовать определённую фичу, я просто завожу под это дело отдельный бранч. Бранч можно создать двумя способами, какой из них использовать — вопрос персональных предпочтений. Расскажу об обоих по порядку. Создаём branch

Первый вариант создания — команда git branch имя_бранча. Создаёт локальный бранч с указанным именем. Просмотреть существующие бранчи в репозитории можно командой git branch (можно добавить опцию -v для вывода также текущего HEAD’а каждого из бранчей).

После создания бранча надо переключиться на него, то есть, привести рабочую копию в соответствии с HEAD’ом этого бранча и указать репозиторию, что все действия необходимо вести именно с этим бранчем. Такое переключение осуществляется командой git checkout имя_бранча.

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

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

Работа с бранчем рано или поздно должна завершиться переносом всех изменений из этого бранча в master. Для начала рассмотрим простейший вариант: есть основная ветка master с ревизиями a-b-c, мы создаём бранч bug1, вносим в него изменения и коммитим их: в бранче bug1 порядок ревизий стал a-b-c-d. Сейчас, чтобы перенести ревизию d в бранч master, мы выполняем следующую последовательность команд:

git checkout master # переключились на бранч master git merge bug1 # выполняем слияние с бранчем bug1

Так как последовательность изменений из бранча bug1 однозначно накладывается на последовательность из бранча master, выполняемый merge будет определён как fast-forward, то есть история будет без лишних ветвлений, а итоговая последовательность изменений в master’е выглядит так: a-b-c-d.

После успешного наложения всех изменений из бранча bug1 его можно безболезненно удалить командой git branch -d bug1. Полезной особенностью этой команды является проверка на наличие всех изменений удаляемой ветки в master’е — если изменения перенесены не все, команда откажется удалять ветку. Трансплантация истории

Рассмотрим более сложный, но более близкий к реальности вариант: параллельное внесение изменений в основную ветку репозитория и отдельном бранче. Исходные данные аналогичны предыдущему примеру: master с историей изменений a-b-c, и ветка bug1 с добавленным изменением d, то есть история для неё a-b-c-d.

Предположим, пока мы занимались работой над багом, кто-то другой успел реализовать какую-нибудь фичу и пропихнуть её в основной репозиторий. Теперь, переключившись из бранча bug1 в master, и выполнив в master’е git pull, мы получаем в нём такую историю: a-b-c-E, где E — это коммит с реализацией той фичи, которую успел закоммитить другой программист.

Если сейчас находясь в ветке master выполнить git merge bug1, мы получим историю изменений раздваивающуюся после коммита c на 2 ветви и заканчивающуюся автоматическим слиянием веток, родителями этого merge-коммита будут ревизии E (из master’а) и d (из бранча bug1). Избежать подобной ветвистости помогает волшебная команда git rebase.

git rebase — инструмент для “пересадки” веток истории изменений. В нашем примере, имея в master историю a-b-c-E, мы можем “пересадить” кусок истории c-d из бранча bug1 после коммита E. Проделать это можно так:

git checkout bug1 # переключаемся на бранч bug1 git rebase master # пересадить историю изменений

Остановимся на последней команде подробнее. git rebase берёт ветку истории из текущего бранча, отличающуюся от истории бранча, указанного в качестве параметра (master), и “пересаживает” эту ветку поверх подтянутой истории (master’а). То есть, история изменений для бранча bug1 после выполнения этой команды будет выглядеть так: a-b-c-E-D.

Необходимо обратить внимание на то, что получившееся изменение D отличается от исходного изменения d своим идентификатором, хотя и сохраняет такие атрибуты как дата, текст и патч. То есть, это уже фактически другая ревизия, а с номерами ревизий “играть” по-хорошему допускается только локально.

Имея в master’е историю a-b-c-E, а в бранче bug1 историю a-b-c-E-D, несложно выполнить fast-forward merge, сохранив “прямую” историю без ненужных ветвлений:

git checkout master git merge bug1

Результатом получаем master с красивой историей a-b-c-E-D.

Более подробная информация с картинками есть в увлекательной документации: git help rebase (или man git-rebase).

Источник: http://www.evasive.ru/articles/git_kung-fu.html