GitFlow, вопросы сквоша и слияния - PullRequest
Новая
       132

GitFlow, вопросы сквоша и слияния

0 голосов
/ 04 мая 2020

Я использую GitFlow в моем git хранилище, поэтому у меня есть ветка master, develop и (временная) release.

Рабочий процесс

  1. Я создаю новую ветку из develop (например, fix/fix-the-bug)
  2. Я сква sh мое исправление в значимые коммиты
  3. Я объединяю свою ветку fix/fix-the-bug в develop
  4. Как только у меня будет достаточно слитых веток, я создаю (временную) ветку release/x.y.z из develop
  5. I version-bump мои скрипты в ветке release/x.y.z и тег, которые фиксируют
  6. Когда я хочу слить release/x.y.z в master, я получаю конфликты слияния. Похоже, master не понимает, что коммиты уже присутствуют в master
  7. release/x.y.z ветвь объединяется в develop
  8. Я удаляю release/x.y.z

Мало что следует заметить, не уверен, что все они верны:

  • Я сква sh мои коммиты в один коммит при слиянии с мастером
  • Должен быть git тег на master, указывающий номер версии, но не уверен, что он будет работать правильно, если я буду sh коммитов.

Вопрос

Мне теперь интересно:

  • как я могу исправить свое репо, так как я не думаю, что я должен получить эти конфликты.
  • Любые дальнейшие советы по рабочему процессу ( например, в какой части я мог бы исполнить сква sh лучший) будет приветствоваться.

1 Ответ

1 голос
/ 04 мая 2020

Я сква sh мои коммиты в один коммит при слиянии с мастером

Похоже, вы используете git merge --squash при слиянии с master. Это не стандартная практика gitflow; вы бы просто сделали нормальное слияние.

Вся разница между обычным слиянием и слиянием squa sh заключается в том, что слияние squa sh не записывает отношения между новым коммитом на ветви, которую вы ' повторное слияние с (т. е. master в данном случае) и исходные коммиты в исходной ветке; поэтому последующие слияния не понимают, что содержимое master уже соответствует предыдущему состоянию develop.

Недостатком использования регулярного слияния является то, что git по умолчанию выводит например, при регистрации master будут включены все отдельные коммиты, а не просто список коммитов релиза на master; но вы можете это исправить, используя опцию --first-parent.

Чтобы поместить это в визуальные эффекты, вы начинаете с пустого репо 

o <--(master)

Не создавая коммитов, вы запускаете develop ветвь, а затем ветвь fix, над которой вы выполняете некоторую работу 

o <--(master)(develop)
 \
  A <--(fix)

Вы объединяетесь с dev 

o <--(master)
|
|- M <--(develop)
\ /
 A <--(fix)

Возможно, вы сделаете больше исправлений 

o <--(master)
|
|- M - M2 <--(develop)
| / \ /
| |  B <--(fix2)
\ |
 A <--(fix)

Теперь, если вы сква sh слиться с мастером, вы получите что-то вроде 

o -------- AB <--(master)
|
|- M - M2 <--(develop)
| / \ /
| |  B <--(fix2)
\ |
 A <--(fix)

и AB содержит все изменения, которые A и B внесли, но до git касается, это случайно; и как только develop содержит дополнительные изменения, даже тот факт, что изменения "одинаковы", будет потерян, и конфликты (как вы уже видели) приводят к.

Таким образом, вместо этого вы делаете обычное слияние - просто пропустите опцию --squash, предполагая, что вы в первую очередь использовали squa sh merges: 

o ------- AB <--(master)
|        /
|- M - M2 <--(develop)
| / \ /
| |  B <--(fix2)
\ |
 A <--(fix)

Вот как git означает, что слияния работают; теперь будущие попытки слияния будут «знать», что M2 (и все, что с этим связано) уже включено в master, и только изменения после M2 будут включены как «их изменения» в расчет слияния.

Это также то, как gitflow намеревается что-то сделать.

...