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

Шпаргалка по 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

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

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

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

 

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

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

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

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

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

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

 

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

  1. Создаем новую ветку в локальном репозитории:
  2. Публикуем ее на github:

 

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

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

 

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

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

 

Как сделать commit

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

  1. Список всех измененных и добавленных файлов можно просмотреть командой:
  2. Подготавливаем коммит, добавляя в него файлы командой:

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

  3. Выполняем коммит:

  4. Как правило, в репозитории существует две основные ветки — dev и master. Dev — общая ветка разработчиков и тестировщиков. Именно в нее добавляются все новые разработки перед очередным релизом. Master — ветка для выкладки продукта на боевые сервера.

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

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

  5. Переключаемся на ветку dev:

  6. Вливаем в dev изменения из ветки проекта:

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

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

git annotate, выводит измененные строки и информацию о коммитах, где это произошло:

 

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

  1. git log — просмотр логов, показывает дельту (разницу/diff), привнесенную каждым коммитом.
  2. Копируем идентификатор коммита, до которого происходит откат.
  3. Откатываемся до последнего успешного коммита (указываем последний коммит):

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

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

 

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

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

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

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

 

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

 

git cherry-pick

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

  1. Для этого нужно выписать ветку, в которую будем вливать коммит:
  2. Обновить ее:
  3. Выполнить команду, указать код коммита:
  4. После этого обновить ветку на сервере:

 

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

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

Чтобы раскрасить вывод git, можно добавить в файл блок [color]:

 

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

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

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

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

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

  1. Nikolay

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

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

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

  2. Блог программиста

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

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

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

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

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

  3. urmat

    Добрый день!

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

    echo выводит null

    1. Natalie Автор записи

      Простите, у меня сейчас нет git на серверах — т.к. для личных нужд он мне пока не был нужен, а устанавливать нет желания. Обычно я не отвечаю на вопросы, если не могу проверить ответ на практике, чтобы быть уверенной в его корректности. :(

    2. aarexer

      You should remove $ in fourth line:)

      Try smth like that:

      #!/bin/bash
      clear
      git status | grep -c “nothing to commit”
      read s
      echo $s

    1. Natalie Автор записи

      Ну можно, наверное, перевести это как «создать копию указанной ветки на локальном компьютере» :)

  4. sssds

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

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

Комментарии запрещены.