Пример использования 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/имя_сабмодуля;
Дополнительные материалы
В качестве источников дополнительной информации я бы рекомендовал следующие:
Источник: https://eax.me/git-commands/
Публикую
у себя, потому что домены авторов иногда не продлевается, а такой
контент исчезает. Blogspot работает и ничего не просит годами.