Введение
В этом практическом занятии (лабораторной работе) вы научитесь определять, является ли коммит (коммит в Git) слиянием (merge commit). Мы рассмотрим команду git show для изучения деталей коммитов, с особым вниманием к определению родительских коммитов, что является ключевым признаком слияния.
Вы также узнаете, как использовать команду git log --merges для эффективного вывода только коммитов слияния в истории вашего репозитория. Наконец, мы протестируем эти методы на не-слияниях (non-merge commits), чтобы закрепить ваше понимание того, как различать разные типы коммитов в Git.
Используйте git show для проверки родительских коммитов
На этом этапе мы рассмотрим, как использовать команду git show для изучения деталей коммита, с особым вниманием к его родительским коммитам. Понимание родительских коммитов является важным для навигации по истории проекта и понимания того, как различные коммиты связаны друг с другом.
Сначала убедимся, что мы находимся в директории нашего проекта. Откройте терминал и перейдите в директорию my-time-machine:
cd ~/project/my-time-machine
Теперь используем git log для просмотра истории коммитов. Мы будем использовать флаг --oneline для краткого представления:
git log --oneline
Вы должны увидеть вывод, похожий на этот (ваш хэш коммита будет другим):
a1b2c3d (HEAD -> master) Send a message to the future
Это показывает наш первый коммит. Теперь используем git show для просмотра деталей этого коммита. Скопируйте хэш коммита (короткую строку букв и цифр, например a1b2c3d) из вывода команды git log и замените YOUR_COMMIT_HASH в следующей команде:
git show YOUR_COMMIT_HASH
Например, если ваш хэш коммита был a1b2c3d, вы должны выполнить:
git show a1b2c3d
Вывод будет довольно подробным и покажет информацию о коммите, включая автора, дату, сообщение коммита и изменения, внесенные коммитом.
commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9
Author: Jane Doe <jane.doe@example.com>
Date: Mon Aug 7 10:00:00 2023 +0000
Send a message to the future
diff --git a/message.txt b/message.txt
new file mode 100644
index 0000000..a1b2c3d
--- /dev/null
+++ b/message.txt
@@ -0,0 +1 @@
+Hello, Future Me
Для нашего первого коммита, который является началом истории проекта, вы заметите, что в выводе нет строки "Parent". Это потому, что начальный коммит не имеет родителя – он является корнем истории проекта.
На последующих этапах, когда у нас будет больше коммитов, мы снова используем git show, чтобы увидеть, как отображаются родительские коммиты и как они связывают историю. Понимание этой связи является фундаментальным для понимания того, как Git отслеживает изменения во времени.
Запустите git log --merges для проверки
На этом этапе мы узнаем о коммитах слияния (merge commits) и о том, как использовать команду git log --merges для просмотра только таких коммитов в истории нашего проекта. Коммиты слияния - это специальные коммиты, которые объединяют изменения из разных веток (branches).
В настоящее время история нашего проекта очень проста, здесь есть только один начальный коммит. У нас пока нет ни веток, ни операций слияния. Давайте сначала убедимся в этом, запустив команду git log --merges.
Убедитесь, что вы находитесь в директории ~/project/my-time-machine:
cd ~/project/my-time-machine
Теперь запустите команду:
git log --merges
Поскольку мы еще не выполнили ни одного слияния, эта команда, скорее всего, не выдаст никакого вывода:
Это ожидаемый результат! Команда git log --merges предназначена для фильтрации истории коммитов и отображения только тех коммитов, которые были созданы в результате слияния одной ветки в другую.
Чтобы увидеть, как работает эта команда, нам нужно создать новую ветку, сделать несколько коммитов в этой ветке, а затем объединить ее с основной веткой. Мы рассмотрим создание веток и слияние в будущих практических занятиях (лабораторных работах).
Пока что важно понять, что git log --merges - это мощный инструмент для понимания того, когда и как различные линии разработки были объединены в вашем проекте. Это особенно полезно в условиях совместной работы, когда несколько человек одновременно работают над разными функциями.
Тестирование не-мерж коммитов
На этом этапе мы создадим обычный коммит (не-сливающий коммит, non-merge commit) и затем используем git log, чтобы увидеть, как он появляется в истории проекта по сравнению с коммитом слияния (merge commit), которого у нас пока нет, но который появится в будущих лабораторных работах). Это поможет закрепить ваше понимание разных типов коммитов.
Сначала внесем небольшое изменение в файл message.txt. Мы добавим еще одну строку.
Убедитесь, что вы находитесь в директории ~/project/my-time-machine:
cd ~/project/my-time-machine
Теперь используйте команду echo для добавления новой строки в файл:
echo "Adding another line." >> message.txt
Оператор >> добавляет текст в файл, а не перезаписывает его.
Давайте проверим содержимое файла:
cat message.txt
Вы должны увидеть:
Hello, Future Me
Adding another line.
Теперь проверим статус нашего репозитория:
git status
Вы должны увидеть, что файл message.txt был изменен:
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: message.txt
no changes added to commit (use "git add" and/or "git commit -a")
Git распознал изменения, которые мы внесли. Теперь подготовим (stage) и зафиксируем (commit) эти изменения.
git add message.txt
git commit -m "Add a second line to message"
Вы должны увидеть вывод, подтверждающий коммит:
[master a1b2c3d] Add a second line to message
1 file changed, 1 insertion(+)
Теперь посмотрим на историю коммитов снова, используя git log --oneline:
git log --oneline
Вы должны увидеть два коммита:
e4f5g6h (HEAD -> master) Add a second line to message
a1b2c3d Send a message to the future
Последний коммит (e4f5g6h в этом примере, ваш хэш будет другим) - это наш новый не-сливающий коммит. Он представляет собой одно изменение, внесенное непосредственно в ветку master.
Если мы снова запустим git log --merges, он по-прежнему не выдаст никакого вывода, потому что ни один из этих коммитов не является коммитом слияния.
Понимание различий между обычными коммитами и коммитами слияния важно для интерпретации истории проекта и эффективного сотрудничества с другими разработчиками. Обычные коммиты представляют линейное развитие на одной линии разработки, в то время как коммиты слияния представляют интеграцию изменений из разных линий разработки.
Резюме
В этой лабораторной работе мы научились определять коммиты слияния (merge commits) в Git. Мы начали с использования команды git show для изучения деталей коммита, с особым вниманием к наличию или отсутствию родительских коммитов (parent commits). Мы увидели, что у начального коммита нет родителя, в то время как последующие коммиты отображают своих родителей.
Затем мы изучили команду git log --merges, которая является прямым способом перечисления только коммитов слияния в истории репозитория. Наконец, мы проверили эти методы на не-сливающих коммитах, чтобы убедиться, что они правильно идентифицируются как такие, тем самым закрепив наше понимание того, как отличать коммиты слияния от обычных коммитов.
