Некоторое время назад я открыл для себя 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 не раскидывает по каталогам служебную информацию (помните «.svn»?) , вместо этого она хранится только в корне репозитория.
- Git нынче очень моден (хотя это далеко не единственная распределенная система контроля версий, например, есть Mercurial и Darcs), в связи с чем растет число разработчиков, использующих его. Как следствие, используя Git, легче получить помощь на каком-нибудь форуме или собрать команду разработчиков, знакомых с этой VCS.
- Существует множество полезных утилит для работы с Git — Qgit, gitk, gitweb и другие. «Из коробки» есть импорт и экспорт в/из Subversion/CVS.
- Git поддерживают многие хостинги репозиториев ( GitHub , BitBucket , SourceForge , Google Code , … ) — есть из чего выбрать.
- Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего open source проекта.
Пример использования 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 . Если память не подводит, для работы ему нужен Git for Windows . Для генерации ключей можно воспользоваться утилитой PuTTyGen . Только не забудьте экспортировать открытый ключ в правильном формате, «Conversions → Export OpenSSH key».
Следует отметить, что мне лично TortoiseGit показался не слишком удобным. Возможно, это всего лишь дело привычки, но мне кажется намного удобнее работать с Git из консоли, чем с помощью контекстного меню в Проводнике.
Шпаргалка по командам
В этом параграфе приведена сухая шпаргалка по командам Git. Я далеко не спец в этой системе контроля версий, так что ошибки в терминологии или еще в чем-то вполне возможны. Если вы видите в этом разделе ошибку, отпишитесь, пожалуйста, в комментариях.
Создать новый репозиторий:
Если вы планируете клонировать его по ssh с удаленной машины, также скажите:
… иначе при git push вы будете получать странные ошибки вроде:
By default, updating the current branch in a non-bare repository
is denied, because it will make the index and work tree inconsistent
with what you pushed, and will require ‘git reset —hard’ to match
the work tree to HEAD.
Клонировать репозиторий с удаленной машины:
Если хотим пушить один код в несколько репозиториев:
Добавить файл в репозиторий:
Удалить файл:
Текущее состояние репозитория (изменения, неразрешенные конфликты и тп):
Сделать коммит:
Сделать коммит, введя его описание с помощью $EDITOR:
Замержить все ветки локального репозитория на удаленный репозиторий (аналогично вместо origin можно указать и remotename, см выше):
Аналогично предыдущему, но делается пуш только ветки master :
Запушить текущую ветку , не вводя целиком ее название:
Замержить все ветки с удаленного репозитория:
Аналогично предыдущему, но накатывается только ветка master:
Накатить текущую ветку, не вводя ее длинное имя:
Скачать все ветки с origin, но не мержить их в локальный репозиторий:
Аналогично предыдущему, но только для одной заданной ветки:
Начать работать с веткой some_branch (уже существующей):
Создать новый бранч (ответвится от текущего):
Переключиться на другую ветку (из тех, с которыми уже работаем):
Получаем список веток, с которыми работаем:
Просмотреть все существующие ветви:
Замержить some_branch в текущую ветку:
Удалить бранч (после мержа):
Просто удалить бранч (тупиковая ветвь):
История изменений:
История изменений в обратном порядке:
История конкретного файла:
Аналогично предыдущему, но с просмотром сделанных изменений:
История с именами файлов и псевдографическим изображением бранчей:
Изменения, сделанные в заданном коммите:
Посмотреть, кем в последний раз правилась каждая строка файла:
Удалить бранч из репозитория на сервере:
Откатиться к конкретному коммиту (хэш смотрим в «git log»):
Аналогично предыдущему, но файлы на диске остаются без изменений:
Попытаться обратить заданный commit:
Просмотр изменений (суммарных, а не всех по очереди, как в «git log»):
Используем vimdiff в качестве программы для разрешения конфликтов (mergetool) по умолчанию:
Отключаем диалог «какой mergetool вы хотели бы использовать»:
Отображаем табы как 4 пробела, например, в «git diff»:
Создание глобального файла .gitignore :
Разрешение конфликтов (когда оные возникают в результате мержа):
Создание тэга:
Удаление untracked files:
«Упаковка» репозитория для увеличения скорости работы с ним:
Иногда требуется создать копию репозитория или перенести его с одной машины на другую. Это делается примерно так:
cd / tmp / git-copy
git clone —bare git @ example.com:afiskon / cpp-opengl-tutorial1.git
cd cpp-opengl-tutorial1.git
git push —mirror git @ example.com:afiskon / cpp-opengl-tutorial2.git
Следует отметить, что Git позволяет использовать короткую запись хэшей. Вместо «d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4» можно писать «d8578edf» или даже «d857».
Дополнение: Также в 6-м пункте Мини-заметок номер 9 приводится пример объединения коммитов с помощью git rebase
, а в 10-м пункте Мини-заметок номер 11 вы найдете пример объединения двух репозиториев в один без потери истории.
Работа с сабмодулями
Более подробно сабмодули и зачем они нужны объясняется в заметке Простой кроссплатформенный OpenGL-проект на C++ . Здесь упомянем самое главное.
Добавить сабмодуль:
Инициализация сабмодулей:
Обновление сабмодулей, например, если после git pull
поменялся коммит, на который смотрит сабмодуль:
Удаление сабмодуля производится так:
- Скажите
git rm --cached имя_сабмодуля
; - Удалите соответствующие строчки из файла .gitmodules;
- Также грохните соответствующую секцию в .git/config;
- Сделайте коммит;
- Удалите файлы сабмодуля;
- Удалите каталог .git/modules/имя_сабмодуля;
Дополнительные материалы
В качестве источников дополнительной информации я бы рекомендовал следующие:
Как обычно, любые замечания, дополнения и вопросы категорически приветствуются. И кстати, с наступающим вас!
Дополнение: Практика работы с системами контроля версий