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

Будет создана ветка на основе 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

Создаем новую директорию для проекта project_name, переходим в нее.
Выполняем команду:
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 -b project_branch
git pull origin project_branch

git checkout -b project_branch

git pull origin project_branch

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

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

Создаем новую ветку в локальном репозитории:
$ git checkout -b dev
Switched to a new branch ‘dev’

$ git checkout -b dev
Switched to a new branch ‘dev’
Публикуем ее на 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 readme.txt

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

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

$ git branch
* dev
master

$ git branch

* dev

master

Как сделать commit

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

Список всех измененных и добавленных файлов можно просмотреть командой:
Подготавливаем коммит, добавляя в него файлы командой:
$ git add <file1> <file2> …

$ git add <file1> <file2> …

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

$ git rm <file1> <file2> …

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

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

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

$ git pull origin dev
$ git pull origin master

$ git pull origin dev
$ git pull origin master

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

$ git merge project_branch

$ 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 [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

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

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

Копируем идентификатор коммита, до которого происходит откат.
Откатываемся до последнего успешного коммита (указываем последний коммит):
$ 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 merge выполняет слияние текущей и указанной ветки. Изменения добавляются в текущую ветку.

$ git merge origin/ticket_1001_branch

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

$ 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 cherry-pick eb042098a5

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

Как раскрасить команды 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

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

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

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

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

Как выписать ветку с 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 -b project_branch
git pull origin project_branch

git checkout -b project_branch

git pull origin project_branch

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

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

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

$ 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 readme.txt

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

$ git branch
* dev
master

$ git branch

* dev

master

Как сделать commit

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

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

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

$ git add <file1> <file2> …

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

$ git rm <file1> <file2> …

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

$ 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

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

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 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 —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 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

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

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

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

$ 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

git push -f origin master

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

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

$ git merge origin/ticket_1001_branch

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

$ git pull origin ticket_1001_branch

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

$ mkdir project_dir
$ cd project_dir
$ git init

$ mkdir project_dir

$ cd project_dir

$ git init

git cherry-pick

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

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

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

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

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

автор: Peter Mortensen

4 ответов

Если вам нравится метод в ссылке, которую вы опубликовали, посмотрите на Git Flow.

Это набор скриптов, которые он создал для этого процесса.

но чтобы ответить на ваш вопрос:

$ git checkout -b myFeature dev

создает ветвь MyFeature от dev. Делайте свою работу, а затем

$ git commit -am "Your message"

теперь объединить изменения в dev без перемотки вперед

$ git checkout dev
$ git merge --no-ff myFeature

теперь нажмите изменения на сервере

$ git push origin dev
$ git push origin myFeature

и вы увидите, как вы хотите он.

Если вы хотите создать новую ветку из любой из существующих ветвей в Git, просто следуйте инструкциям.

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

мастер
dev
branch2, равная

Так что если вы хотите создать новую ветку под названием «subbranch_of_b1» под веткой с именем «branch2, равная» выполните действия:

оформить заказ или изменения в «branch2, равная»
```
git checkout branch2
```
Теперь создать новую ветку под названием «subbranch_of_b1» под «branch2, равная» используя следующую команду.
```
git checkout -b subbranch_of_b1 branch2
```
выше будет создана новая ветвь под названием subbranch_of_b1 в филиале branch2, равная (заметим, что branch2 в приведенной выше команде не является обязательным, так как голова в настоящее время указывает на нее, вы можете уточнить ее, если вы находитесь в другой ветви).
Теперь после работы с subbranch_of_b1 вы можете зафиксировать и нажать или объединить его локально или удаленно.

227

автор: Praveen George

создать ветку

создать ветвь при извлечении главной ветви. Здесь коммиты в master будут синхронизированы с созданной вами веткой.
$ git branch branch2
создать ветвь при извлечении branch2 . Здесь коммиты в branch2 будут синхронизированы с branch3
$ git branch branch3

в кассу филиала

ветви переключателя команды проверки git или восстановить файлы рабочего дерева

$ git checkout branchname

переименование филиала

$ git branch -m branch2 newbranchname

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

$ git branch -d branch-to-delete
$ git branch -D branch-to-delete
( принудительное удаление без проверки объединенного состояния )

создание и переключение Бранч

$ git checkout -b branchname

ветви, которые полностью включены

************************** Филиала Различия [ git diff branch2..branch3 ] ************************

многострочный разница

$ git diff master..branch2

Singleline разница

$ git diff --color-words branch2..branch3

автор: Gnanasekar S

сделайте одновременную работу на dev филиала. Что происходит, так это то, что в вашем сценарии ветвь функции движется вперед от вершины ветви dev, но ветвь dev не изменяется. Легче рисовать как прямую линию, потому что ее можно рассматривать как движение вперед. Вы сделали это, чтобы указать A на dev, и оттуда вы просто продолжили параллельный путь. Эти две ветви на самом деле не разошлись.

Теперь, если вы сделаете фиксацию на dev, перед слиянием вы снова начните с того же commit, A, но теперь функции перейдут в C, а dev-в B. Это покажет разделение, которое вы пытаетесь визуализировать, поскольку ветви теперь расходятся.

*-----*Dev-------*Feature

       /----*DevB
*-----*DevA
       \----*FeatureC

автор: ToothlessRebel

git — Создать новую ветку

Переполнение стека

Около
Продукты
Для команд

Переполнение стека
Общественные вопросы и ответы
Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии
Программирование и связанные с ним технические возможности карьерного роста
Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя
Реклама
Обратитесь к разработчикам и технологам со всего мира
О компании

Загрузка…

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

В Git и большинстве других инструментов VCS ветвление является одной из основных конструкций, которые действительно делают его полезным для разработки программного обеспечения. Эти ветки почти как новая копия вашего кода в текущем состоянии, которую затем можно использовать для разработки нового кода.

Например, всякий раз, когда вам нужно создать новую функцию, исправить ошибку или переписать какой-либо код, рекомендуется создать новую ветку, чтобы ни одно из ваших изменений не повлияло на «основную» версию кода.Это важно, поскольку может быть очень сложно вернуть изменения кода из памяти, особенно в сложных системах.

Есть несколько способов создания новых веток в Git, многие из которых отличаются тем, как ваша ветка создается из основной ветки, будь то из текущей ветки, другой ветки, тега и т. Д.

Наиболее распространенный способ создания новой ветки следующий:

  $ git checkout -b <имя-ветки>

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

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

  $ git checkout -b новая ветка dev-ветка
Перешел на ветку new-branch

Другой распространенный способ — напрямую использовать команду branch (которую checkout делает за кулисами):

  $ git branch <имя-ветки>

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

  $ ветка git
* мастер
$ git branch новая ветка
$ git ветка
* мастер
  новая ветка

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

  $ git checkout новая ветка
Перешел на ветку new-branch

Создание ветви из коммита

Как упоминалось выше, есть несколько других способов создания новых веток.Один из таких способов — указать конкретный коммит через его хэш:

  $ git branch <имя-ветки> <хэш>

Как всегда с Git, на самом деле не нужно указывать весь хеш, всего несколько символов.

  $ ветка git
* мастер
$ git branch commit-branch 735c5b4
$ git ветка
  коммит-ветка
* мастер

Вы также можете использовать синтаксис git checkout -b , который создаст ветку и проверит ее, все в одной команде.

Создание ответвления из тега

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

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

  $ git branch tag-branch v0.4.12
$ git ветка
  тег-ветвь
* мастер

И снова можно использовать синтаксис git checkout -b <имя-ветки> <тег> .

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

Git упрощает создание веток и управление ими. Фактически, мощность и гибкость модели ветвления — одно из самых больших преимуществ Git!

Есть несколько разных вариантов использования при создании веток в Git. Давайте рассмотрим каждый из них по очереди.

Как мне создать новую ветку на основе текущей HEAD ?

Чтобы создать новую ветку, основанную на вашей текущей ветке (HEAD), просто используйте «git branch» с именем новой ветки в качестве единственного параметра:

  $ git branch <новая ветка>

Как мне создать новую ветку на основе существующей ветки ?

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

  $ git branch <новая-ветка> <базовая-ветка>

Если вы используете клиент Tower Git, вы можете просто использовать перетаскивание для создания новых веток (а также для слияния, выбора вишни и т. Д.):

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

Если вы хотите запустить новую ветку на основе определенной фиксации (а не ветки), вы можете указать хеш фиксации в качестве отправной точки:

  $ git branch <новая ветка> f71ac24d

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

Вы также можете создать новую ветку на основе определенного тега, который уже есть в вашем репозитории:

  $ git branch <новая ветка> v1.2

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

Чтобы использовать удаленную ветку в качестве основы для вашей новой локальной ветки, вы можете использовать опцию «—track»:

  $ git branch --track <новая-ветка> origin / <базовая-ветка>

В качестве альтернативы вы также можете использовать для этого команду «checkout». Если вы хотите назвать локальную ветку, как удаленную, вам нужно только указать имя удаленной ветки:

  $ git checkout --track origin /

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

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

  $ git push -u origin <локальная-ветка>

Флаг «-u» указывает Git установить «отслеживающее соединение», что в будущем значительно упростит отправку и извлечение.

Что делает команда «git branch»?

Команда «git branch» используется для множества задач:

создание новых местных филиалов
удаление существующих локальных или удаленных филиалов
со списком локальных и / или удаленных филиалов
со списком ветвей, например еще не объединены

Узнать больше

Git — книга

2-е издание (2014)

Загрузить электронную книгу

Вся книга Pro Git, написанная Скоттом Чаконом и Беном Штраубом и опубликованная Apress, доступна здесь. Все содержимое находится под лицензией Creative Commons Attribution Non Commercial Share Alike 3.0. Печатные версии книги доступны на 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
  Базовое ветвление и слияние
3. 3.3
  Управление филиалом
4. 3,4
  Ветвление рабочих процессов
5. 3.5
  Удаленные филиалы
6. 3,6
  Ребазинг
7. 3,7
  Резюме
1. 4.1
  Протоколы
2. 4.2
  Получение Git на сервере
3. 4.3
  Создание вашего открытого ключа SSH
4. 4.4
  Настройка сервера
5. 4.5
  Git Daemon
6. 4.6
  Умный HTTP
7. 4.7
  GitWeb
8. 4.8
  GitLab
9. 4.9
  Сторонние варианты размещения
10. 4.10
  Резюме
1. 5.1
  Распределенные рабочие процессы
2. 5.2
  Вклад в проект
3. 5.3
  Сопровождение проекта
4. 5,4
  Резюме
1. 6.1
  Настройка и конфигурация учетной записи
2. 6.2
  Вклад в проект
3. 6.3
  Сопровождение проекта
4. 6.4
  Управление организацией
5. 6.5
  Создание сценариев на GitHub
6. 6,6
  Резюме
1. 7.1
  Выбор редакции
2. 7.2