Git создать новую ветку: 24. Создание ветки

Содержание

24. Создание ветки

Цели

  • Научиться создавать локальную ветку в репозитории

Пора сделать наш hello world более выразительным. Так как это может занять некоторое время, лучше переместить эти изменения в отдельную ветку, чтобы изолировать их от изменений в ветке master.

01 Создайте ветку

Давайте назовем нашу новую ветку «style».

Выполните:
git checkout -b style
git status

Примечание: git checkout -b <имяветки> является шорткатом для git branch <имяветки> за которым идет git checkout <имяветки>.

Обратите внимание, что команда git status сообщает о том, что вы находитесь в ветке «style».

02Добавьте файл стилей style.css

Выполните:
touch lib/style.css
Файл: lib/style.css
h2 {
  color: red;
}
Выполните:
git add lib/style.css
git commit -m "Added css stylesheet"

03Измените основную страницу

Обновите файл hello.html, чтобы использовать стили style.css.

Файл: lib/hello.html
<!-- Author: Alexander Shvets ([email protected]) -->
<html>
  <head>
    <link type="text/css" rel="stylesheet" media="all" href="style.css" />
  </head>
  <body>
    <h2>Hello, World!</h2>
  </body>
</html>
Выполните:
git add lib/hello.html
git commit -m "Hello uses style.css"

04Измените index.html

Обновите файл index.html, чтобы он тоже использовал style.css

Файл: index.html
<html>
  <head>
    <link type="text/css" rel="stylesheet" media="all" href="lib/style.css" />
  </head>
  <body>
    <iframe src="lib/hello.html" />
  </body>
</html>
Выполните:
git add index.html
git commit -m "Updated index.html"

05 Далее

Теперь у нас есть новая ветка под названием style с 3 новыми коммитами. Далее мы узнаем, как осуществлять навигацию и переключаться между ветками.

Git — Book

2nd Edition (2014)

Download Ebook

The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com.>

    1. 1.1 О системе контроля версий
    2. 1.2 Краткая история Git
    3. 1.3 Основы Git
    4. 1.4 Командная строка
    5. 1.5 Установка Git
    6. 1.6 Первоначальная настройка Git
    7. 1.7 Как получить помощь?
    8. 1.8 Заключение
    1. 2.1 Создание Git-репозитория
    2. 2.2 Запись изменений в репозиторий
    3. 2.3 Просмотр истории коммитов
    4. 2.4 Операции отмены
    5. 2.5 Работа с удалёнными репозиториями
    6. 2.6 Работа с метками
    7. 2.7 Псевдонимы в Git
    8. 2.8 Заключение
    1. 3.1 О ветвлении в двух словах
    2. 3.2

Ветки. Git branch. Урок 7

Урок, в котором мы узнаем, что такое ветки, зачем они нужны и научимся с ними работать

Видеоурок

Конспект урока

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

Ветки — главная фишка git

Git стал стандартом в системах контроля версий благодаря простой и удобной работе с ветками.

Какие проблемы решают ветки

Представим рабочую ситуацию. Мы сидим и разрабатываем функционал новой большой фичи, например, добавляем на сайт раздел новостей. Уже добавили новые файлы, поменяли стили, поправили разметку, но до завершения еще далеко.

Внезапно прилетает задача — срочно поправить багу в верстке шапки. Мы не можем чинить багу прямо сейчас, в текущем состоянии проекта. У нас много изменений, но работа над большой фичей не завершена — поэтому мешать код новой фичи и код с починкой срочной баги нельзя. Как быть?

Было бы здорово, если бы могли разрабатывать новую фичу независимо от основного кода проекта. То есть взять и зафиксировать рабочее состояние сайта, а делать новый функционал отдельно, не боясь поломать рабочий код. И еще чтобы можно было переключаться между основным кодом (для правки баги) и кодом новой фичи (для продолжения работы над ней)

Когда я не пользовался git, то решал эту проблему созданием архивов проекта. Довел сайт до какого-то рабочего состояния — сделал архив. Реализовал новую фичу — сделал еще один архив. Нужно переключиться на старый код для правки баги — сохранил текущую работу в новый «временный» архив, выбрал старый «стабильный» архив, распаковал, починил там багу, вернулся обратно во «временный» архив.

Схема рабочая, но слишком много суеты и неудобств:

  • нужно постоянно создавать архивы с рабочим кодом
  • сложно «переключаться» между архивами
  • сложно перетаскивать изменения между архивами
  • легко что-то напутать или потерять — все мы люди

Все эти проблемы git решает механизмом веток.

Как работают ветки

Представим код проекта в виде дерева. Посередине ствол — это рабочее состояние проекта, тот код, который выложен на боевом сервере. Этот ствол в терминах git называется основной веткой разработки — веткой master. Эта ветка есть всегда в любом проекте. Как только мы клонировали или создали новый репозиторий, мы попали в ветку master. Все, что мы делали на предыдущих уроках, мы делали в мастере.

Когда мы начинаем работать над новым функционалом, мы создаем новую ветку на основе master. Это называется «ответвиться от мастера». После этого мы можем работать, создавать новые файлы, вносить изменения в старые, можем хоть удалить половину проекта — главное, что это будет изолировано от основного мастера. То есть в своей ветке мы можем как угодно ломать проект, основной код при этом не пострадает.

Кроме того мы в любой момент можем переключиться в мастер, например, для правки баги, не боясь потерять изменения в своей ветке с новым функционалом. Починим багу в мастере, выложим правку на боевой сайт и так же легко вернемся к своей ветке и продолжим работать в ней.

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

Когда мы заканчиваем работать над новым функционалом, то нужно наши изменения перенести в мастер, чтобы залить на боевой сайт. Это называется слить ветку в мастер, или залить в мастер, или смерджить в мастер. При этом после мерджа в мастере оказываются не только наши изменения, но и те, которые были в мастере, но не были в нашей ветке (правка баги в мастере). То есть нам даже не обязательно после правки баги в мастере переносить эти изменения в свою ветку. При мердже git наш новый код «положит» поверх того, что было в мастере, не стирая старый.

Чтобы было нагляднее и понятнее, как это работает, смотрите видео. А в тексте ниже краткое описание команд для работы с ветками.

Ветка master

Еще раз закрепим. Ветка master — это, как правило, основная ветка проекта. Она появляется сразу после клонирования или инициализации репозитория. Есть разные варианты ведения веток, но мы будем считать, что master — наша основная рабочая ветка, от которой ответвляются другие.

Как создать новую ветку


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

Так мы создали новую ветку news, имея в виду, что будем разрабатывать в ней блок новостей.

Как переключаться между ветками

Для этого используется команда checkout


    $ git checkout news 

Обратите внимание, если у вас есть незакоммиченные изменения, то переключиться на другую ветку не получится — git за этим следит

Вот что при этом вы увидите


    $ git checkout master 
    error: Your local changes to the following files would be overwritten by checkout:
            index.html
    Please, commit your changes or stash them before you can switch branches.
    Aborting

Поэтому сначала или закоммитьте изменения в ветке, или откатите эти изменения — а уже потом переключайтесь. Это может показаться странным, но так сделано для безопасности, чтобы случайно не потерять код.

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


    $ git branch
      master
    * news

Этой командой мы выведем список всех локальных веток. Звездочка у news означает текущую ветку, в которой мы сейчас находимся.

Коммитим в новую ветку

Коммиты в ветку добавляются точно так же, как и раньше. Делаем изменения в файлах, потом git add, потом git commit -m ‘commit message’.

Как запушить новую ветку

Вспомним, как мы пушили раньше


    $ git push origin master

Точно так же мы пушим и новую ветку, только вместо master указываем свое название


    $ git push origin news

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

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

Допустим, мы неудачно выбрали название и хотим его заменить. Находясь в нужной ветке, выполним команды


    $ git branch -m block-news

Это переименует текущую ветку news в block-news. Чтобы убедиться, посмотрим список веток


    $ git branch 
    * block-news
      master

Обратите внимание, если мы запушим новую ветку, то на сервере, в github, появится еще одна ветка block-news, и при этом останется старая news. Чтобы не засорять проект, старую ветку нужно удалить как локальную у себя, так и удаленную на сервере.

Как удалить ветку

Удаляется ветка командой git branch -d branch_name. Но здесь могут быть варианты. Рассмотрим, что может пойти не так


    $ git branch -d block-news 
    error: Cannot delete the branch 'block-news' which you are currently on.

Здесь просто — мы не можем удалить ветку, потому что в ней находимся. Сначала нужно перелючиться в мастер


    $ git checkout master 
    $ git branch -d block-news 
    error: The branch 'block-news' is not fully merged.
    If you are sure you want to delete it, run 'git branch -D block-news'.

Опять ошибка — здесь git говорит о том, что в удаляемой ветке есть код, который не залит в мастер. То есть при удалении ветки этот код потеряется. Поэтому если мы уверены в своих действиях и ветка действительно не нужна, то вместо флага -d нужен -D


    $ git branch -D block-news 
    Deleted branch block-news (was cb38a55).

Теперь удалено без вопросов.

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

В правом нижнем углу есть пункт «Git:master». Там пишется название текущей ветки. Чтобы создать новую, нужно кликнуть на этот пункт и выбрать New Branch. Чтобы переключиться, выбрать в списке Local Branches нужную ветку и Checkout. Чтобы удалить или переименовать соотвественно Delete или Rename.

Наглядно это показывается в видеоуроке

Раздел Remote Branches мы рассмотрим в следующем уроке

Что могу посоветовать

  • научитесь легко оперировать ветками
  • создавайте больше веток
  • называйте ветки по общим правилам
  • пушьте ветки почаще, их легко потом удалить

Поняв магию веток, мы уже не представим свою работу без git. Любой, даже небольшой проект мы будем начинать с создания репозитория. А работа с ветками будет такой же естественной, как и собственно написание кода. Мне кажется, именно понимание веток превращает git из прикольной тулзы в незаменимый инструмент работы.

И напоследок Киану. Просветление. Назад возврата нет

В следующем уроке мы узнаем, как работать с ветками на сервере

Спасибо за внимание и до встречи!

Все уроки курса

Продолжение следует…

Создание ветки на основе существующей в GIT

Создание новой ветки — это рутинная операция в GIT. Как указать на основе какой существующей ветки нужно создать новую?

По умолчанию, за основу будет взята текущая ветка, в которой вы находитесь. Например:

git checkout master git branch feature/new-branch git checkout feature/new-branch

git checkout master

git branch feature/new-branch

git checkout feature/new-branch

Сначала мы переключились на ветку master, затем создали на её основе новую ветку feature/new-branch. Третьей командой мы переключились на вновь созданную ветку, чтобы начать производить в её рамках какие то изменения.

Узнать где вы находитесь (какая ветка в текущий момент выбрана в GIT), можно с помощью

или

Первый вариант выведет список локальных веток, с выделением активной. Второй вариант подробно опишет текущий статус, в том числе укажет в какой ветке вы находитесь.

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

git checkout -b feature/new-branch master

git checkout -b feature/new-branch master

Будет создана ветка на основе master, кроме того git переключится на вновь созданную ветку.

git

Написать комментарий

Данная запись опубликована в 30.07.2018 15:55 и размещена в Программирование. Вы можете перейти в конец страницы и оставить ваш комментарий.

Мало букафф? Читайте есчо !

Тонкости настройки в .gitignore

Июль 17, 2017 г.

Настройки в файле .gitignore позволяют исключить из списка файлов сканируемых GIT, все то что отслеживать не надо. Обычно это так называемые юзер-файлы, изображения, архивы, документация и т.п. В данной статье рассмотрим типовой случай настоек в .gitignore. …

Читать

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

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

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

 

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

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

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

    git clone [email protected]:devlabuser/sharp.git ./

    git clone [email protected]:devlabuser/sharp.git ./


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

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

 

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

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

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

$ git checkout -b dev origin/dev

$ git checkout -b project_branch origin/project_branch

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

$ git checkout —track origin/production

$ git checkout —track origin/production

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

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

git checkout -b project_branch git pull origin project_branch

git checkout -b project_branch

git pull origin project_branch

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

 

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

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

    $ git checkout -b dev Switched to a new branch ‘dev’

    $ git checkout -b dev

    Switched to a new branch ‘dev’

  2. Публикуем ее на github:

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

    $ git push origin dev

    Total 0 (delta 0), reused 0 (delta 0)

    To [email protected]:devlabuser/sharp.git

    * [new branch]      dev -> dev

 

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

$ git checkout project2_branch

$ git checkout project2_branch

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

$ git checkout readme.txt

$ git checkout readme.txt

 

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

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

$ git branch * dev master

$ git branch

* dev

  master

 

Как сделать commit

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

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

    $ git add <file1> <file2> …

    $ git add <file1> <file2> …

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

    $ git rm <file1> <file2> …

    $ git rm <file1> <file2> …

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

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

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

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

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

    $ git pull origin dev $ git pull origin master

    $ git pull origin dev

    $ git pull origin master

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

  5. Переключаемся на ветку dev:
  6. Вливаем в dev изменения из ветки проекта:

    $ git merge project_branch

    $ git merge project_branch

  7. Заливаем последнюю версию ветки 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 [email protected]: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 [email protected]: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

git checkout —ours binary.dat

git add binary.dat

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

git checkout —theirs binary.dat git add binary.dat

git checkout —theirs binary.dat

git add binary.dat

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

 

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

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

$ git log commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a Author: DevLab User <[email protected]> Date: Wed Jul 31 18:35:47 2013 +0400 first commit commit d528335724dfc15461996ed9d44d74f23ce6a075 Author: DevLab User <[email protected]> Date: Wed Jul 31 06:24:57 2013 -0700 Initial commit

$ git log

commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a

Author: DevLab User <[email protected]>

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

 

    first commit

 

commit d528335724dfc15461996ed9d44d74f23ce6a075

Author: DevLab User <[email protected]>

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

$ git log | grep -e «first»

    first commit

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

$ git show 99452d955bdb57e7e4f2b09f8ce2fbb6cd56377a commit 99452d955bdb57e7e4f2b09f8ce2fbb6cd56377a Author: DevLab User <[email protected]> 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 <[email protected]>

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

$ git annotate readme.txt

9a452d9c        (DevLab User      2013-07-31 18:35:47 +0400       1)Text

 

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

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

    commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a Author: devlabuser <[email protected]> Date: Wed Jul 31 18:35:47 2013 +0400 first commit commit d528335724dfc15461996ed9d44d74f23ce6a075 Author: devlabuser <[email protected]> Date: Wed Jul 31 06:24:57 2013 -0700 Initial commit

    commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a

    Author: devlabuser <[email protected]>

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

     

        first commit

     

    commit d528335724dfc15461996ed9d44d74f23ce6a075

    Author: devlabuser <[email protected]>

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

     

        Initial commit

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

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

    $ git reset —hard 9a452d955bdb57e7e4f2b09f8ce2fbb6cd56377a

    HEAD is now at 9a45779 first commit


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

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

    $ git reset —hard origin/dev

    HEAD is now at 9a45779 first commit

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

git push -f origin master

git push -f origin master

 

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

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

$ git merge origin/ticket_1001_branch

$ git merge origin/ticket_1001_branch

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

$ git pull origin ticket_1001_branch

$ 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 помогает применить один-единственный коммит из одной ветки к дереву другой.

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

    git cherry-pick eb042098a5

    git cherry-pick eb042098a5

  4. После этого обновить ветку на сервере:

 

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

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

[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote «origin»] fetch = +refs/heads/*:refs/remotes/origin/* url = [email protected]: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 = [email protected]: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. Русский перевод

Шпаргалка по Git. Инструкции по git для начинающих.

Шпаргалка по Git

Шпаргалка по Git

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

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

git clone [email protected]:devlabuser/sharp.git ./

git clone [email protected]:devlabuser/sharp.git ./

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

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

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

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

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

$ git checkout -b dev origin/dev

$ git checkout -b project_branch origin/project_branch

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

$ git checkout —track origin/production

$ git checkout —track origin/production

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

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

git checkout -b project_branch git pull origin project_branch

git checkout -b project_branch

git pull origin project_branch

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

 

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

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

$ git checkout -b dev Switched to a new branch ‘dev’

$ git checkout -b dev

Switched to a new branch ‘dev’

2. Публикуем ее на github:

$ git push origin dev Total 0 (delta 0), reused 0 (delta 0) To [email protected]:devlabuser/sharp.git * [new branch] dev -&gt; dev

$ git push origin dev

Total 0 (delta 0), reused 0 (delta 0)

To [email protected]:devlabuser/sharp.git

* [new branch]      dev -&gt; dev

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

$ git checkout project2_branch

$ git checkout project2_branch

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

$ git checkout readme.txt

$ git checkout readme.txt

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

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

$ git branch * dev master

$ git branch

* dev

  master

Как сделать commit

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

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

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

$ git add &lt;file1&gt; &lt;file2&gt; …

$ git add &lt;file1&gt; &lt;file2&gt; …

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

$ git rm &lt;file1&gt; &lt;file2&gt; …

$ git rm &lt;file1&gt; &lt;file2&gt; …

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

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

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

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

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

$ git pull origin dev $ git pull origin master

$ git pull origin dev

$ git pull origin master

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

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


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

$ git merge project_branch

$ git merge project_branch


7. Заливаем последнюю версию ветки 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 [email protected]:devlab/sharp.git d528335..9a452d9 dev -&gt; 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 [email protected]:devlab/sharp.git

   d528335..9a452d9  dev -&gt; dev


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

 

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

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

$ git status … Unmerged paths: (use «git add &lt;file&gt;…» 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 &lt;file&gt;…» 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

git checkout —ours binary.dat

git add binary.dat

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

git checkout —theirs binary.dat git add binary.dat

git checkout —theirs binary.dat

git add binary.dat

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

 

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

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

$ git log commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a Author: DevLab User &lt;[email protected]&gt; Date: Wed Jul 31 18:35:47 2013 +0400 first commit commit d528335724dfc15461996ed9d44d74f23ce6a075 Author: DevLab User &lt;[email protected]&gt; Date: Wed Jul 31 06:24:57 2013 -0700 Initial commit

$ git log

commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a

Author: DevLab User &lt;[email protected]&gt;

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

    first commit

commit d528335724dfc15461996ed9d44d74f23ce6a075

Author: DevLab User &lt;[email protected]&gt;

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

$ git log | grep -e «first»

    first commit

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

$ git show 99452d955bdb57e7e4f2b09f8ce2fbb6cd56377a commit 99452d955bdb57e7e4f2b09f8ce2fbb6cd56377a Author: DevLab User &lt;[email protected]&gt; 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 &lt;[email protected]&gt;

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

$ git annotate readme.txt

9a452d9c        (DevLab User      2013-07-31 18:35:47 +0400       1)Text

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

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

commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a Author: devlabuser &lt;[email protected]&gt; Date: Wed Jul 31 18:35:47 2013 +0400 first commit commit d528335724dfc15461996ed9d44d74f23ce6a075 Author: devlabuser &lt;[email protected]&gt; Date: Wed Jul 31 06:24:57 2013 -0700 Initial commit

commit 9a452d9cdbdb57e7e4f2b09f8ce2f776cd56657a

Author: devlabuser &lt;[email protected]&gt;

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

    first commit

commit d528335724dfc15461996ed9d44d74f23ce6a075

Author: devlabuser &lt;[email protected]&gt;

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

    Initial commit

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

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

$ git reset —hard 9a452d955bdb57e7e4f2b09f8ce2fbb6cd56377a

HEAD is now at 9a45779 first commit

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

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

$ git reset —hard origin/dev

HEAD is now at 9a45779 first commit

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

git push -f origin master

git push -f origin master

 

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

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

$ git merge origin/ticket_1001_branch

$ git merge origin/ticket_1001_branch

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

$ git pull origin ticket_1001_branch

$ 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 помогает применить один-единственный коммит из одной ветки к дереву другой.

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

2. Обновить ее:

3. Выполнить команду, указать код коммита:

git cherry-pick eb042098a5

git cherry-pick eb042098a5

4. После этого обновить ветку на сервере:

Создать ветку в Git из другой ветки

у меня есть две ветви: мастер и dev

Я хочу создать «ветку» от dev филиала.

В настоящее время на ветке dev, я делаю:

$ git checkout -b myfeature dev

… (какая-то работа)

$ git commit -am "blablabla"
$ git push origin myfeature

но, визуализировав мои ветви, я получил:

--**master**
------0-----0-----0-----0-----0
------------------------**dev**----**myfeature**

Я имею в виду, что ветка, кажется, слил ФФ, и я не понимаю, почему…

что я делаю не так?

вы можете объясните мне, пожалуйста, как вы отделяетесь от другой ветви и возвращаетесь в удаленный репозиторий для ветви функций?

все это в ветвящейся модели, как описанный здесь.

612

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Theme: Overlay by Kaira Extra Text
Cape Town, South Africa