Git Tagging & Gitflow: Что происходит, когда вы объединяете старые коммиты

Question

Я очень смущаюсь по поводу тегов и должен что-то прояснить. Для управления версиями мне нравится использовать рабочий процесс «gitflow». Я обычно отключаю ветки функций от того, что, после завершения, я снова объединился в разработку, а затем во время цикла выпуска ветвь релиза будет отключена от разработки и, в конечном итоге, найти свой путь в мастер. После объединения с мастером я отмечаю верхний фиксатор номером версии.

Представьте себе следующий сценарий:

Мастер ветвь сидит с тегом «v1.0», который имеет всю последнюю коду от разработки. Другой член команды подталкивает филиал, над которым он работал в течение нескольких недель. Некоторые из этих ветвей фиксируют дату создания метки с указанием даты. В конце концов релиз-ветвь создается с помощью этих старых коммитов и находит свой путь в мастер через слияние. Если я посмотрю на историю git, я могу увидеть, что старые фиксации еще вернулись в журнале основных ветвей.

Если я теперь отмечаю верхний фиксатор (фиксация слияния) как «v1.1», где это оставляет мой проект? Если я проверю тег «v1.0», теперь он будет включать старые коммиты, поскольку они еще вернулись в историю? Моя причина для пометки - я могу прыгать туда и обратно между версиями, если это необходимо, но если старые коммиты собираются бросить гаечный ключ в работу, я не уверен, что делать!

Answer 1

Я сам задал этот вопрос сегодня, поэтому я прочитал некоторые документы и совершил некоторые проверки.

Посмотрите на мой тестовый репозиторий https://github.com/pixelbrackets/hello-github-world/

Я сделал девять фиксаций в »VERSION.TXT«, добавив порядковые номера в файл:

1. Два коммиты в мастера
2. Tagged release версии 0.1.0 (с двумя коммитами)
3. Переключен на ветвь с функциями
4. Создал две коммиты в ветви функции
5. Switched обратно освоить
6. Создано два коммиты в мастер
7. меткой версия релиз 0.2.0 (с ныне четыре фиксаций, не включая функцию еще)
8. Switched обратно в эту ветку
9. создал два больше фиксаций в художественном отделении
10. Merged мастера в этой ветку и разрешили конфликт слияния
11. Объединять ветвь функции, чтобы мастер
12. метки релиза версия 0.3.0 (с девятью фиксаций - четыре от мастера, четыре из художественного отделения, один слияние совершивших)
13. Удалена этой ветке

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

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

Для просмотра истории git в топологическом порядке вы можете использовать графический инструмент типа «gitg« или введите «git log --topo-order -graph» в командной строке.

Вот скриншот моего теста коммиты, сделанные с »gitg«:

Как вы можете видеть в правой колонке, все коммиты в последовательном порядке. Но, несмотря на то, что я удалил ветвь признаков, график все еще четко показывает, что фиксации 3,4,7,8 (шаг 4 & 9) были сделаны отдельно. Имена тегов отображаются рядом с соответствующими коммитами.

Когда я проверяю второй тег, то обязательства четвертого этапа не включаются.

$ git checkout 0.1.0 
HEAD is now at d76c450... Commit 2 Master 2 
$ cat version.txt 
1 
2 
$ git checkout 0.2.0 
HEAD is now at 3eeec86... Commit 6 Master 4 
$ cat version.txt 
1 
2 
5 
6 
$ git checkout 0.3.0 
HEAD is now at 699c6f1... Fix Merge Conflict 
$ cat version.txt 
1 
2 
3 
4 
5 
6 
7 

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