Git расширенные расширенные операции

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

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

ОТСОЕДИНЕННАЯ ГОЛОВА

В Git мы обычно думаем о HEAD как об указателе на текущую ветку, но если вы извлекаете (извлекаете) ссылку, которая не является локальной веткой (например, тегом, удаленной веткой, идентификатором SHA-1 или относительным ссылки, такие как main~3), то вы войдете в особое состояние, называемое состоянием "отключенный указатель головы".

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

 Если вы сделали коммит, находясь в состоянии «отсоединенная голова», а затем переключились на другую ветку (например main), коммиты, которые вы сделали в состоянии «отсоединена голова», могут быть потеряны. Если вы хотите сохранить коммиты, сделанные в состоянии «отсоединенной головы», вы должны создать новую ветку, чтобы ссылаться на эти коммиты перед переключением веток. Вы можете использовать git checkout -b nameкоманды для создания и переключения на новую ветку. Эта команда создаст новую ветку и переключит указатель HEAD на эту новую ветку, чтобы коммиты, сделанные вами в состоянии «отключенный указатель головы», не были потеряны.

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

Лиса

Краткий обзор основ rebase: если вы используете git rebase main в своей функциональной ветке, эта команда вытянет все коммиты в функциональной ветке и повторно применит их поверх последней фиксации из основной ветки.

Если на исходные коммиты больше не ссылается какая-либо ветвь или метка, они могут быть удалены механизмом сборки мусора Git через определенный период времени (то есть нечетная часть коммитов на рисунке). Поэтому, если вам нужно сохранить исходные коммиты, вы должны ссылаться (или сохранять) на эти коммиты rebase, создав git checkout -b name命令новую ветку перед этим, потому что они не будут удалены, пока есть ветки, ссылающиеся на них.

Вернитесь в исходное состояние, если вы отмените команду, а именно: git checkout main git rebase feature, то вы поместите коммит основной ветки за веткой вашей функции:

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

1. Сначала в локальном репозитории mainизвлеките новую ветку (например, feature) из главной ветки ( ), а затем разработайте на этой новой ветке.

2. Когда ваша работа по разработке будет завершена, вы можете вернуться к основной ветке, а затем использовать git merge featureкоманду для объединения вашей работы с основной веткой. Эта операция создает новую фиксацию слияния.

3. Затем вы можете отправить ветку master в удаленный репозиторий, а затем создать запрос на включение (pull request) в удаленном репозитории. Этот запрос на вытягивание показывает ваши изменения и просит других участников проекта просмотреть ваш код и объединить ваши изменения в основную ветку проекта.

Теперь вернемся к rebase и поговорим о других сложных операциях.

git перебазировать --интерактивный

git rebase --interactive — это команда, которая позволяет пользователям в интерактивном режиме выполнять более сложные операции над историей коммитов, включая сжатие ( squeshing ), разделение ( spliting ), удаление ( deleting ) коммитов и т. д.

Начнем с простого примера: при выполнении git rebase -i main( featureна ветке) Git откроет текстовый редактор со списком всех mainкоммитов, которые будут перемещены (т.е. применены к ветке), например:

pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

Перед каждым коммитом pickкоммит будет использоваться в этой перебазировке. Вы можете изменить порядок выполнения коммитов, изменив порядок этих строк. Эти коммиты выполняются сверху вниз (в обратном порядке, как показано в журнале), поэтому коммиты сначала 33d5b7aдобавляются в mainветку. Если вы удалите здесь строку, соответствующая фиксация будет удалена. Если вы удалите все строки, операция перебазирования будет прервана. После того, как вы сохраните и закроете файл, Git выполнит операцию перебазирования в соответствии с вашими инструкциями.

Сжатие сжатия

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

pick 33d5b7a Message for commit #1
squash 9480b3d Message for commit #2
squash 5c67e61 Message for commit #3

 

Когда вы выбираете squashфиксацию, Git включает изменения из этой фиксации в предыдущую (то есть указанную выше) фиксацию. В вашем примере изменения 9480b3dиз 5c67e61обоих коммитов будут объединены в 33d5b7aэтот коммит. Это означает, что изменения из всех трех коммитов будут помещены в новый коммит. Затем Git откроет редактор и позволит вам написать новое сообщение коммита для нового объединенного коммита. Это сообщение обычно по умолчанию представляет собой набор всех сжатых сообщений фиксации, но вы можете отредактировать его по мере необходимости. Наконец, когда вы сохраните и закроете редактор, Git завершит операцию перебазирования, и будет только один новый коммит, содержащий все изменения в вашей истории коммитов, а исходные три коммита больше не будут существовать.

расщепление

«Разделить» фиксацию означает разбить фиксацию на отдельные коммиты. Это может быть полезно, если в одном коммите сделано слишком много разных изменений. Разделив эту фиксацию на одну или несколько отдельных коммитов, ваша история версий становится более детализированной, ее легче читать и изменять. Вот пример кода: Предположим, вы хотите разделить вторую фиксацию на две отдельные фиксации, вы можете использовать editкоманду split.

pick 33d5b7a Message for commit #1
edit 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

Git сначала выполнит ваш первый коммит (33d5b7a), затем применит второй коммит (9480b3d), когда обнаружит, что вы использовали редактирование для второго коммита, git поместит вас в консоль. Оттуда вы можете использовать git reset HEAD~смешанный сброс этой фиксации, который по существу отменяет эту фиксацию и оставляет измененные файлы неустановленными. Теперь вы можете создавать и фиксировать файлы отдельно в несколько коммитов. например:

$ git add file_for_first_commit
$ git commit -m ‘first commit message’
$ git add file_for_second_commit
$ git commit -m ‘second commit message’
$ git rebase --continue

Когда вы закончите обработку команды редактирования, git обработает последний коммит (5c67e61).

удалить удалить

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

pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
drop 5c67e61 Message for commit #3

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

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

Некоторые другие команды git rebase --interactive:

• p, выберите <commit> = используйте коммит
• r, reword <commit> = использовать коммит, но отредактировать сообщение коммита
• e, edit <commit> = использовать фиксацию, но остановить для внесения поправок
• s, squash <commit> = использовать коммит, но объединиться с предыдущим коммитом
• f, fixup <commit> = как "сквош", но отбросить сообщение журнала этой фиксации
• x, exec <command> = запустить команду (остальная часть строки) с помощью оболочки
• b, break = остановиться здесь (продолжить перебазирование позже с помощью «git rebase--continue»)
• d, drop <commit> = удалить коммит
• l, label <label> = пометить текущую HEAD именем
• t, reset <метка> = сбросить HEAD на метку
• m, слияние [-C <commit> | -c <commit>] <label> [# <oneline>] = Создать фиксацию слияния, используя исходное сообщение коммита слияния (или строку, если исходная фиксация слияния не была указана). Используйте -c <commit>, чтобы перефразировать сообщение фиксации.

Git совершить --изменить

Наконец, добавьте исправление, ключевое слово исправление также очень полезно, возможно, если вы хотите обновить свое последнее представление, вы можете использовать команду git commit --amend -m “message for updated commit”. Эта команда добавит ваши изменения в последнюю фиксацию и обновит сообщение фиксации.