- •3 Работа с репозитарием
- •4 Общественные репозитарии
- •1 Введение
- •2.2.3 Git merge — слияние веток (разрешение возможных конфликтов).
- •2.2.4 Git rebase — построение ровной линии коммитов
- •2.3.2 Git tag — тэги как способ пометить уникальный коммит
- •2.3.3 Относительная адресация
- •2.3.4 Файл .Gitignore — объясняем git, какие файлы следует игнорировать
- •3.4 Git push — вносим изменения в удаленный репозитарий (удаленную ветку)
3.4 Git push — вносим изменения в удаленный репозитарий (удаленную ветку)
После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозитарий (удаленную ветку). Для этого используется команда git push: git push — отправить свои изменения в удаленную ветку, созданную при клонировании по умолчанию. git push ssh://yourserver.com/~you/proj.git master:experimental — отправить изменения из ветки master в ветку experimental удаленного репозитария. git push origin :experimental — в удаленном репозитарии origin удалить ветку experimental. git push origin master:master — в удаленную ветку master репозитария origin (синоним репозитария по умолчанию) ветки локальной ветки master.
4 git-о-день
В этом разделе будут показаны и разобраны подробно несколько обычных и чуть меньше необычных для работы с git ситуаций.
4.1 Обычный workflow при работе с локальным репозитарием
Git обладает необычайной легкостью в использовании не только как распределенная система контроля версий, но и в работе с локальными проектами. Давайте разберем обычный цикл — начиная с создания репозитария — работы разработчика git над собственным персональным проектом:
mkdir git-demo
cd git-demo
git init
git add.
git commit -m «initial commit»
git branch new-feature
git checkout new-feature
git add.
git commit -m «Done with the new feature»
git checkout master
git diff HEAD new-feature
git merge new-feature
git branch -d new-feature
git log --since=«1 day»
Разберем каждое из действий. 1-2 — просто создаем рабочую директорию проекта. 3 — создаем репозитарий в директории. 4 — индексируем все существующие файлы проекта (если, конечно, они вообще были). 5 — создаем инициализирующий коммит. 6 — новая ветка, 7 — переключение в нее (можно сделать в один шаг командой git checkout -b new-feature). Далее, после непосредственной работы с кодом, индексируем внесенные изменения(8), совершаем коммит(9). Переключаемся в основную ветку(10), смотрим отличия между последним коммитом активной ветки и последним коммитом экспериментальной (11). Проводим слияние (12) и, если не было никаких конфликтов, удаляем ненужную больше ветку (13). Ну и на всякий случай оценим проведенную за последний день работу (14). Почему именно так? Зачем отказываться от линейной модели? Хотя бы даже потому, что у программиста появляется дополнительная гибкость: он может переключаться между задачами (ветками); под рукой всегда остается «чистовик» — ветка master; коммиты становятся мельче и точнее.
4.2 Workflow при работе с удаленным репозитарием
Предположим, что вы и несколько ваших напарников создали общественный репозитарий, чтобы заняться неким общим проектом. Как выглядит самая распространенная для git модель общей работы?
git clone http://yourserver.com/~you/proj.git … возможно, прошло некоторое время.
git pull
git diff HEAD^
git checkout -b bad-feature … работаем некоторое время.
git commit -a -m «Created a bad feature»
git checkout master
git pull
git merge bad-feature
git commit -a
git diff HEAD^ … запускаем тесты проекта, обнаруживаем, что где-то произошла ошибка. Упс.
git reset --hard ORIG_HEAD
git checkout bad-feature … исправляем ошибку.
git -m bad-feature good-feature
git commit -a -m «Better feature»
git checkout master
git pull
git merge good-feature
git push
git branch -d good-feature
Итак, первым делом создаем (1) создаем копию удаленного репозитария (по умолчанию команды вроде git pull и git push будут работать с ним). «Вытягиваем» последние обновления (2); смотрим, что же изменилось(3); создаем новую ветвь и переключаемся в нее (4); индексируем все изменения и одновременно создаем из них коммит (5); переключаемся в главную ветвь (6), обновляем ее (7); проводим слияние с веткой bad-feature(8) и, обнаружив и разрешив конфликт, делаем коммит слияния (9). После совершения коммита отслеживаем изменения(10), запускаем, например, юнит-тесты и с ужасом обнаруживаем, что после слияния проект валится на большей части тестов. В принципе, тесты можно было прогнать и до коммита, в момент слияния (между пунктами 8 и 9); тогда бы хватило «мягкого» резета. Таким образом, приходится совершить «жесткий» (11) сброс произошедшего слияния, ветки вернулись в исходное до состояние. После чего переключаемся в неудачную ветку (12), вносим необходимые изменения и переименовываем ветку (13). Совершаем коммит (14); переходим в главную ветку(15), опять ее обновляем (16). На этот раз бесконфликтно делаем слияние (17), закидываем изменения в удаленный репозитарий (18) и удаляем ненужную теперь ветку (19). Закрываем ноутбук, одеваемся и идем домой под утро.