Как проверить, является ли ветка Git сиротской

Введение

В этом практическом занятии (лабораторной работе) вы узнаете, как проверить, является ли ветка Git "сиротской" (orphaned). Мы рассмотрим команду git log, чтобы понять, как выглядят коммиты без родительских коммитов, что характерно для первого коммита в репозитории.

Кроме того, вы будете использовать команду git branch --no-merged для определения веток, изменения которых не были интегрированы в текущую ветку. Наконец, вы протестируете эти концепции, создав и изучив новую "сиротскую" ветку.

Skills Graph

Проверка git log на отсутствие родительских коммитов

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

Сначала убедитесь, что вы находитесь в директории my-time-machine:

cd ~/project/my-time-machine

Теперь давайте используем команду git log с опцией --pretty=oneline. Эта опция отображает каждый коммит в одной строке, что полезно для краткого просмотра истории. Мы также добавим опцию --max-count=1, чтобы показать только самый свежий коммит.

git log --pretty=oneline --max-count=1

Вы должны увидеть вывод, похожий на следующий:

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9 (HEAD -> master) Send a message to the future

В этом выводе показаны хэш коммита (длинная строка символов), ветка, на которой он находится (HEAD -> master), и сообщение коммита.

Теперь давайте попробуем посмотреть родителя этого коммита. Поскольку это самый первый коммит, у него нет родителя. Мы можем использовать опцию --no-walk=parent с командой git log, чтобы попытаться показать родительский коммит.

git log --no-walk=parent --pretty=oneline --max-count=1

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

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

Использование git branch --no-merged

На этом этапе мы узнаем о команде git branch и, в частности, об опции --no-merged. Эта опция помогает нам определить ветки, содержащие изменения, которые еще не были включены в текущую ветку.

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

Убедитесь, что вы находитесь в директории ~/project/my-time-machine.

cd ~/project/my-time-machine

Теперь создайте новую ветку с именем experiment:

git branch experiment

Эта команда создает новую ветку, но не переключает вас на нее. Вы по-прежнему на ветке master.

Выведем список всех веток в нашем репозитории с помощью команды git branch:

git branch

Вы должны увидеть вывод, похожий на следующий:

  experiment
* master

Звездочка (*) указывает на ветку, на которой вы в данный момент находитесь, то есть master.

Теперь используем команду git branch --no-merged. Эта команда выводит список веток, которые не были объединены с текущей веткой (master).

git branch --no-merged

Вы должны увидеть:

  experiment

Этот вывод говорит нам, что ветка experiment содержит изменения, которых нет в ветке master. В данном случае, так как мы только что создали ветку experiment из master и еще не внесли никаких изменений в ней, это может показаться нелогичным. Однако опция --no-merged предназначена для отображения веток, чей конечный коммит недоступен из конца текущей ветки. Поскольку experiment в настоящее время указывает на тот же коммит, что и master, но master не "объединил" experiment (что в данном контексте не имеет смысла), все равно выводится experiment.

В реальной ситуации вы обычно создаете новую ветку, делаете несколько коммитов в ней, а затем используете git branch --no-merged из основной ветки (например, master), чтобы увидеть, какие ветки с новыми функциями готовы к объединению.

Тестирование с новой "сиротской" веткой

На этом этапе мы создадим новую "сиротскую" (orphan) ветку. Сиротская ветка - это ветка, которая начинается без истории предыдущих веток. Это как начало совершенно новой истории в вашей машине времени. Это полезно, например, для веток с документацией или веток gh-pages для веб - сайтов, где вы не хотите включать историю основного кода.

Убедитесь, что вы находитесь в директории ~/project/my-time-machine.

cd ~/project/my-time-machine

Теперь создадим новую сиротскую ветку с именем new-start:

git checkout --orphan new-start

Вы должны увидеть вывод, похожий на следующий:

Switched to a new branch 'new-start'

Теперь мы переключились на ветку new-start. Обратите внимание, что файлы из ветки master по-прежнему присутствуют в вашей рабочей директории. Это потому, что команда git checkout --orphan подготавливает рабочую директорию и индекс для нового корневого коммита, но не удаляет существующие файлы.

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

git status

Вы должны увидеть что-то вроде этого:

On branch new-start

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        message.txt

nothing added to commit but untracked files present (use "git add" to track)

Git воспринимает message.txt как неотслеживаемый файл, потому что история ветки new-start полностью отделена от ветки master.

Чтобы действительно начать с чистого листа на этой сиротской ветке, обычно мы удаляем старые файлы и затем добавляем новый контент для этой ветки. Удалим файл message.txt:

rm message.txt

Теперь проверим статус еще раз:

git status

Вы должны увидеть:

On branch new-start

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Теперь рабочая директория чистая, и мы готовы создать первый коммит на нашей новой, независимой истории.

Создадим новый файл, специфичный для этой ветки:

echo "This is a fresh start!" > readme.md

Добавим новый файл в область подготовленных изменений (staging area):

git add readme.md

И, наконец, создадим первый коммит на ветке new-start:

git commit -m "Initial commit for new-start branch"

Вы должны увидеть вывод, похожий на следующий:

[new-start (root-commit) a1b2c3d] Initial commit for new-start branch
 1 file changed, 1 insertion(+)
 create mode 100644 readme.md

Обратите внимание, что этот коммит также является "(root-commit)", как и первый коммит на ветке master. Это подтверждает, что у него нет родителя и он является началом новой истории.

Теперь посмотрим на журнал коммитов для этой ветки:

git log --pretty=oneline

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

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9 (HEAD -> new-start) Initial commit for new-start branch

Это показывает, что ветка new-start имеет свою собственную независимую историю, отделенную от ветки master.

Резюме

В этом практическом занятии (lab) мы научились проверять, является ли ветка Git сиротской (orphaned). Мы начали с изучения команды git log, в частности, с того, как определить отсутствие родительского коммита для начального коммита в репозитории с использованием опции --no-walk=parent. Это продемонстрировало фундаментальный концепт истории Git, согласно которому первый коммит не имеет родителя.

Затем мы познакомились с командой git branch --no-merged. Эта команда используется для вывода списка веток, которые не были объединены с текущей веткой. Это ключевая техника для определения веток, которые могут быть сиротскими или содержать неинтегрированные изменения. В рамках практического занятия также был включен этап проверки этих концепций путем создания и изучения новой сиротской ветки.