Добавить метаданные для фиксации, которые сохраняются после перебазирования / слияния

Question

Допустим, у меня есть следующий рабочий процесс:

git checkout -b feature
# do some work
git add new_file
git commit -m "finished feature"
git checkout master
# integrate the feature changes into master
git rebase feature

Когда изменения из функциональной ветки интегрированы в мастер посредством rebase / merge / rebase & squa sh, новая фиксация ha sh создается на мастере. Есть ли способ сопоставить хэши фиксации в функциональной ветке с новой фиксацией ha sh в основной ветке и наоборот?

Контекст: у меня есть программа, которая прикрепляет метаданные к фиксации ha sh. Я хочу иметь возможность сохранить эти метаданные для фиксации отношения даже после того, как разработчик объединит / перебазирует ветку в / на master.

Answer 1

Я бы поискал другие способы идентификации коммитов.

Например:

• Когда вы используете трекер проблем, обычный способ «связать» фиксацию с проблемой тикет должен указать fixes #xyz в сообщении фиксации; многие стандартные инструменты используют это для связывания ветвей с проблемами.
• Запросы на извлечение (в github, gitlab, azure DevOps ...) отслеживают имена веток вместо идентификаторов фиксации.

Вы можете использовать либо определенные c токены в сообщениях коммитов (они будут автоматически добавляться при перебазировании, выборе вишни ...), либо использовать теги / ветки с указанными c именами для укажите на интересующие вас коммиты (вам нужно будет обновить целевой тег / ветку как отдельное действие, если коммит «уходит»).

Answer 2

Вот ваш текущий поток:

git checkout -b feature
# do some work
git add new_file
git commit -m "finished feature"
git checkout master
# integrate the feature changes into master
git rebase feature

Вот измененный поток для переноса ваших изменений с feature на master более стандартным способом.

git checkout -b feature
# do some work
git add new_file
git commit -m "finished feature"
git push origin <feature> 
<create pull request - I usually do this on the service itself>
<approve and merge the pull request into master>

При использовании рабочего процесса ветвления идея состоит в том, что ветвь master обычно обновляется только с помощью запроса на вытягивание, а история перебазирования / исправления происходит в случае проблем. Если вы перебазируете и обновляете свой мастер таким образом, вы можете также выполнить go дополнительные шаги, связанные с созданием отдельной ветки, и просто pu sh фиксируется непосредственно на master с тем же результатом.