Владеешь merge

revert, checkout, reset

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

git revert

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

Откатиться с помощью commit-хэшей:

Можно и с помощью диапазонов:

Действие git revert

git checkout

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

Для переключения между ветками:

Для проверки более старого коммита с помощью хэша:

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

Чтобы отменить все локальные незакоммиченные изменения:

Чтобы отменить определенное локальное незакоммиченное изменение:

Действие git checkout

—mixed

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

—hard

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

Действие git reset

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

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

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

Вводный урок
1. Установка и базовая настройка git
2. Создание и клонирование репозитория git
3. Делаем первые изменения, git status и git diff
4. Коммиты и история коммитов, git commit, git log и git show
5. Подробнее об истории коммитов. Путешествие по истории
6. Работа с сервером, git push и git pull
7. Ветки — главная фишка git, git branch и git checkout
8. Работа с ветками на сервере, git fetch
9. Слияния или мерджи веток, git merge
10. Конфликты и их разрешение
Платная часть курса. Презентация
* 11. Работа с gitignore и git exclude
* 12. Буфер обмена git, git stash
* 13. Копирование коммитов, git cherry-pick
* 14. Отмена и редактирование последнего коммита
* 15. Отмена произвольного коммита, git revert
16. Склеивание коммитов, git rebase —interactive и git reflog
* 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
* 18. Работа с git rebase. Отличия от merge
* 19. Что такое git push —force и как с ним работать
* 20. Ищем баги с помощью git, git bisect
* 21. Как и зачем работать с тегами git
* 22. Процессы: github flow и git flow
* 23. Псевдонимы в git
24. Мердж-реквесты
* 25. Форки

* платные уроки

список обновляется…

Создание merge request

Идём на GitLab, находим модуль, в котором мы опубликовали свою ветку, далее на закладке Merge requests и нажимаем кнопку Create merge request.

Вводим

Заголовок обязательно должен включать номер задачи в Jira и тему, характеризующую изменения.
В можем указывать какие именно изменения были сделаны, почему предпочтение отдано именно такому подходу.
Дополнительно здесь можно указать информацию, которая может быть полезна ревьюверу чтобы сориенироваться в предлагаемых правках.
А также упомянуть тех, кому эти изменения могут быть интересны (чьё мнение вам важно). Для этого введите
Здесь работает .
Проверяем что в список попали только коммиты с вашей ветки.
Выбираем того, кому предстоит принимать ваш запрос из выпадающего списка .
Ставим галку .
Жмём

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

Немного о философии коммитов

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

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

В любом проекте важны не только код и его структура, но и история коммитов и хорошие commit message.

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

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

Следующий урок ⇨
Урок 5. История коммитов в подробностях. Путешествие по истории

⇦ Предыдущий урок
Урок 3. Первые изменения, git status и git diff

Просмотр истории коммитов

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

Помимо автора и даты, у каждого комита есть идентификатор, который называется hash. Пример: 2934ee19f4d4ca37ff9bea9dc8208ef5362d789e. Необязательно использовать такую длинную запись, git поймет и по первым 5 символам, какой hash вам нужен.

Команда имеет очень большое количество опций для поиска коммитов по разным критериям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

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

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

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

Что такое мердж или слияние веток

Это перенос кода из одной ветки в другую. Например, когда мы заканчиваем работу над веткой, например, сделали новый функционал или поправили багу, мы сливаем ее в мастер. В мастере код проверяется еще раз и выкладывается на боевой сервер.

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

Разница логическая

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

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

Следует четко различать мердж своей ветки в мастер и мердж мастера в свою ветку.

Простейшее перебазирование

Если вы вернётесь к более раннему примеру из «», вы увидите, что разделили свою работу и сделали коммиты в две разные ветки.

Рисунок 35 – История коммитов простого разделения

Как мы выяснили ранее, простейший способ выполнить слияние двух веток – это команда . Она осуществляет трёхстороннее слияние между двумя последними снимками сливаемых веток (C3 и C4) и самого недавнего общего для этих веток родительского снимка (C2), создавая новый снимок (и коммит).

Рисунок 36 – Слияние разделённой истории коммитов

Однако есть и другой способ: вы можете взять те изменения, что были представлены в C4, и применить их поверх C3. В Git это называется перебазированием. С помощью команды вы можете взять все коммиты из одной ветки и в том же порядке применить их к другой ветке.

В данном примере переключимся на ветку и перебазируем её относительно ветки следующим образом:

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

Рисунок 37 – Перебазирование изменений из C4 поверх C3

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

Рисунок 38 – Перемотка ветки master

Теперь снимок, на который указывает C4′ абсолютно такой же, как тот, на который указывал C5 в . Нет абсолютно никакой разницы в конечном результате между двумя показанными примерами, но перебазирование делает историю коммитов чище. Если вы взглянете на историю перебазированной ветки, то увидите, что она выглядит абсолютно линейной: будто все операции были выполнены последовательно, даже если изначально они совершались параллельно.

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

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

Перебазирование (rebase) против слияния (merge)

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

Одна из точек зрения заключается в том, что история коммитов в вашем репозитории – это запись того, что на самом деле произошло. Это исторический документ, ценный сам по себе, и его нельзя подделывать. С этой точки зрения изменение истории коммитов практически кощунственно; вы лжёте о том, что на самом деле произошло. Но что, если произошла путаница в коммитах слияния? Если это случается, репозиторий должен сохранить это для потомков.

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

Теперь к вопросу о том, что лучше – слияние или перебазирование (надеюсь, вы видите, что это не так просто). Git – мощный инструмент, позволяющий вам делать многое с вашей историей, однако каждая команда и каждый проект индивидуален. Теперь, когда вы знаете, как работают оба эти приёма, выбор, какой из них будет лучше в вашей ситуации, зависит от вас.

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

Полезные команды git

rebase -i

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

fixup

cherry-pick

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

Пример:

add/checkout/reset

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

diff --git a/README.md b/README.md
index 7b45277..6b1993c 100644
--- a/README.md
+++ b/README.md
@@ -186,10 +186,13 @@ bebebe Corrige nome de método na classe InventoryBackend
 ``
 # Bad (mixes English and Portuguese)
 ababab Usa o InventoryBackendPool para recuperar o backend de estoque
-efefef Add `use` method to Credit model
 cdcdcd Agora vai
 ``

+### Template
+
+This is a template, (http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the (https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).
+
 ## Участие в проекте

 Any kind of help would be appreciated. Example of topics that you can help me with:
@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi

 - (https://chris.beams.io/posts/git-commit/)
 - (https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)
+- (https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)

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

часть 1

@@ -186,7 +186,6 @@
 ``
 # Bad (mixes English and Portuguese)
 ababab Usa o InventoryBackendPool para recuperar o backend de estoque
-efefef Add `use` method to Credit model
 cdcdcd Agora vai
 ``

Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]?

часть 2

@@ -190,6 +189,10 @@
 ``
 cdcdcd Agora vai
 ``

+### Template
+
+This is a template, (http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), which appears in the (https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project).
+
 ## Contributing

 Any kind of help would be appreciated. Example of topics that you can help me with:
Stage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]?

часть 3

@@ -202,3 +205,4 @@ Any kind of help would be appreciated. Example of topics that you can help me wi

 - (https://chris.beams.io/posts/git-commit/)
 - (https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines)
+- (https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)

Теоретические сведения

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

Основная цель создание дополнительных веток – проработать отдельный элемент проекта автономно а затем присоединить его к проекту. Поэтому в большинстве случаев эти ветки в конечном итоге объединяются с веткой . Процедура объединения веток называется слияние (merge).

Для слияния текущей ветки с какой-либо другой используется команда

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

Изменения, происходящие с репозиторием при выполнении команды схематично показаны на рисунках 3 и 4.

Рисунок 3 – Состояние репозитория до слияния

Рисунок 4 – Состояние репозитория после слияния

После слияния веток одна из них становится лишней. Ее можно удалить командой .

Типичная последовательность действий, которой завершается работа над какой-либо задачей проекта в отдельной ветке (назовем ее для примера ), будет такой:

Конфликты при слиянии

При слиянии может возникнуть ситуация, когда фрагмент в каком-либо файле проекта в различных ветках отредактирован по разному. Такая ситуация называется конфликт (conflict).

В случае возникновения конфликтов git заносит в создаваемый при объединении коммит файл, содержащий текст обоих версий. Начало конфликтного фрагмента помечается строкой, начинающиеся с символов и содержащей имя первой ветки, а заканчивается строкой, начинающиеся с символов и содержащей имя вливаемой ветки. Версии из каждой ветки разделяются строкой с символами . Такой файл получает статус не объединенный (unmerged).

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

Перемещение

В СКВ git существует альтернативный способ объединения веток. Он называется Перемещение (rebase, часто переводиться как перебазирование).

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

Рисунок 5 – Состояние репозитория после перемещения

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

Какой способ объединения веток использовать (слияние или перемещение) во многом является делом вкуса. Слияние сохраняет историю коммитов, а перемещение позволят прибраться в структуре коммитов. Единственное существенное ограничение, которое накладывается на выбор операции, состоит в том, что перемещение нельзя использовать для коммитов, для которых есть копии в других репозиториях или на сервере (подробнее копирование репозиториев рассмотрено в следующей работе).

Примечание

Используйте команду только в своём локальном репозитории. Её применение в удалённых репозиториях может привести к огромной путанице.

Наведение порядка в истории коммитов

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

Рекомендуется поддерживать синхронизацию между локальным и удалённым репозиториями. Это позволяет избежать множества конфликтов, связанных со слиянием, возникающих при слишком редкой синхронизации репозиториев. Следуя этой практике, вы решаете загружать изменения из удалённого репозитория каждые два дня.

Каждый раз, когда вы загружаете код из удалённого в локальный репозиторий, в локальном репозитории создаётся новый коммит-слияние (Merge Commit). Это означает, что в вашей локальной истории коммитов будет много таких коммитов, которые могут запутать того, кто будет просматривать ваш код.

История коммитов в локальном репозитории

Как привести в порядок историю коммитов? Для решения этой задачи можно воспользоваться командой .

Команда git rebase

Рассмотрим команду на примере.

Коммиты в ветке Release и в ветке Feature

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

Будем использовать для двух рассматриваемых веток имена и .

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

Особенности команды rebase

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

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

Ветка Feature и три шага работы команды rebase

Не спеша, эффективно и правильно – путь разработки. Часть 3. Практика

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация “Эксперт”, несколько успешных проектов класса “сверхтяжелая”. Успешные проекты ЦКТП. Четыре года работал в самой “1С”, из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

Шаг 3

После того, как в ветку добавлен коммит , Git пытается добавить туда же . Тут, опять же, если конфликтов нет, то добавляется после и операция оказывается успешно завершённой. Если обнаружен конфликт, то Git, как и прежде, сообщит об этом и предложит с ним разобраться.

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

Примечание

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

В случае использования команды вы получите коммит-слияние. В случае использования никаких дополнительных коммитов у вас не будет.

Рекомендуется использовать эти команды в различных ситуациях. Так, подходит для обновления кода локального репозитория на основе свежего кода из удалённого репозитория. Используйте команду , выполняя пулл-запросы, направленные на слияние ветки с веткой или .

Итоги

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

Опасности перемещения

Но даже перебазирование, при всех своих достоинствах, не лишено недостатков, которые можно выразить одной строчкой:

Не перемещайте коммиты, уже отправленные в публичный репозиторий

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

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

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

Рисунок 44 – Клонирование репозитория и выполнение в нём какой-то работы

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

Рисунок 45 – Извлекаем ещё коммиты и сливаем их со своей работой

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

Рисунок 46 – Кто-то выложил перебазированные коммиты, отменяя коммиты, на которых основывалась ваша работа

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

Рисунок 47 – Вы снова выполняете слияние для той же самой работы в новый коммит слияния

Если вы посмотрите в этот момент, вы увидите два коммита с одинаковыми авторами, датой и сообщением, что может сбить с толку. Помимо этого, если вы отправите свою историю на удалённый сервер в таком состоянии, вы вернёте все эти перебазированные коммиты на сервер, что ещё больше всех запутает. Логично предположить, что разработчик не хочет, чтобы C4 и C6 были в истории, и именно поэтому он перебазируется в первую очередь.

Заключение

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

Такой подход равносилен высказыванию: “Хоть у меня и отличная машина, но лучше я ограничусь первой передачей, ведь скоростная езда смертельно опасна”. А почему бы не научиться переключать передачи и безопасно передвигаться на высоких скоростях?!

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

Как-то в самом начале моей карьеры разработчика я получил один из лучших советов от более опытного коллеги. Звучит он так: “Хватит стучать по клавишам в Source Tree, лучше научись использовать команды Git из терминала! Иначе ты не познаешь все возможности Git, и в перспективе не сможешь программировать автоматические конвейеры.”

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

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

Благодарю за внимание и желаю удачи в развитии навыков управления исходным кодом

Продвинутый функционал Git: хитрые приемы и команды
Поддержание документации в актуальном состоянии с помощью Bit и GitHub
Как на самом деле работает Git

Читайте нас в Telegram, VK и