Моя шпаргалка по работе с Git
Некоторое время назад я открыл для себя Git. И знаете, я проникся. То есть, по-настоящему проникся. Теперь я использую Git не только на работе (где я с ним, собственно, познакомился), но и для своих проектиков, которые я стал хранить на BitBucket. Последний начал поддерживать Git относительно недавно. В отличии от GitHub, BitBucket позволяет совершенно бесплатно создавать как открытые, так и закрытые репозитории.
В чем состоит отличие Git от Subversion?
Главное отличие Git от Subversion заключается в том, что Git — распределенная система контроля версий. Звучит ужасающе, но на практике это означает очень простую вещь. Каждый разработчик держит у себя на диске отдельный репозиторий. Обратите внимание — не копию репозитория, не некоторые бранчи, а тупо отдельный и при этом абсолютно полноценный репозиторий.
Пока мы работаем в рамках своего репозитория, все происходит в точности, как в Subversion. Мы коммитим и откатываем изменения, создаем, мерджим и удаляем бранчи, разрешаем конфликты и тд. Помимо этого, предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает мердж локальных изменений в удаленный репозиторий, а «git pull» — наоборот, мердж изменений из удаленного репозитория в локальный. Обмен данными по сети обычно происходит с использованием протокола SSH.
В результате имеем:
- Git присущи все те же преимущества от использования VCS, что мы получаем в Subversion.
- Git дает нам нормальное шифрование «из коробки», безо всяких танцев с бубнами, как в случае с Subversion.
- Если сервер с «главным» репозиторием, куда пушат свои изменения все разработчики (хотя формально в Git нет никакого «главного» репозитория), вдруг прилег — ничего страшного. Делаем коммиты в локальный репозиторий и ждем, когда сервер вернется.
- Даже если сервер доступен, все равно удобнее сделать пяток локальных коммитов, а затем отправить их на сервер одним пушем.
- Сервер вообще не нужен. Вы можете использовать Git только локально. И не обязательно для работы с исходниками. Например, можно использовать Git для того, чтобы иметь возможность откатиться к предыдущим версиям файлов (каких-нибудь электронных таблиц) или вернуть случайно удаленные. А в этой заметке рассказывается, как хранить git-репозиторий на флешке.
- Git не раскидывает по каталогам служебную информацию (помните «.svn»?), вместо этого она хранится только в корне репозитория.
- Git нынче очень моден (хотя это далеко не единственная распределенная система контроля версий, например, есть Mercurial и Darcs), в связи с чем растет число разработчиков, использующих его. Как следствие, используя Git, легче получить помощь на каком-нибудь форуме или собрать команду разработчиков, знакомых с этой VCS.
- Существует множество полезных утилит для работы с Git — Qgit, gitk, gitweb и другие. «Из коробки» есть импорт и экспорт в/из Subversion/CVS.
- Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Google Code, …) — есть из чего выбрать.
- Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего OpenSource проекта.
Пример использования Git
Я использовал Git при написании программы из заметки Генерация почти осмысленных текстов на Haskell, сидя под своей любимой FreeBSD. Вот как примерно выглядела моя работа с Git.
В первую очередь необходимо поставить Git:
Затем создаем пару ssh ключей, если не создавали ее ранее:
cat ~/.ssh/id_rsa.pub
Заходим на БитБакет, создаем git-репозиторий под новый проект, а в свойствах аккаунта прописываем свой открытый ssh-ключ. Затем клонируем репозиторий:
git clone git@bitbucket.org:afiskon/hs-textgen.git
cd hs-textgen
Делаем какие-то изменения:
Добавляем новый файл в репозиторий и делаем коммит:
git commit -a
Поскольку я не указал описание коммита, запускается редактор VIM, с помощью которого я и ввожу описание. Затем я отправляю все сделанные мною изменения на БитБакет:
Допустим, теперь я хочу сделать некоторые изменения в проекте, но не уверен, выйдет ли из этого что-то хорошее. В таких случаях создается новая ветка:
git checkout new_feature
Работаем с этой веткой. Если ничего хорошего не вышло, возвращаемся к основной ветке (она же «trunk» или «ствол»):
Если вышло что-то хорошее, мерджим ветку в master (о разрешении конфликтов рассказано в следующем параграфе):
git checkout master # переключаемся на master
git merge new_feature # мерджим ветку new_feature
Не забываем время от времени отправлять наш код на BitBucket:
Если мы правим код с нескольких компьютеров, то перед началом работы не забываем «накатить» в локальный репозиторий последнюю версию кода:
Работа в команде мало чем отличается от описанного выше. Только каждый программист должен работать со своей веткой, чтобы не мешать другим программистам. Одна из классических ошибок при начале работы с Git заключается в push’е всех веток, а не только той, с которой вы работали. Вообще я бы советовал первое время перед выполнением каждого push делать паузу с тем, чтобы подумать, что и куда сейчас уйдет. Для большей безопасности советую при генерации ssh-ключей указать пароль. Тогда каждый запрос пароля со стороны Git будет для вас сигналом «Эй, ты делаешь что-то, что затронет других».
Для работы с Git под Windows можно воспользоваться клиентом TortoiseGit. Если память не изменяет, для нормальной работы ему нужен MSysGit. Для генерации ключей можно воспользоваться утилитой PuTTyGen, только не забудьте экспортировать открытый ключ в правильном формате, «Conversions → Export OpenSSH key».
Следует отметить, что мне лично TortoiseGit показался каким-то глючноватым и вообще не слишком удобным. Возможно, это всего лишь дело привычки, но мне кажется намного удобнее работать с Git из консоли, чем с помощью контекстного меню в Проводнике. Так что по возможности я бы советовал работать с Git в Юниксах. В крайнем случае можно поставить виртуальную машину, установить под ней FreeBSD (безо всяких GUI) и работать в этой виртуальной машине.
Шпаргалка по командам
В этом параграфе приведена сухая шпаргалка по командам Git. Я далеко не спец в этой системе контроля версий, так что ошибки в терминологии или еще в чем-то вполне возможны. Если вы видите в этом разделе ошибку, отпишитесь, пожалуйста, в комментариях.
Создать новый репозиторий:
Клонировать репозиторий с удаленной машины:
Добавить файл в репозиторий:
Текущее состояние репозитория (изменения, неразрешенные конфликты и тп):
Сделать коммит:
Сделать коммит, введя его описание с помощью $EDITOR:
Замерджить все ветки локального репозитория на удаленный репозиторий:
Аналогично предыдущему, но делается пуш только ветки master:
Замерджить все ветки с удаленного репозитория:
Аналогично предыдущему, но «накатывается» только ветка master:
Скачать все ветки с origin, но не мерджить их в локальный репозиторий:
Аналогично предыдущему, но только для одной заданной ветки:
Начать работать с веткой some_branch (уже существующей):
Создать новый бранч (ответвится от текущего):
Переключиться на другую ветку (из тех, с которыми уже работаем):
Получаем список веток, с которыми работаем:
Просмотреть все существующие ветви:
Замерджить some_branch в текущую ветку:
Удалить бранч (после мерджа):
Просто удалить бранч (тупиковая ветвь):
Последние изменения:
История конкретного файла:
Аналогично предыдущему, но с просмотром сделанных изменений:
Посмотреть, кем в последний раз правилась каждая строка файла:
Откатиться к конкретному коммиту (хэш смотрим в «git log»):
Аналогично предыдущему, но файлы на диске остаются без изменений:
Попытаться обратить заданный commit (но чаще используется branch/reset + merge):
Просмотр изменений (суммарных, а не всех по очереди, как в «git log»):
Используем vimdiff в качестве программы для разрешения конфликтов (mergetool) по умолчанию:
Отключаем диалог «какой mergetool вы хотели бы использовать»:
Разрешение конфликтов (когда оные возникают в результате мерджа):
Создание тэга:
Следует отметить, что Git позволяет использовать короткую запись хэшей. Вместо «d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4» можно писать «d8578edf» или даже «d857».
Дополнительные материалы
В качестве источников дополнительной информации я бы рекомендовал следующие:
- Why Git is Better than X;
- Хабростатья «Почему Git?»;
- Хабровопрос о преимуществах Git и других DVCS;
- Книга «Pro Git» на русском языке;
- Книга «Волшебство Git» на русском языке;
- How To Create a Remote Shared Git Repository;
Как обычно, любые замечания, дополнения и вопросы категорически приветствуются. И кстати, с наступающим вас!
Дополнение: См также заметку Как я выбирал между GitHub и BitBucket.