Git: как вы документируете этапы разработки перед удалением ветки?

Question

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

(Я понимаю, что коммиты остаются в истории после удаления веток. Суть в том, что, пока существует ветвь, ясно, какие коммиты в ней содержатся. Как только ветвь объединена обратно в master и удалена, все вы осталось длинная история * 1004. * Итак, когда вы сталкиваетесь с длинной историей недифференцированных коммитов, как вы документируете свою работу, чтобы определить, какие коммиты были частью определенной ветки - какие коммиты реализовали, какой тикет или функциональность?)

Answer 1

Все коммиты в любую ветку сохраняются в вашем git-репозитории как скрытые ветки, независимо от того, удалили ли вы ветку или нет. Если вы хотите получить доступ к ветви, которую вы слили в master, например, после того, как вы удалили ее, вы можете:

1. Просмотрите журнал git, набрав git log
2. Скопируйте самый последний идентификатор фиксации ветви, которую вы слили с мастером (некоторый длинный хеш)
3. Проверьте ветвь этого коммита, набрав git checkout <commit id>

Надеюсь, это поможет!

Answer 2

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

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

Рассмотрим следующий сценарий:

remote:   A -- B -- C
           \
feature:    D -- E -- F

Выполнение git rebase remote из ветви feature приведет крезультат в следующем:

remote:   A -- B -- C
                     \
feature:              D' -- E' -- F'

Теперь выполнение git push origin feature приведет к полностью линейному обновлению удаленной ветви:

remote:   A -- B -- C -- D' -- E' -- F'

С линейной историей легко читатьчто случилось в ветке.Но использование git rebase сложнее, чем git merge, о чем следует помнить.