35. Слияние в ветку master

Цели

• Мы поддерживали соответствие ветки style с веткой master (с помощью rebase), теперь давайте сольем изменения style в ветку master.

01 Слияние style в master

Выполните:

git checkout master git merge style

Результат:

$ git checkout master Switched to branch ‘master’ $ $ git merge style Updating 6c0f848..6e6c76a Fast-forward index.html | 2 +- lib/style.css | 8 ++++++++ lib/hello.html | 6 ++++— 3 files changed, 13 insertions(+), 3 deletions(-) create mode 100644 lib/style.css

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

При быстрой перемотке конфликтов быть не может.

02 Просмотрите логи

Выполните:

git hist

Результат:

$ git hist * 6e6c76a 2011-03-09 | Updated index.html (HEAD, master, style) [Alexander Shvets] * 1436f13 2011-03-09 | Hello uses style.css [Alexander Shvets] * 59da9a7 2011-03-09 | Added css stylesheet [Alexander Shvets] * 6c0f848 2011-03-09 | Added README [Alexander Shvets] * 8029c07 2011-03-09 | Added index.html. [Alexander Shvets] * 567948a 2011-03-09 | Moved hello.html to lib [Alexander Shvets] * 6a78635 2011-03-09 | Add an author/email comment [Alexander Shvets] * fa3c141 2011-03-09 | Added HTML header (v1) [Alexander Shvets] * 8c32287 2011-03-09 | Added standard HTML page tags (v1-beta) [Alexander Shvets] * 43628f7 2011-03-09 | Added h1 tag [Alexander Shvets] * 911e8c9 2011-03-09 | First Commit [Alexander Shvets]

Теперь ветки style и master идентичны.

1 декабря, 2014, обновлено 26 марта, 2016

Git

Команды Git

git clone

— копирует репозиторий и устанавливает настройки для наблюдения за оригиналом (применяются в командах fetch, push, pull).

$ git clone repo

— копирует репозиторий сохранив название корневой папки.

$ git clone repo newRepo

— копирует репозиторий переименовав корневую папку репозитория.

$ git clone git@github.com:/zlatov/simpleparser.git

— скопирует репозиторий в папку simpleparser.

$ git clone git@github.com:/zlatov/simpleparser.git temp

— скопирует репозиторий в папку temp.

git status

— показывает текущее состояние репозитория.

git init

— создаёт новый репозиторий.

$ git init —bare

— создать „голый“ репозиторий в текущей папке (используется как централизованное хранилище).

$ git init repo

— создать папку „repo“ в текущей папке и создать в ней репозиторий.

$ git init —bare repo

— аналогично предыдущему примеру, но создаётся „голый“ репозиторий.

git add

— добавляет файл или группу файлов в index (staging area).

$ git add .

— добавить все файлы и папки текущей директории в index.

$ git add path/to/file1

— добавить только один файл (или папку) в index.

$ git add . $ git add -u

— добавляем в индекс измененные и новые и удаляем из индекса удаленные файлы

git commit

— переносит изменения из index (staging area) в local repo.

$ git commit -m «comment»

— фиксирует изменения, добавленные в staging area.

$ git commit -a -m «comment»

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

git checkout

— загрузить любое состояние репозитория (checkout можно выполнить, только тогда, когда у нет никаких изменений в текущем состоянии). При каждой операции checkout ссылка HEAD указывает на текущее положение (читать как: метка HEAD — это текущее состояние репозитория, т.е. переносится чекаутом).

$ git checkout branchNameOrCommitHash

Например:

$ git checkout a71b72

— при таком переключении меняется текущая ветка на ветку «(no branch)».

$ git checkout master

— переключиться на ветвь master (переключение происходит на верхушку ветви).

$ git checkout master~1

— переключиться на одну фиксацию назад относительно верхушки ветви master.

$ git checkout head~1

— переключиться на одну фиксацию назад относительно текущего вашего положения.

$ git checkout a71b72~3

— переключиться на три фиксации назад относительно фиксации с именем, начинающимся на «a71b72».

$ git checkout -b branchName branchNameOrCommitHash

— переключается на фиксацию branchNameOrCommitHash и тут же создаёт от неё новую ветвь branchName и переключается на эту ветвь. Примечание: если переключиться назад, то команда git log не покажет историю «будущего», но история не потерена, выполните команду git log —all, чтобы увидеть и узнать hash последнего коммита и перейти к нему, если неоходимо; или выполните команду git checkout master, чтобы сразу перейти на верхушку ветки.

git branch

— просмотр, создание и удаление ветвей разработки.

$ git branch

— просмотреть список существующих ветвей и узнать какая ветвь выбрана текущей.

$ git branch -r

— просмотреть список удалённых ветвей.

$ git branch branchName

— создать ветвь с именем name. Создание ветви не приводит к переключению в эту ветвь.

$ git checkout -b branchName

— создать ветвь и переключиться на нее.

$ git branch -d branchName

— удаляет ветвь branchName. Если ветвь ещё не была с лита с основной ветвью, то git предупредит об этом и удаления не будет.

$ git branch -D branchName

— удаляет ветвь branchName, даже если вы ещё не сливали её изменения с основной ветвью.

$ git checkout master $ git merge testing $ git branch -d testing

— после выполненных работы в ветке testing сольём с рабочей веткой master, после чего не забываем удалить ненужную ветвь.

git diff

— увидеть изменения между work tree и index или между index и local repo.

$ git diff

— изменения между work tree и index (внесенны изменения, но не проиндексированы).

$ git diff —cached

— изменения между index и local repo (проиндексированные изменения, но не закомичены).

$ git diff master~2..master

— изменения при перемещении от фиксации master~2 к фиксации master.

Возможно указание фиксаций в обратном порядке при этом логика изменений поменяется. Возможно указание разных веток.

git log

— история фиксаций.

$ git log

— от начала до текущего состояния HEAD.

$ git log branchNameOrCommitHash

— от начала до указанной ветви или фиксации.

$ git log branchNameOrCommitHash..branchNameOrCommitHash

— история указанного диапазона.

$ git log branchName…branchName

— общая история указанного диапазона (по всем веткам).

$ git log FETCH_HEAD

— от начала до состояний FETCH_HEAD (состояние FETCH_HEAD доступно после операции fetch или pull).

$ git log HEAD..FETCH_HEAD

— от места совпадения HEAD и FETCH_HEAD, и до конца истории.

$ git log HEAD…FETCH_HEAD

— общая историю от места совпадения HEAD и FETCH_HEAD, и до конца истории.

git remote

— наблюдения за удаленными репозиториями.

$ git remote

— список существующих.

$ git remote add name path

— добавляет с именем name расположенного по пути path.

$ git remote rm name

— удаляет с именем name.

$ git remote rename remoteNameOld remoteNameNew

— переименовывает из remoteNameOld в remoteNameNew.

git fetch

— загрузить удалённый репозиторий в раздел «наблюдения» локального репозитория. Загрузить репозиторий — ещё не значит «слиться» с ним. Для слияния используется команда git merge.

$ git fetch

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

$ git fetch repo branch

— подгружает содержимое ветки branch репозитория repo в объект состояния FETCH_HEAD.

git merge

— слияние двух состояний HEAD и FETCH_HEAD в новое HEAD состояние. Если происходит конфликт изменений, то эти файлы выходят из index (staging area), до тех пор, пока вы не исправите конфликт и не поместите их обратно в index командой . Команда слияния всегда занимает отдельную фиксацию, при слиянии не допускается изменение каких-либо файлов.

$ git merge branch

— слить ветку branch с текущей веткой.

git pull

— подгрузка и слияние. Данная операция аналогична последовательному выполнению двух операций: git fetch и git merge.

$ git pull

— обновить текущую ветку репозитория до состояния другой локальной или удалённой текущей ветки репозитория.

$ git pull repoName branchName

— обновить ветку branchName локального репозитория до состояния удалённой ветки branchName репозитория repoName.

git push

— втолкнуть изменения текущего репозитория в удалённый. По умолчанию, вталкивать данные можно только в «голые» репозитории.

$ git push

— вталкивает данные всего локального репозитория в соответствующие ветки удалённого репозитория.

$ git push origin master

— вталкивает данные текущей ветви в ветвь master удалённого репозитория origin. Если ветвь master не существует в удалённом репозитории, она будет создана.

Лучший (и безопасный) способ объединения ветки git в мастер

Если для удалённой ветви невозможно выполнить FAST-FORWARD слияние, то данные не будут «втолкнуты» (об этом будет сообщено). Данный способ вызова команды является первым при первой фиксации в пустой удалённый репозиторий.

git reset

— откатить изменения или неудачное слияние до последнего стабильного состояния (до последней фиксации).

$ git reset

— отменит операцию слияния, но оставит изменения в конфликтующих файлах и/или в index области. При этом состоянии Git будет ожидать от вас фиксации или полной отмены изменений.

$ git reset —hard

— отменит операцию слияния, очистит index область и вернёт все файлы work tree до состояния последней фиксации по текущей ветви.

git tag

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

Используется для создания списка стабильных версий проекта. Имя метки tag может использоваться в командах checkout и других командах, на ровне с именами фиксаций, именами ссылок (HEAD, FETCH_HEAD) и именами веток (master и т.п.).

$ git tag

— список существующих tag-ов

$ git tag -m «описание» tagname

— создать метку tag для текущего состояния (на текущей ветке) с именем tagname.

$ git tag -d tagname

— удалить метку tag с именем tagname

Управление ветвлением и слиянием

Один git репозиторий может заключать в себе множество ветвей разработки. Чтобы создать новое ответвление под именем «experimental», выполните команду

Теперь если вы выполните

то получите список всех существующих ветвей:

Ветка «experimental» это та, которую вы только что создали, а ветка «master» это ветка по умолчанию которая создается автоматически. Звездочка указывает в какой ветке вы в данный момент находитесь; наберите

чтобы переключиться в ветку experimental. Теперь отредактируйте файл, выполните комит, и переключитесь обратно в главную ветку «master»:

Убедитесь, что сделанные изменения невидимы, поскольку они были сделаны в ветке experimental, а вы сейчас в главной ветке «master».

Вы можете сделать другое изменение в ветке «master», затем выполнить коммит:

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

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

Как только вы отредактировали файлы вызывающие конфликты выполните,

это выполнит коммит результат слияния. В заключении,

покажет наглядное графическое представление истории.

Теперь вы можете удалить ветку experimental командой

Эта команда гарантирует что изменения в ветке experimental уже в текущей активной ветке.(Прим. переводчика: если вы попытаетесь удалить ветку которую вы не слили со своей рабочей git выведет предупреждение и попросит вас выполнить след.команду $ git branch -D experimental)

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

Ветки это легко и просто, и это хороший способ попробовать что то новое.

Как сливать ветки

Вы можете объединить две разошедшиеся ветки разработки используя git merge:

сливает изменения сделанные в ветке «branchname» в активную(рабочую) ветку. Если присутствуют конфликты — например один и тот же файл модифицирован разными способами в удаленной и локальной ветках — то вы будете предупреждены; вывод будет выглядеть след. образом:

Отметки конфликтов останутся в проблемных файлах, и после того как вы исправите их вручную, вы можете обновить индекс и выполнить git commit, как вы обычно это делаете когда изменяете файл.

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

Исправление конфликтов при слиянии

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

Файлы с конфликтами отмечаются в индексе особым образом, так что до тех пор пока вы не исправите проблему и не обновите индекс, выполненить git commit не удастся:

Также, git status перечислит эти файлы как «unmerged», а файлы с конфликтами будут иметь добавленные отметки, и выглядеть след.образом:

Все что вам нужно это отредактировать файлы, исправить конфликты, а затем выполнить

Заметьте что сообщение-описание коммита уже будет содержить некоторую информацию о слиянии.

Обычно вы можете оставить это сообщение-описание, а также можете добавить свои дополнительные комментарии, если пожелаете.

Теперь вы знаете все что вам нужно чтобы выполнить простое слияние. Но git предоставляет больше информации, чтобы помочь разрешить конфликты:

Отменить слияние

Если в процессе слияния и исправления конфликтов,вы застряли и решили сдаться и выбросить все к черту, то вы всегда можете вернуться с состоянию pre-merge (такое же как и было до того как вы запустили слияние) выполнив

Если вы уже выполнили коммит после слияния, и вы хотите сбросить его,

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

fast-forwarding слияния

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

Однако в некоторых случаях когда активная ветка не отклонилась от другой — и каждый коммит в активной ветке уже содержится в другой — то git просто выполняет «fast forward»; голова активной ветки перемещается вперед и указывается на голову сливаемой ветки, без создания каких-либо новых коммитов.

gitcast:c6-branch-merge

Однажды, работая с git репозиторием вы можете случайно отправить (закомитить) в репозиторий свои личные логины, пароли или SSH ключи. Конечно, с помощью можно удалить файл, но файл так же будет присутствовать в истории. К счастью есть утилиты которые позволяют удалить файл из git репозитория полностью. В это статье описано как использовать BFG Repo-Cleaner и git-filter-branch для полного удаления файла из git репозитория.

Важно: после того, как файл с приватными данными попал в репозиторий, все данные в нем можно считать скомпроментированными, и необходимо незамедлительно предпринять меры (поменять пароли, и т.д.).

Нет возможности проследить успел ли кто либо посмотреть или скачать эти файлы.

git-filter-branch

Начать пожалуй стоит с , так как эта утилита является частью git и не требует установки.

Переходим в директорию с нужным проектом:

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

Предположим, что мы случайно закомитили в репозиторий файл в котором у нас храниться пароль к базе данных. Проект в активной разработке и испольуется тестовая база данных, но по привычке пароль использовали такой же какой для входа в систему или ещё куда либо. Знакомая ситуация? 🙂

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

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

Если есть ещё файлы которые необходимо удалить — выполняете эту команду для каждого из них.

Важно: дабы избежать повторения этой неприятной ситуации, файл необходимо добавить в :

Теперь закомитим все наши изменения:

Если использовали теги:

Важно: после всех проделанных изменений всем остальным кто работал с этим репозиторием, необходимо сделать rebase.

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

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

🙂

BFG Repo-Cleaner

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

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

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

Выводы

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

• Использовать программы с графическим интерфейсом для работы git. Они наглядно показывают какие файлы будут добавлены в коммит. Во всех средах разработки как правило есть либо дополнения, либо встроенные средства для работы с git которые помогают избежать таких ошибок. Если среда разработки которую вы используете не имеет средств работы с git, то есть графические интерефейсы. Я когда-то писал небольшой обзор графических интерфейсов для git;
• Избегать таких опасных команд как , и . Вместо них добавлять отдельные файлы с ;
• Использовать чтобы интерактивно просматривать и добавлять файлы;
• Перед добавлением файлов внимательно просматривать какие файлы были изменены и могут попасть в коммит .

Полезные ссылки:

В данной статье мы рассмотрим основы управления ветками в Git.

Операция branch позволяет нам создавать новую линию разработки. Мы можем использовать данную операцию для разделения процесса разработки на несколько различных направлений. Например, у нас есть готовый проект с версией 1.0 и мы хотим начать работу над новой версией 2.0. При этом мы хотим, чтобы наша версия 1.0 была неизменной, поэтому имеет смысл вести разработку новой версии отдельно от версии 1.0

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

Для создания новой ветки нам необходимо использовать следующую команду:

Теперь посмотрим, какие именно ветки есть в нашем проекте:

Звёздочкой отмечена активная ветка master – которая является главной веткой проекта по умолчанию.

Переключение между ветками
Для переключения между ветками используется следующая операция:

Графически это можно представить следующим образом:

Мы можем объединить процесс создания новой ветки и переключения на неё.

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

Проверим какие ветки есть в проекте, и какая из них активна:

Предположим, что мы внесём изменения в ветке new_branch.
Структура проекта в ветке master выглядит так:

Добавим новый класс в ветке new_branch, а именно, добавим новый класс:

Customer.java

И подтвердим данные изменения:

Посмотрим структуру проекта в ветке new_branch:

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

И проверим структуру проекта:

Как мы видим, ветка master осталась неизменной.

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

Слияние веток

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

И выполняем следующую команду:

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

Удаление веток

На данный момент в нашем проекте есть следующие ветки:

Ветки new_branch и version_2.0 нам больше не нужны и мы можем их удалить.
Для удаления веток используется следующая команда:

Повторим процесс для ветки version_2.0

Теперь проверим ветки проекта:

На этом мы заканчиваем изучение управления ветками и изучение технологии Git.

Более подробно с Git вы можете ознакомиться, изучив книгу Pro Git по ссылке: https://git-scm.com/book/en/v2

14. Отмена локальных изменений (до индексации)

Цели

• Научиться отменять изменения в рабочем каталоге

01 Переключитесь на ветку Master

Убедитесь, что вы находитесь на последнем коммите ветки master, прежде чем продолжить работу.

Выполните:

git checkout master

02 Измените hello.html

Иногда случается, что вы изменили файл в рабочем каталоге, и хотите отменить последние коммиты. С этим справится команда .

Внесите изменение в файл hello.html в виде нежелательного комментария.

Файл: hello.html

<html> <head> </head> <body> <h1>Hello, World!</h1> <!— This is a bad comment. We want to revert it. —> </body> </html>

03 Проверьте состояние

Сначала проверьте состояние рабочего каталога.

Выполните:

git status

Результат:

$ git status # On branch master # Changes not staged for commit: # (use «git add <file>…» to update what will be committed) # (use «git checkout — <file>…» to discard changes in working directory) # # modified: hello.html # no changes added to commit (use «git add» and/or «git commit -a»)

Мы видим, что файл был изменен, но еще не проиндексирован.

04 Отмена изменений в рабочем каталоге

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

Выполните:

git checkout hello.html git status cat hello.html

Результат:

$ git checkout hello.html $ git status # On branch master nothing to commit (working directory clean) $ cat hello.html <html> <head> </head> <body> <h1>Hello, World!</h1> </body> </html>

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