Шпаргалка по Git — основные команды, слияние веток, выписка веток с githubPerl, Python — блог программиста

Шпаргалка по 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. Удобно использовать один из них в качестве основного хранилища для корпоративных проектов.

git_meet

Изображение с сайта http://www.stickycomics.com/where-did-you-meet/

Ниже приведены инструкции по использованию git в различных ситуациях. Что делать, если нужно создать новый репозиторий, или выписать ветку, и т.п. Я использую подобную шпаргалку для скоростного копипаста :) Чтобы не отвлекаться, когда голова занята сложными задачами. По мере создания новых инструкций, статья будет обновляться.

Пошаговые рекомендации

Как выписать репозиторий с github

Создаем новую директорию для проекта project_name, переходим в нее.
Выполняем команду:

git clone git@github.com:devlabuser/sharp.git ./

1

git clone git@github.com:devlabuser/sharp.git ./

«./» означает, что создать репозиторий нужно в текущей директории.

Результат: каталог с выписанной веткой master. Теперь можно создавать новые ветки, или выписывать с github существующие.

Как выписать ветку с github

С помощью команды «checkout» можно выписать уже существующую ветку с github:

$ git checkout -b dev origin/dev
$ git checkout -b project_branch origin/project_branch

1 2	$ git checkout -b dev origin/dev $ git checkout -b project_branch origin/project_branch

Или так, что намного надежнее:

$ git checkout --track origin/production

1	$ git checkout --track origin/production

Если команда не сработала, нужно попробовать выполнить обновление:

$ git remote update

1	$ git remote update

Если вышеприведенные команды не сработали, выдали ошибку, и времени разбираться с ней нет, можно попробовать получить нужную ветку следующим способом:

git checkout -b project_branch
git pull origin project_branch

1 2	git checkout -b project_branch git pull origin project_branch

Т.е. сначала мы создаем новую ветку, а затем вливаем в нее изменения из ветки на github.

Как создать новую ветку в локальном репозитории

Создаем новую ветку в локальном репозитории:

$ git checkout -b dev Switched to a new branch 'dev'

1
2

$ git checkout -b dev
Switched to a new branch 'dev'
Публикуем ее на github:

$ git push origin dev Total 0 (delta 0), reused 0 (delta 0) To git@github.com:devlabuser/sharp.git * [new branch] dev -> dev

1
2
3
4

$ git push origin dev
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:devlabuser/sharp.git
* [new branch] dev -> dev

Как переключиться на другую ветку в git

$ git checkout project2_branch

1	$ git checkout project2_branch

Если вы случайно удалили какой-то файл, можно извлечь его из хранилища:

$ git checkout readme.txt

1	$ git checkout readme.txt

Как посмотреть список веток

Команда «branch» позволяет посмотреть список веток в локальном репозитории. Текущая ветка будет помечена звездочкой:

$ git branch
* dev
  master

$ git branch

* dev

master

Как сделать commit

Создаем новую ветку, выполняем в ней нужные изменения.

Список всех измененных и добавленных файлов можно просмотреть командой:

$ git status

1

$ git status
Подготавливаем коммит, добавляя в него файлы командой:

$ git add <file1> <file2> ...

1

$ git add <file1> <file2> ...

Или удаляем устаревшие файлы:

$ git rm <file1> <file2> ...

1

$ git rm <file1> <file2> ...
Выполняем коммит:

$ git commit -m 'Комментарий к коммиту'

1

$ git commit -m 'Комментарий к коммиту'
Как правило, в репозитории существует две основные ветки — dev и master. Dev — общая ветка разработчиков и тестировщиков. Именно в нее добавляются все новые разработки перед очередным релизом. Master — ветка для выкладки продукта на боевые сервера.

После коммита надо влить в нашу ветку изменения из ветки dev и master:

$ git pull origin dev $ git pull origin master

1
2

$ git pull origin dev
$ git pull origin master

Теперь наша ветка содержит изменения для проекта, и все последние изменения по другим задачам, которые успела внести команда.
Переключаемся на ветку dev:

$ git checkout dev

1

$ git checkout dev
Вливаем в dev изменения из ветки проекта:

$ git merge project_branch

1

$ git merge project_branch

Заливаем последнюю версию ветки dev на удаленный сервер:

$ git push origin dev

Counting 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.git
   d528335..9a452d9  dev -> dev

$ git push origin dev

Counting 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.git

d528335..9a452d9 dev -> dev

push может не пройти, потому что удалённый origin/dev обогнал локальную его копию.

Как решить конфликт бинарных файлов

Допустим, при слиянии с другой веткой git выдал ошибку. Команда git status возвращает информацию о конфликте:

$ 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

$ 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

Конфликтный файл является бинарным (это могут быть архивные файлы, изображения и т.п.), и решение конфликта стандартным способом, с помощью редактирования — не возможно.

Чтобы решить такой конфликт, надо просто выбрать — какая версия файла будет использоваться: ваша или из вливаемой ветки. Чтобы использовать свой вариант файла, вводим команду:

git checkout --ours binary.dat
git add binary.dat

1 2	git checkout --ours binary.dat git add binary.dat

Если мы выбираем версию из вливаемой ветки:

git checkout --theirs binary.dat
git add binary.dat

1 2	git checkout --theirs binary.dat git add binary.dat

«ours» — от английского «наш», «theirs» — от английского «их».

Как посмотреть историю изменений

git log — просмотр логов.

$ 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

$ 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

Вывод данных о каждом коммите в одну строку:

git log --pretty=oneline

9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a first commit
d528335724dfc15461996ed9d44d74f23ce6a075 Initial commit

git log --pretty=oneline

9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a first commit

d528335724dfc15461996ed9d44d74f23ce6a075 Initial commit

Для вывода информации git log использует просмотрщик, указанный в конфиге репозитория.

Поиск по ключевому слову в комментариях к коммиту:

$ git log | grep -e "first"
    first commit

1 2	$ git log \| grep -e "first" first commit

Команда «git show» позволяет просмотреть, какие именно изменения произошли в указанном коммите:

$ 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

$ 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

Можно посмотреть построчную информацию о последнем коммите, имя автора и хэш коммита:

$ 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 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, выводит измененные строки и информацию о коммитах, где это произошло:

$ git annotate readme.txt
9a452d9c        (DevLab User      2013-07-31 18:35:47 +0400       1)Text

1 2	$ git annotate readme.txt 9a452d9c (DevLab User 2013-07-31 18:35:47 +0400 1)Text

Как сделать откат

git log — просмотр логов, показывает дельту (разницу/diff), привнесенную каждым коммитом.

commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a
Author: devlabuser <user@mail.ru>
Date:   Wed Jul 31 18:35:47 2013 +0400

    first commit

commit d528335724dfc15461996ed9d44d74f23ce6a075
Author: devlabuser <user@mail.ru>
Date:   Wed Jul 31 06:24:57 2013 -0700

    Initial commit

commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a

Author: devlabuser <user@mail.ru>

Date: Wed Jul 31 18:35:47 2013 +0400

first commit

commit d528335724dfc15461996ed9d44d74f23ce6a075

Author: devlabuser <user@mail.ru>

Date: Wed Jul 31 06:24:57 2013 -0700

Initial commit

Копируем идентификатор коммита, до которого происходит откат.
Откатываемся до последнего успешного коммита (указываем последний коммит):

$ git reset --hard 9a452d955bdb57e7e4f2b09f8ce2fbb6cd56377a HEAD is now at 9a45779 first commit

1
2

$ git reset --hard 9a452d955bdb57e7e4f2b09f8ce2fbb6cd56377a
HEAD is now at 9a45779 first commit

Можно откатить до последней версии ветки:

$ git reset --hard origin/dev HEAD is now at 9a45779 first commit

1
2

$ git reset --hard origin/dev
HEAD is now at 9a45779 first commit

После того, как откат сделан, и выполнен очередной локальный коммит, при попытке сделать push в удаленный репозиторий, git может начать ругаться, что версия вашей ветки младше чем на github и вам надо сделать pull. Это лечится принудительным коммитом:

git push -f origin master

1	git push -f origin master

Как выполнить слияние с другой веткой

git merge выполняет слияние текущей и указанной ветки. Изменения добавляются в текущую ветку.

$ git merge origin/ticket_1001_branch

1	$ git merge origin/ticket_1001_branch

git pull забирает изменения из ветки на удаленном сервере и проводит слияние с активной веткой.

$ git pull origin ticket_1001_branch

1	$ git pull origin ticket_1001_branch

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

Создание нового локального репозитория

$ mkdir project_dir
$ cd project_dir
$ git init

$ mkdir project_dir

$ cd project_dir

$ git init

git cherry-pick

git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.

Для этого нужно выписать ветку, в которую будем вливать коммит:

git checkout master

1

git checkout master
Обновить ее:

git pull origin master

1

git pull origin master
Выполнить команду, указать код коммита:

git cherry-pick eb042098a5

1

git cherry-pick eb042098a5
После этого обновить ветку на сервере:

git push origin master

1

git push origin master

Как раскрасить команды git

После создания репозитория в текущей директории появится субдиректория .git . Она содержит файл config .

[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

[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]:

[color]
        branch = auto
        diff = auto
        interactive = auto
        status = auto
        ui = auto

[color]

branch = auto

diff = auto

interactive = auto

status = auto

ui = auto

Полезные ссылки по теме git

Основы работы с Git

Моя шпаргалка по работе с Git

Pro Git book, written by Scott Chacon. Русский перевод

Блог программиста 28.01.2015 в 9:02 пп

У меня с гитом было так…
На первом работе использовали SVN
В ВУЗе я работаю четвертый год над проектом и исторически там SVN
Писал игрушку под андроид и надеялся делать это не один, товарищ подтолкнул к гиту, я попробовал. Потом таки писал один и проклинал гит.
Постепенно привыкал к гиту, хотел прочитать книжку по нему, но руки не доходили (ты знаешь о чем я, ведь твой блог о мотивации xD).
Устроился на новую работу, там меркуриал. Работа работой, но за 3 месяца я прочитал на работе 2 книжки (одни из них Pro GIT) и прошел курс по git.

Но сначала был курс. Я как бы понимал что делаю что-то не так, когда постоянно матерился на гит в проекте с андройдом. Я хотел научиться и нашел курс (ну многие его знают — на githowto). И вот я устроился на работу и у меня появилось 8 часов свободного времени в сутки xD — я конечно прошел курс. Дак вот курс хреновый, он запутывает и не рассказывает как правильно.

Я начал читать книжку Чакона и вот ее я всем советую. Особенно в середине книжке здорово описаны варианты использования гита — из этого хотя бы понятно как его правильно (ну или «более оптимально») использовать в твоем проекте исходя из масштаба проекта. Потому что в гите тьма всяких фич и вот статьи на хабре рассказывают про них, а значит люди пользуются этим. Если кто-то этим пользуется, а я нет, значит я чего-то не понимаю? — вот Чакон пояснил че почем. Это реально нужно, потому что в гите гораздо больше вариантов ведения проекта чем в svn. Ну а также есть куча холиваров на хабре, например по поводу удаленных веток и эти все статьи часто запутывают.

Опять же статьи описывают не все, а книга Чакона — все и сразу. Очень здоровская книга и ее перевели на русский уже.

Но пока я читал книгу, я написал вот такую же шпаргалку как у Вас примерно (но побольше только…). Потом я забыл ее на работе (( — я ж уволился сразу как дочитал все книги xD.

Шпаргалка по Git — основные команды, слияние веток, выписка веток с github: 10 комментариев

Nikolay 28.01.2015 в 3:58 пп

> git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.

можно и не один, а много коммитов перечислить через проблел

пример: git cherry-pick qw1w2e3 a4s5d5 f6g7h8j8
(последний коммит будет верхним)
Блог программиста 28.01.2015 в 9:02 пп

У меня с гитом было так…
На первом работе использовали SVN
В ВУЗе я работаю четвертый год над проектом и исторически там SVN
Писал игрушку под андроид и надеялся делать это не один, товарищ подтолкнул к гиту, я попробовал. Потом таки писал один и проклинал гит.
Постепенно привыкал к гиту, хотел прочитать книжку по нему, но руки не доходили (ты знаешь о чем я, ведь твой блог о мотивации xD).
Устроился на новую работу, там меркуриал. Работа работой, но за 3 месяца я прочитал на работе 2 книжки (одни из них Pro GIT) и прошел курс по git.

Но сначала был курс. Я как бы понимал что делаю что-то не так, когда постоянно матерился на гит в проекте с андройдом. Я хотел научиться и нашел курс (ну многие его знают — на githowto). И вот я устроился на работу и у меня появилось 8 часов свободного времени в сутки xD — я конечно прошел курс. Дак вот курс хреновый, он запутывает и не рассказывает как правильно.

Я начал читать книжку Чакона и вот ее я всем советую. Особенно в середине книжке здорово описаны варианты использования гита — из этого хотя бы понятно как его правильно (ну или «более оптимально») использовать в твоем проекте исходя из масштаба проекта. Потому что в гите тьма всяких фич и вот статьи на хабре рассказывают про них, а значит люди пользуются этим. Если кто-то этим пользуется, а я нет, значит я чего-то не понимаю? — вот Чакон пояснил че почем. Это реально нужно, потому что в гите гораздо больше вариантов ведения проекта чем в svn. Ну а также есть куча холиваров на хабре, например по поводу удаленных веток и эти все статьи часто запутывают.

Опять же статьи описывают не все, а книга Чакона — все и сразу. Очень здоровская книга и ее перевели на русский уже.

Но пока я читал книгу, я написал вот такую же шпаргалку как у Вас примерно (но побольше только…). Потом я забыл ее на работе (( — я ж уволился сразу как дочитал все книги xD.
urmat 03.04.2015 в 3:14 пп

Добрый день!

проконсультируйте пжл что я делаю не правильно.
#!/bin/bash
clear
git status | grep -c «nothing to commit»
read $s
echo $s

echo выводит null
1. Natalie Автор записи05.04.2015 в 7:35 пп
  
  Простите, у меня сейчас нет git на серверах — т.к. для личных нужд он мне пока не был нужен, а устанавливать нет желания. Обычно я не отвечаю на вопросы, если не могу проверить ответ на практике, чтобы быть уверенной в его корректности. :(
2. aarexer 15.01.2016 в 12:23 пп
  
  You should remove $ in fourth line:)
  
  Try smth like that:
  
  #!/bin/bash
  clear
  git status | grep -c “nothing to commit”
  read s
  echo $s
Васек 01.02.2016 в 9:11 дп

Что значит выписать? Все татары кроме я.
1. Natalie Автор записи28.03.2016 в 7:47 пп
  
  Ну можно, наверное, перевести это как «создать копию указанной ветки на локальном компьютере» :)
Антон 31.05.2016 в 4:51 пп

Шикарная шпаргалка, спасибо!
sssds 09.06.2016 в 1:35 пп

Но сначала был курс. Я как бы понимал что делаю что-то не так, когда постоянно матерился на гит в проекте с андройдом. Я хотел научиться и нашел курс (ну многие его знают – на githowto). И вот я устроился на работу и у меня появилось 8 часов свободного времени в сутки xD – я конечно прошел курс. Дак вот курс хреновый, он запутывает и не рассказывает как правильно.

Я начал читать книжку Чакона и вот ее я всем советую. Особенно в середине книжке здорово описаны варианты использования гита – из этого хотя бы понятно как его правильно (ну или “более оптимально”) использовать в твоем проекте исходя из масштаба проекта. Потому что в гите тьма всяких фич и вот статьи на хабре рассказывают про них, а значит люди пользуются этим. Если кто-то этим пользуется, а я нет, значит я чего-то не понимаю? – вот Чакон пояснил че почем. Это реально нужно, потому что в гите гораздо больше вариантов ведения проекта чем в svn. Ну а также есть куча холиваров на хабре, например по поводу удаленных веток и эти все статьи часто запутывают.
urlclosed 27.07.2016 в 12:15 пп

Спасибо, хорошая шпаргалка,
вот тут еще можно почерпнуть полезной инфы http://test-us.ru/web-razrabotka/komandi-git/

Обсуждение закрыто.