Шпаргалка по git. Пошаговое руководство: как выполнить слияние веток в git, как создать новую ветку и репозиторий, как выписать ветку с github и т.п. Инструкции по git для начинающих.
Git – это распределенная система контроля версий. Это главное отличие git от svn. Каждый разработчик создает на своем компьютере отдельный, полноценный репозиторий.
В рамках этого репозитория можно делать все тоже самое, что и обычно в svn – создавать ветки, просматривать изменения, выполнять коммиты. Для того, чтобы можно было работать с удаленными репозиториями и обмениваться изменениями с другими разработчиками, в git есть две команды, не имеющие аналогов в svn – git push и git pull.
git push – вливание локальных изменений в удаленный репозиторий. git pull – вливание изменений из удаленного репозитория в локальный. Обмен данными обычно происходит с использованием протокола SSH.
Git поддерживают несколько крупных репозиториев – GitHub, SourceForge, BitBucket и Google Code. Удобно использовать один из них в качестве основного хранилища для корпоративных проектов.
Изображение с сайта http://www.stickycomics.com/where-did-you-meet/
Ниже приведены инструкции по использованию git в различных ситуациях. Что делать, если нужно создать новый репозиторий, или выписать ветку, и т.п. Я использую подобную шпаргалку для скоростного копипаста :) Чтобы не отвлекаться, когда голова занята сложными задачами. По мере создания новых инструкций, статья будет обновляться.
Пошаговые рекомендации
Как выписать репозиторий с github
- Создаем новую директорию для проекта project_name, переходим в нее.
- Выполняем команду:
1git clone git@github.com:devlabuser/sharp.git ./
“./” означает, что создать репозиторий нужно в текущей директории.
Результат: каталог с выписанной веткой master. Теперь можно создавать новые ветки, или выписывать с github существующие.
Как выписать ветку с github
С помощью команды “checkout” можно выписать уже существующую ветку с github:
|
1 2 |
$ git checkout -b dev origin/dev $ git checkout -b project_branch origin/project_branch |
Или так, что намного надежнее:
|
1 |
$ git checkout --track origin/production |
Если команда не сработала, нужно попробовать выполнить обновление:
|
1 |
$ git remote update |
Если вышеприведенные команды не сработали, выдали ошибку, и времени разбираться с ней нет, можно попробовать получить нужную ветку следующим способом:
|
1 2 |
git checkout -b project_branch git pull origin project_branch |
Т.е. сначала мы создаем новую ветку, а затем вливаем в нее изменения из ветки на github.
Как создать новую ветку в локальном репозитории
- Создаем новую ветку в локальном репозитории:
12$ git checkout -b devSwitched to a new branch 'dev' - Публикуем ее на github:
1234$ git push origin devTotal 0 (delta 0), reused 0 (delta 0)To git@github.com:devlabuser/sharp.git* [new branch] dev -> dev
Как переключиться на другую ветку в git
|
1 |
$ git checkout project2_branch |
Если вы случайно удалили какой-то файл, можно извлечь его из хранилища:
|
1 |
$ git checkout readme.txt |
Как посмотреть список веток
Команда “branch” позволяет посмотреть список веток в локальном репозитории. Текущая ветка будет помечена звездочкой:
|
1 2 3 |
$ git branch * dev master |
Как сделать commit
Создаем новую ветку, выполняем в ней нужные изменения.
- Список всех измененных и добавленных файлов можно просмотреть командой:
1$ git status - Подготавливаем коммит, добавляя в него файлы командой:
1$ git add <file1> <file2> ...Или удаляем устаревшие файлы:
1$ git rm <file1> <file2> ... - Выполняем коммит:
1$ git commit -m 'Комментарий к коммиту'
- Как правило, в репозитории существует две основные ветки – dev и master. Dev – общая ветка разработчиков и тестировщиков. Именно в нее добавляются все новые разработки перед очередным релизом. Master – ветка для выкладки продукта на боевые сервера.
После коммита надо влить в нашу ветку изменения из ветки dev и master:12$ git pull origin dev$ git pull origin masterТеперь наша ветка содержит изменения для проекта, и все последние изменения по другим задачам, которые успела внести команда.
- Переключаемся на ветку dev:
1$ git checkout dev
- Вливаем в dev изменения из ветки проекта:
1$ git merge project_branch
- Заливаем последнюю версию ветки dev на удаленный сервер:
123456789$ git push origin devCounting objects: 4, done.Delta compression using up to 2 threads.Compressing objects: 100% (2/2), done.Writing objects: 100% (3/3), 286 bytes, done.Total 3 (delta 0), reused 0 (delta 0)To git@github.com:devlab/sharp.gitd528335..9a452d9 dev -> dev
push может не пройти, потому что удалённый origin/dev обогнал локальную его копию.
Как решить конфликт бинарных файлов
Допустим, при слиянии с другой веткой git выдал ошибку. Команда git status возвращает информацию о конфликте:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$ git status ... Unmerged paths: (use "git add <file>..." to mark resolution) both modified: root/css/styles.css.gz $ git diff root/css/styles.css.gz diff --cc root/css/styles.css.gz index 970c721,bc6d170..0000000 Binary files differ |
Конфликтный файл является бинарным (это могут быть архивные файлы, изображения и т.п.), и решение конфликта стандартным способом, с помощью редактирования – не возможно.
Чтобы решить такой конфликт, надо просто выбрать – какая версия файла будет использоваться: ваша или из вливаемой ветки. Чтобы использовать свой вариант файла, вводим команду:
|
1 2 |
git checkout --ours binary.dat git add binary.dat |
Если мы выбираем версию из вливаемой ветки:
|
1 2 |
git checkout --theirs binary.dat git add binary.dat |
“ours” – от английского “наш”, “theirs” – от английского “их”.
Как посмотреть историю изменений
git log – просмотр логов.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$ git log commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a Author: DevLab User <user@mail.ru> Date: Wed Jul 31 18:35:47 2013 +0400 first commit commit d528335724dfc15461996ed9d44d74f23ce6a075 Author: DevLab User <user@mail.ru> Date: Wed Jul 31 06:24:57 2013 -0700 Initial commit |
Вывод данных о каждом коммите в одну строку:
|
1 2 3 4 |
git log --pretty=oneline 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a first commit d528335724dfc15461996ed9d44d74f23ce6a075 Initial commit |
Для вывода информации git log использует просмотрщик, указанный в конфиге репозитория.
Поиск по ключевому слову в комментариях к коммиту:
|
1 2 |
$ git log | grep -e "first" first commit |
Команда “git show” позволяет просмотреть, какие именно изменения произошли в указанном коммите:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
$ git show 99452d955bdb57e7e4f2b09f8ce2fbb6cd56377a commit 99452d955bdb57e7e4f2b09f8ce2fbb6cd56377a Author: DevLab User <user@mail.ru> Date: Wed Jul 31 18:35:47 2013 +0400 first commit diff --git a/readme.txt b/readme.txt new file mode 100644 index 0000000..4add785 --- /dev/null +++ b/readme.txt @@ -0,0 +1 @@ +Text \ No newline at end of file |
Можно посмотреть построчную информацию о последнем коммите, имя автора и хэш коммита:
|
1 2 3 4 |
$ git blame README.md ^d528335 (devlabuser 2013-07-31 06:24:57 -0700 1) sharp ^d528335 (devlabuser 2013-07-31 06:24:57 -0700 2) ===== |
git annotate, выводит измененные строки и информацию о коммитах, где это произошло:
|
1 2 |
$ git annotate readme.txt 9a452d9c (DevLab User 2013-07-31 18:35:47 +0400 1)Text |
Как сделать откат
- git log – просмотр логов, показывает дельту (разницу/diff), привнесенную каждым коммитом.
1234567891011commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657aAuthor: devlabuser <user@mail.ru>Date: Wed Jul 31 18:35:47 2013 +0400first commitcommit d528335724dfc15461996ed9d44d74f23ce6a075Author: devlabuser <user@mail.ru>Date: Wed Jul 31 06:24:57 2013 -0700Initial commit - Копируем идентификатор коммита, до которого происходит откат.
- Откатываемся до последнего успешного коммита (указываем последний коммит):
12$ git reset --hard 9a452d955bdb57e7e4f2b09f8ce2fbb6cd56377aHEAD is now at 9a45779 first commit
Можно откатить до последней версии ветки:
12$ git reset --hard origin/devHEAD is now at 9a45779 first commit
После того, как откат сделан, и выполнен очередной локальный коммит, при попытке сделать push в удаленный репозиторий, git может начать ругаться, что версия вашей ветки младше чем на github и вам надо сделать pull. Это лечится принудительным коммитом:
|
1 |
git push -f origin master |
Как выполнить слияние с другой веткой
git merge выполняет слияние текущей и указанной ветки. Изменения добавляются в текущую ветку.
|
1 |
$ git merge origin/ticket_1001_branch |
git pull забирает изменения из ветки на удаленном сервере и проводит слияние с активной веткой.
|
1 |
$ git pull origin ticket_1001_branch |
git pull отличается от git merge тем, что merge только выполняет слияние веток, а pull прежде чем выполнить слияние – закачивает изменения с удаленного сервера. merge удобно использовать для слияния веток в локальном репозитории, pull – слияния веток, когда одна из них лежит на github.
Создание нового локального репозитория
|
1 2 3 |
$ mkdir project_dir $ cd project_dir $ git init |
git cherry-pick
git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.
- Для этого нужно выписать ветку, в которую будем вливать коммит:
1git checkout master - Обновить ее:
1git pull origin master - Выполнить команду, указать код коммита:
1git cherry-pick eb042098a5 - После этого обновить ветку на сервере:
1git push origin master
Как раскрасить команды git
После создания репозитория в текущей директории появится субдиректория .git . Она содержит файл config .
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = git@github.com:devlab/sharp.git [branch "master"] remote = origin merge = refs/heads/master [branch "dev"] remote = origin merge = refs/heads/dev |
Чтобы раскрасить вывод git, можно добавить в файл блок [color]:
|
1 2 3 4 5 6 |
[color] branch = auto diff = auto interactive = auto status = auto ui = auto |
> git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.
можно и не один, а много коммитов перечислить через проблел
пример: git cherry-pick qw1w2e3 a4s5d5 f6g7h8j8
(последний коммит будет верхним)
У меня с гитом было так…
На первом работе использовали SVN
В ВУЗе я работаю четвертый год над проектом и исторически там SVN
Писал игрушку под андроид и надеялся делать это не один, товарищ подтолкнул к гиту, я попробовал. Потом таки писал один и проклинал гит.
Постепенно привыкал к гиту, хотел прочитать книжку по нему, но руки не доходили (ты знаешь о чем я, ведь твой блог о мотивации xD).
Устроился на новую работу, там меркуриал. Работа работой, но за 3 месяца я прочитал на работе 2 книжки (одни из них Pro GIT) и прошел курс по git.
Но сначала был курс. Я как бы понимал что делаю что-то не так, когда постоянно матерился на гит в проекте с андройдом. Я хотел научиться и нашел курс (ну многие его знают – на githowto). И вот я устроился на работу и у меня появилось 8 часов свободного времени в сутки xD – я конечно прошел курс. Дак вот курс хреновый, он запутывает и не рассказывает как правильно.
Я начал читать книжку Чакона и вот ее я всем советую. Особенно в середине книжке здорово описаны варианты использования гита – из этого хотя бы понятно как его правильно (ну или “более оптимально”) использовать в твоем проекте исходя из масштаба проекта. Потому что в гите тьма всяких фич и вот статьи на хабре рассказывают про них, а значит люди пользуются этим. Если кто-то этим пользуется, а я нет, значит я чего-то не понимаю? – вот Чакон пояснил че почем. Это реально нужно, потому что в гите гораздо больше вариантов ведения проекта чем в svn. Ну а также есть куча холиваров на хабре, например по поводу удаленных веток и эти все статьи часто запутывают.
Опять же статьи описывают не все, а книга Чакона – все и сразу. Очень здоровская книга и ее перевели на русский уже.
Но пока я читал книгу, я написал вот такую же шпаргалку как у Вас примерно (но побольше только…). Потом я забыл ее на работе (( – я ж уволился сразу как дочитал все книги xD.
Добрый день!
проконсультируйте пжл что я делаю не правильно.
#!/bin/bash
clear
git status | grep -c “nothing to commit”
read $s
echo $s
echo выводит null
Простите, у меня сейчас нет git на серверах – т.к. для личных нужд он мне пока не был нужен, а устанавливать нет желания. Обычно я не отвечаю на вопросы, если не могу проверить ответ на практике, чтобы быть уверенной в его корректности. :(
You should remove $ in fourth line:)
Try smth like that:
#!/bin/bash
clear
git status | grep -c “nothing to commit”
read s
echo $s
Что значит выписать? Все татары кроме я.
Ну можно, наверное, перевести это как “создать копию указанной ветки на локальном компьютере” :)
Шикарная шпаргалка, спасибо!
Но сначала был курс. Я как бы понимал что делаю что-то не так, когда постоянно матерился на гит в проекте с андройдом. Я хотел научиться и нашел курс (ну многие его знают – на githowto). И вот я устроился на работу и у меня появилось 8 часов свободного времени в сутки xD – я конечно прошел курс. Дак вот курс хреновый, он запутывает и не рассказывает как правильно.
Я начал читать книжку Чакона и вот ее я всем советую. Особенно в середине книжке здорово описаны варианты использования гита – из этого хотя бы понятно как его правильно (ну или “более оптимально”) использовать в твоем проекте исходя из масштаба проекта. Потому что в гите тьма всяких фич и вот статьи на хабре рассказывают про них, а значит люди пользуются этим. Если кто-то этим пользуется, а я нет, значит я чего-то не понимаю? – вот Чакон пояснил че почем. Это реально нужно, потому что в гите гораздо больше вариантов ведения проекта чем в svn. Ну а также есть куча холиваров на хабре, например по поводу удаленных веток и эти все статьи часто запутывают.
Спасибо, хорошая шпаргалка,
вот тут еще можно почерпнуть полезной инфы http://test-us.ru/web-razrabotka/komandi-git/