Слияния или мерджи веток. урок 9

Введение¶

Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

Объединяем репозитории

Осталось совсем немного. Переходим в наш уберпроект mainproject и вытягиваем все коммиты из изменённого репозитория библиотеки:

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

Однако сам план зависит от того, как именно Вы хотите слить две ветки. Это зависит, главным образом, от принятой в Вашей команде политики управления ветками в репозитории.

Можно пойти по Linus-way и слить две ветки через обычный merge. В таком случае создастся коммит, у которого будет два предка: один из libfoo, и один из mainproject:

Есть и другой вариант. Например, мы на своём рабочем проекте запретили коммиты с несколькими родителями (ради простой линейной истории коммитов). В таком случае надо сливать ветки через .

И в любом случае не забываем подчистить удалённый репозиторий — он нам больше не нужен!

Common Questions On Git Merge

Can I undo the changes done by the git merge?

Yes, the changes done by the git merge command can be undone through and commands.

What is squashing in Git?

Squashing in Git is compressing all the commits to a single commit. Squashing a commit many times or let say n time for n commits will squash it to a single commit. The following image depicts git squash:

What happens when two users modify the same line and then perform git merge?

This type of situation is merge-conflict in Git. In Git, when two users try to modify the same line, Git gets confused about which changes to keep and which to reject. It is a merge-conflict.

I hope after reading this article you will be able to merge branches in Git with ease.

Happy Learning!

Git tools для продвинутых разработчиков

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

В этом руководстве объясняется, как изменить сообщение о самых последних или старых коммитах Git.

Не задний коммит

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

Перейдите в каталог хранилища в вашем терминале.

Выполните следующую команду, чтобы изменить (изменить) сообщение о последнем коммите:

Команда выполняет перезапись самого последнего коммита новым.

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

Перед изменением сообщения о коммите вы также можете добавить другие ранее забытые изменения:

Задний коммит

Измененный (измененный) коммит — это новый объект с другим SHA-1. Предыдущий коммит больше не будет существовать в текущей ветке.

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

Перейдите в хранилище.

Исправьте сообщение о последнем введенном коммите:

Принудительно нажмите, чтобы обновить историю удаленного хранилища:

Изменение старого или нескольких коммитов

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

Перейдите в хранилище, содержащее сообщение фиксации, которое вы хотите изменить.

Введите , где — количество коммитов, на которых необходимо выполнить ребазинг. Например, если вы хотите изменить 4-й и 5-й последние коммиты, введите:

Команда отобразит последние коммиты в текстовом редакторе по умолчанию:

Перейдите к строкам коммит-сообщения, которое вы хотите изменить, и замените на :

Сохраните изменения и закройте редактор.

Для каждого выбранного коммита открывается новое окно текстового редактора. Измените сообщение о коммите, сохраните файл и закройте редактор.

Принудительно отправить изменения в удаленный репозиторий:

Вывод

Чтобы изменить самое последнее сообщение о , используйте команду а для изменения более старого или многократного сообщения о используйте

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

В этой статье будет показано, как стирать, настраивать, изменять или редактировать «Начать» название экрана запуска Windows 8 с помощью Resource Hacker.

Узнайте, как изменить размер или изменить размер миниатюр панели задач в Windows Vista / 7/8 через взлом реестра. Если вы обнаружите, что размер миниатюр слишком мал, легко увеличивайте его размер.

Git remotes — это указатели на версии репозитория, которые обычно хранятся на других серверах. В этом руководстве объясняется, как изменить URL-адрес пульта Git.

Why do we merge branch in Git?

We create Branches to work separately on a feature without disturbing the main stable branch, also known as the master branch. But, the fate of branches is to get merged. We create them so that they can merge after finishing work on them. Merging a branch into the master branch symbolizes that the feature you were developing into that branch is complete and tested and is now ready to be a part of the software.

A small example will make this clear. Let say you are currently working as usual on your software, and suddenly, a new requirement comes up. It is very urgent and should execute as soon as possible. The straightforward steps for this would be to create a new branch from production or master or any other branch. Work on the feature in this branch. Test this branch. Finally, merge it with the master.

A single repository generally contains multiple branches in Git. A simple merge of two branches is represented pictorially as below:

As seen in the above image, the top branch merges into the master branch after three commits.

Syntax to merge a branch in Git

A merge operation can be executed by typing the command

So what does Git do behind the scenes when you type this command? When the command executes, git replays all the commits from the time this branch got diverted, i.e., from time marked as «1» in the image to the time the branch is merged into the master, i.e., the time marked as «2». These commits that happened since the branch diverged from the master branch will then log to a single branch, i.e., the top branch in our case.

6 ответов

Лучший ответ

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

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

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

… а затем запустите либо

…или

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

Наконец, вы бы сбежали

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

К сожалению, как уже объяснялось, этот подход не удаляет всю историю.

Если вы хотите делать это часто, я бы рекомендовал сразу после запустить что-то вроде

Это поместит пустой коммит в корень вашей истории и пометит его тегом с именем ROOT. Тогда вы можете сделать что-то вроде

Или

Чтобы вернуть вас к первой пустой фиксации.

Чтобы лучше понять, что делает , я рекомендую прочитать это .

kjo
11 Май 2013 в 18:28

Касса к мастеру:

Показать журнал:

Сброс до первой фиксации:

Затем отправьте изменения на удаленный:

Alexey Slusar
20 Ноя 2019 в 13:28

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

Где — это sha1 некоторой исторической фиксации.

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

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

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

Вы также можете переименовывать ветви, чтобы ваши эксперименты имели оригинальные названия веток, например:

Если вы хотите уничтожить ветку , просто выполните:

mvp
11 Май 2013 в 20:57

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

(т.е. в значительной степени то, что сказал VonC)

(добавлен для защиты от неверных меток времени)

Community
23 Май 2017 в 10:31

Вы можете вернуться к первой фиксации:

«Как показать первую фиксацию с помощью ‘git log’? «описывает, как найти первую фиксацию:

(работает, только если нет нескольких корневых веток)

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

Community
23 Май 2017 в 12:02

Просто удалите каталог после проверки вашего первого коммита. Как таковой:

GoZoner
12 Май 2013 в 00:04

Переписываем путь к файлам

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

Добиться этого нам поможет термоядерная команда . Она предназначена для активного редактирования истории в духе “1984”. История изменяется непосредственно через изменение (точнее, пересоздание) коммитов, поэтому все правки необратимы. Неудачное применение может отправить Ваш репозиторий на свалку.

Поэтому внимательно следите за руками:

Флаг командует git-у, что следующая за ним команда должна быть применена к каждому коммиту в цепочке (в нашем случае ко всей ветке master). Фильтрация пройдёт успешно только в том случае, когда команда завершается со статусом 0, и все коммиты удаётся наложить.

Сама команда шелла тоже состоит из двух частей. Сначала мы создаём папку libfoo. Затем перемещаем в неё все файлы, за исключением самой libfoo. Типичный пример мощи шелла: с помощью пайпа ~~и чьей-то матери~~ составляем из базовых команд сложное действие, которое сделает за человека всю монотонную работу.

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

При этом сохранится вся история изменений (хотя, разумеется, изменятся хэши коммитов):

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

Теперь можно заняться и самим слиянием.

Git — создание новой ветви (branch)

В системе Git (как уже упоминалось ранее) имеется механизм ветвления (branches). Попробую на словах объяснить, что он из себя представляет.

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

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

Строка услужливо информирует, что меня автоматически “перебросило” во вновь ветвь . Можно проверить себя, набрав в консоли:

Строка говорит сама за себя.

Отлично! Теперь давайте я внесу некоторые изменения в файлы и и мы вместе посмотрим на результат в окне браузера. Изменения будут касаться добавления блока-обертки, еще нескольких параграфов и другой легкой стилизации.

Не забуду также проиндексировать и зафиксировать внесенные изменения

Обратите внимание на вид команды -. Эта команда является сокращенным вариантом двух команд: и

Применяется, когда нужно “проскочить” этап индексирования и сразу зафиксировать изменения.

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

Log

git log --no-merges --raw --since='2 weeks ago'

Alternatives:

git whatchanged --since='2 weeks ago'

git log --branches --not --remotes

Alternatives:

git log @{u}..

git cherry -v

Показать количество строк, которое добавил/удалил пользователь

git log --author='Your Name Here' --pretty=tformat: --numstat | gawk '{ add += <!-- @doxie.inject start -->; subs += <!-- @doxie.inject end -->; loc += <!-- @doxie.inject start --> - <!-- @doxie.inject end --> } END { printf "added lines: %s removed lines: %s total lines: %s
", add, subs, loc }' -

Alternatives:

git log --author='Your Name Here' --pretty=tformat: --numstat | awk '{ add += <!-- @doxie.inject start -->; subs += <!-- @doxie.inject end -->; loc += <!-- @doxie.inject start --> - <!-- @doxie.inject end --> } END { printf "added lines: %s, removed lines: %s, total lines: %s
", add, subs, loc }' - # on Mac OSX

git log --pretty=oneline --graph --decorate --all

Alternatives:

gitk --all

By sending an email

Prerequisites:

A GitLab administrator must configure incoming email.
A GitLab administrator must configure Reply by email.

On the top bar, select Menu > Projects and find your project.
On the left menu, select Merge requests.
In the top right, select Email a new merge request to this project.
An email address is displayed. Copy this address.
Ensure you keep this address private.
- The To line is the email address you copied.
- The subject line is the source branch name.
- The message body is the merge request description.
Send the email message.

A merge request is created.

Add attachments when creating a merge request by email

Introduced in GitLab 11.5.

The combined size of the patches can be 2 MB.

If the source branch from the subject does not exist, it is
created from the repository’s HEAD or the specified target branch.
You can specify the target branch by using the
quick action. If the source
branch already exists, the patches are applied on top of it.

Set the default target project

Introduced in GitLab 13.11.

Merge requests have a source and a target project that are the same, unless
forking is involved. Creating a fork of the project can cause either of these
scenarios when you create a new merge request:

You target an upstream project (the project you forked, and the default
option).
You target your own fork.

To have merge requests from a fork by default target your own fork
(instead of the upstream project), you can change the default.

On the top bar, select Menu > Project.
On the left menu, select Settings > General > Merge requests.
In the Target project section, select the option you want to use for
your default target project.
Select Save changes.

Disclaimer

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

Поэтому проводите все эксперименты на копиях рабочих репозиториев. Тем более, что клоны в git создаются очень быстро. А когда все манипуляции будут завершены, то репозитории можно синхронизировать через /.

В общем, я считаю, что предупредил Вас. Берегите свои данные!

Rebase

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

Git rebase копирует коммиты из текущей ветки и помещает эти скопированные коммиты поверх указанной ветки.

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

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

Этот пример показывает rebase в ветке. Однако в больших проектах вы обычно не захотите этого делать. Git rebase изменяет историю проекта, поскольку для скопированных коммитов создаются новые хэши.

Rebase отлично подходит, когда вы работаете над feature branch, а master ветка была обновлена. Вы можете получить все обновления в своей ветке, которые предотвратят будущие merge конфликты

Interactive Rebase

Перед rebas’ом коммитов мы можем их изменить! Мы можем сделать это с помощью Interactive Rebase. Interactive Rebase также может быть полезен для ветки, над которой вы сейчас работаете, и хотите изменить некоторые коммиты.