Repozytorium Git w Azure Repos używa chronionej gałęzi master, a prace nad funkcjami są rozwijane w gałęziach tematycznych. Aby skonsolidować historię commitów i zapewnić, że zmiany zostaną scalone jako pojedynczy commit, która strategia scalania żądań ściągnięcia powinna być wymuszona w zasadach gałęzi?

Prawidłowa odpowiedź to squash merge. Ta strategia scalania konsoliduje wszystkie commity z gałęzi tematycznej w jeden commit przed scaleniem go z gałęzią docelową (np. master). Zachowuje to czystą i liniową historię gałęzi master, co jest kluczowe, gdy gałąź master jest chroniona i wymaga uporządkowanej historii. Fast-forward merge jest możliwy tylko wtedy, gdy gałąź master nie ma żadnych nowych commitów od momentu rozgałęzienia gałęzi tematycznej. Nie konsoliduje commitów i nie jest odpowiedni dla chronionych gałęzi. Git fetch pobiera zmiany, ale ich nie scala. No-fast-forward merge (często domyślny merge) tworzy commit scalający, ale zachowuje całą historię commitów z gałęzi tematycznej, co może zaśmiecać historię gałęzi master.