4 Общественные репозитарии

Общественный репозитарий — способ обмениваться кодом в проектах, где участвует больше двух человек. Лично я использую сайт github.com, настолько удобный, что многие начинают из-за него пользоваться git. Итак, создаем у себя копию удаленного репозитария: git clone git://github.com/username/project.git master Команда создала у вас репозитарий, и внесла туда копию ветки master проекта project. Теперь можно начинать работу. Создадим новую ветку, внесем в нее изменения, закоммитимся: git branch new-feature  edit README  git add .  git commit -m "Added a super feature" Перейдем в основную ветку, заберем последние изменения в проекте, и попробуем добавить новую фишку в проект: git checkout master  git pull  git merge new-feature Если не было неразрешенных конфликтов, то коммит слияния готов. Команда git pull использует так называемую удаленную ветку (remote branch), создаваемую при клонировании удаленного репозитария. Из нее она извлекает последние изменения и проводит слияние с активной веткой. Теперь остается только занести изменения в центральный (условно) репозитарий: git push Нельзя не оценить всю гибкость, предоставляемую таким средством. Можно вести несколько веток, отсылать только определенную, жонглировать коммитами как угодно. В принципе, никто не мешает разработать альтернативную модель разработки. Например, использовать иерархическую систему репозитариев, когда «младшие» разработчики делают коммиты в промежуточные репозитарии, где те проходят проверку у «старших» программистов и только потом попадают в главную ветку центрального репозитария проекта. При работе в парах возможно использовать симметричную схему работы. Каждый разработчик ведет по два репозитария: рабочий и общественный. Первый используется в работе непосредственно, второй же, доступный извне, только для обмена уже законченным кодом.

http://habrahabr.ru/post/60347/

1 Введение

В своей прошлой заметке я постарался осветить в общих чертах стиль работы с распределенной системой контроля версий git и указать на отличия по сравнению с классическими централизованными СКВ. Целью было прежде всего обобщение опыта работы с системой без упоминания тонкостей синтаксиса отдельных команд. Данный же топик задумывался как непосредственное введение в работу с git, нечто среднее между tutorial и обобщенной справкой, до которого все же рекомендуется прочитать упомянутое выше введение. Сознательно избегаются технические подробности работы git, употребляются только общие для СКВ термины и ограничивается список упоминаемых команд.

2 Работа с локальным репозитарием

Сила любых распределенных систем — в наличии у каждого разработчика локального репозитария, в котором возможно организовывать произвольную личную схему разработки. В git есть несколько основных команды для ведения работы на месте и множество вспомогательных.

2.1 Базовые команды

Базовые команды — те, без которых невозможно обойтись в разработке.

2.1.1 git init — создание репозитария

Команда git init создает в директории пустой репозитарий в виде директория .git, где и будет в дальнейшем храниться вся информация об истории коммитов, тегах — ходе разработки проекта: mkdir project-dir cd project-dir git init Другой способ создать репозитарий — команда git clone, но о ней чуть позже.

2.1.2 git add и git rm — индексация изменений

Следующее, что нужно знать — команда git add. Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит. Примеры использования: git add EDITEDFILE — индексация измененного файла, либо оповещение о создании нового. git add. — внести в индекс все изменения, включая новые файлы. Из индекса и дерева одновременно проекта файл можно удалить командой git rm: git rm FILE1 FILE2 — отдельные файлы git rm Documentation/\*.txt — хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки. Сбросить весь индекс или удалить из него изменения определенного файла можно командой git reset: git reset — сбросить нафиг весь индекс. git reset — EDITEDFILE — удалить из индекса конкретный файл. Команда git reset используется не только для сбрасывания индекса, поэтому дальше ей будет уделено гораздо больше внимания. 

2.1.3 git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы

Команда git status, пожалуй, можно считать самой часто используемой наряду с командами коммита и индексации. Она выводит информацию обо всех изменениях, внесенных в дерево директорий проекта по сравнению с последним коммитом рабочей ветки; отдельно выводятся внесенные в индекс и неиндексированные файлы. Использовать ее крайне просто: git status Кроме того, git status указывает файлы с неразрешенными конфликтами слияния и файлы, игнорируемые git.

2.1.4 git commit — совершение коммита

Коммиты — базовое понятие во всех системах контроля версий, поэтому совершатся он должен легко и по возможности быстро. В самом своем простом виде достаточно после индексации набрать:  git commit Если индекс не пустой, то на его основе будет совершен коммит, после чего пользователя попросят прокомментировать вносимые изменения вызовом команды edit(например, в Ubuntu обычно вызывается простенький текстовый редактор nano, у меня же — emacs). Сохраняемся, и вуала! Коммит готов. Есть несколько ключей, упрощающих работу с git commit: git commit -a — совершит коммит, автоматически индексируя изменения в файлах проекта. Новые файлы при этом индексироваться не будут! Удаление же файлов будет учтено. git commit -m «commit comment» — комментируем коммит прямо из командной строки вместо текстового редактора. git commit FILENAME — внесет в индекс и создаст коммит на основе изменений единственного файла. 

2.1.5 git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»

Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset). «Мягкий» (с ключом "--soft") резет оставит нетронутыми ваши индекс и все дерево файлов и директорий проекта, вернется к работе с указанным коммитом. Иными словами, если вы обнаруживаете ошибку в только что совершенном коммите или комментарии к нему, то легко можно исправить ситуацию:

1. git commit… — некорректный коммит; 

2. git reset --soft HEAD^ — переходим к работе над уже совершенным коммитом, сохраняя все состояние проекта и проиндексированные файлы 

3. edit WRONGFILE 

4. edit ANOTHERWRONGFILE 

5. add.

6.1. git commit -c ORIG_HEAD — вернутся к последнему коммиту, будет предложено редактировать его сообщение. Если сообщение оставить прежним, то достаточно изменить регистр ключа -с: 6.2. git commit -C ORIG_HEAD Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит. Естественно, можно вернуться и на большую глубину коммитов, «Жесткий» резет (ключ --hard) — команда, которую следует использовать с осторожностью. Git reset --hard вернет дерево проекта и индекс в состояние, соответствующее указанному коммиту, удалив изменения последующих коммитов: git add. git commit -m «destined to death» git reset --hard HEAD~1 — больше никто и никогда не увидит этот позорный коммит. git reset --hard HEAD~3 — вернее, три последних коммита. Никто. Никогда. Если команда достигнет точки ветвления, удаления коммита не произойдет.  Для команд слияния или выкачивания последних изменений с удаленного репозитария примеры резета будут приведены в соответствующих разделах.

2.1.6 git revert — отмена изменений, произведенных в прошлом отдельным коммитом

Возможна ситуация, в которой требуется отменить изменения, внесенные отдельным коммитом. Git revert создает новый коммит, накладывающий обратные изменения: git revert config-modify-tag — отменяем коммит, помеченный тегом. git revert 12abacd — отменяем коммит, используя его хэш. Для использования команды необходимо, чтобы состояние проекта не отличалось от состояния, зафиксированного последним коммитом.

2.1.7 git log — разнообразная информация о коммитах в целом, по отдельным файлам и различной глубины погружения в историю

Иногда требуется получить информацию об истории коммитов, коммитах, изменивших отдельный файл; коммитах за определенный отрезок времени и так далее. Для этих целей используется команда git log. Простейший пример использования, в котором приводится короткая справка по всем коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении подробно узнать можно ниже, в разделе «Ветвления и слияния»): git log  Получить подробную информацию о каждом в виде патчей по файлам из коммитов можно, добавив ключ -p (или -u): git log -p Статистика изменения файлов, вроде числа измененных файлов, внесенных в них строк, удаленных файлов вызывается ключом --stat: git log --stat За информацию по созданиям, переименованиям и правам доступа файлов отвечает ключ --summary: git log --summary Для исследования истории отдельного файла достаточно указать в виде параметра его имя (кстати, в моей старой версии git этот способ не срабатывает, обязательно добавлять " — " перед «README»): git log README или, если версия git не совсем свежая: git log — README Далее будет приводится только более современный вариант синтаксиса. Возможно указывать время, начиная в определенного момента («weeks», «days», «hours», «s» и так далее): git log --since=«1 day 2 hours» README  git log --since=«2 hours» README  git log --since=«2 hours» dir/ — изменения, касающиеся отдельной папки. Можно отталкиваться от тегов: git log v1… — все коммиты, начиная с тега v1. git log v1… README — все коммиты, включающие изменения файла README, начиная с тега v1. git log v1..v2 README — все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2. Создание, выведение списка, назначение тегов будет приведено в соответствующем разделе ниже. Интересные возможности по формату вывода команды предоставляет ключ --pretty: git log --pretty=oneline — выведет на каждый из коммитов по строчке, состоящей из хэша (здесь — уникального идентификатора каждого коммита, подробней — дальше). git log --pretty=short — лаконичная информация о коммитах, приводятся только автор и комментарий git log --pretty=full/fuller — более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита В принципе, формат вывода можно определить самостоятельно:  git log --pretty=format:'FORMAT' Определение формата можно поискать в разделе по git log из Git Community Book или справке. Красивый ASCII-граф коммитов выводится с использованием ключа --graph.

2.1.8 git diff — отличия между деревьями проекта; коммитами; состоянием индекса и каким-либо коммитом.

Своего рода подмножеством команды git log можно считать команду git diff, определяющую изменения между объектами в проекте: деревьями (файлов и директорий): git diff — покажет изменения, не внесенные в индекс. git diff --cached — изменения, внесенные в индекс. git diff HEAD — изменения в проекте по сравнению с последним коммитом git diff HEAD^ — предпоследним коммитом Можно сравнивать «головы» веток: git diff master..experimental Ну или активную ветку с какой-либо: git diff experimental

2.1.9 git show — показать изменения, внесенные отдельным коммитом

Посмотреть изменения, внесенные любым коммитом в истории можно командой git show: git show COMMIT_TAG

2.1.10 git blame и git annotate — вспомогательные команды, помогающие отслеживать изменения файлов

При работе в команде часто требуется выяснить, кто именно написал конкретный код. Удобно использовать команду git blame, выводящую построчную информацию о последнем коммите, коснувшемся строки, имя автора и хэш коммита: git blame README Можно указать и конкретные строки для отображения: git blame -L 2,+3 README — выведет информацию по трем строкам, начиная со второй. Аналогично работает команда git annotate, выводящая и строки, и информацию о коммитах, их коснувшихся: git annotate README

2.1.11 git grep — поиск слов по проекту, состоянию проекта в прошлом

git grep, в целом, просто дублирует функционал знаменитой юниксовой команды. Однако, он позволяет слова и их сочетания искать в прошлом проекта, что бывает очень полезно: git grep tst — поиск слова tst в проекте. git grep -с tst — подсчитать число упоминаний tst в проекте. git grep tst v1 — поиск в старой версии проекта. Команда позволяет использовать логическое И и ИЛИ: git grep -e 'first' --and -e 'another' — найти строки, где упоминаются и первое слово, и второе. git grep --all-match -e 'first' -e 'second' — найти строки, где встречается хотя бы одно из слов.

2.2 Ветвление

Операции ветвления и слияния — сердце и душа git, именно эти возможности делают такой удобной работу с системой.

2.2.1 git branch — создание, перечисление и удаление веток

Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде: git branch — просто перечислит существующие ветки, отметив активную. git branch new-branch — создаст новую ветку new-branch. git branch -d new-branch — удалит ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую. git branch -D new-branch — удалит ветку в любом случае. git branch -m new-name-branch — переименует ветку. git branch --contains v1.2 — покажет те ветки, среди предков которых есть определенный коммит.

2.2.2 git checkout — переключение между ветками, извлечение отдельных файлов из истории коммитов

Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток: checkout some-other-branch checkout -b some-other-new-branch — создаст ветку, в которую и произойдет переключение. Если в текущей ветке были какие-то изменения по сравнению с последним коммитом в ветке(HEAD), то команда откажется производить переключение, дабы не потерять произведенную работу. Проигнорировать этот факт позволяет ключ -f: checkout -f some-other-branch В случае, когда изменения надо все же сохранить, используют ключ -m. Тогда команда перед переключением попробует залить изменения в текущую ветку и, после разрешения возможных конфликтов, переключиться в новую: checkout -m some-other-branch Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида: git checkout somefile — вернуть somefile к состоянию последнего коммита git checkout HEAD~2 somefile — вернуть somefile к состоянию на два коммита назад по ветке.