jak git się sprawdza do dfm i pas?

w Delphi do zarządzania wersjami w firmie stosowaliśmy jedi vcs, nie gita. Narzędzie które nie merge'owało kilku plików tylko pozwalało zarezerwować dany plik (dfm i pas razem) i to spoko działało, jak nikt nie napchał za dużo do jednego pliku.
Czy ktoś ma doświadczenie z gitem w tym środowisku? Jak merge'owane są zmiany, które dotykają dfm i pas jednocześnie?.

Trzeba pojąć, że git pozwala na commity, czyli zmiany które mogą zawierać wiele plików - czyli nikt nie zabroni np. commitować parami - PAS + DFM. Ma to swoje zalety i wady. Wadą jest np. że jeśli masz zmiany w wielu plikach w ramach featura czy bugfixa, to żeby przenieść taką zmianę do gałęzi develop czy wersyjnej/master (zależy jaki flow), to musisz:

1 Mergować całą gałąź - czyli ze wszystkimi zmianami na tej gałęzi
2 Robic cherry-picki - czyli "dobierać" do danej gałęzi konkretne commity po sha1, no ale jak masz np. 10 par pas+dfm to musisz zrobic 10 cherry-picków - co jest upierdliwe. Można zrobic jeszcze inaczej - jesli chcemy w pakiecie n commitów gdzieś "dobrać" i zakładając, że były robione w serii bez innych zmian z innych feature - wtedy można zrobić brancha i na nowym branchu zrobić squasha - to spowoduje zbicie commitów do jednego i wtedy mozna cały pakie zmian masowo cherry-pickować do innej gałęzi.
3 Przygotować patcha - jest to operacja bardzo podobna do commita, ale przygotowuje zmiany w plikach czyli same diffy. Takie coś możesz nałożyć na swoją gałąź, ale musisz te zmiany osobno dodać i zacommitować - wtedy commit może być zmodyfikowany i mieć inny sha1 - co ma swoje implikacje i czasem jest spoko a czasem nie - np. cieżej się rewertuje zmiany podłączone do konikretnego commita na wielu gałęziach.
4 Jeśli mamy kilka commitów nie po kolei to można zawsze zrobić rebase i potem squasha - co pozwoli uzyskać 1 commit ze wszystkimi zmianami który można łatwo cherry-pickować.

Ogólnie jest jeszcze kilka innych możliwości - git jest bardzo elastyczny i wszystko zależy od scenariusza.

Dlaczego można chcieć przenosić tylko część zmian? No bo np. chcemy przenieść tylko 1 bugfix na brnach 3-4 wersja wcześniejsze i nie chcemy dodawać nowych feature, a naprawialiśmy dany bug na wersji develop gdzie są juz nowe feature. Wtedy trzeba izolować zmiany.

Ogólnie zazwyczaj doprowadzaliśmy, żeby zmiany w ramach 1 zadania były w 1 commicie - właśnie przez robienie squashy i rebase - feature branch mógł wyglądać niechlujnie - jakieś pojedyncze commity z komentarzem "WIP" itd. ale na developa trafiał merge z 1 commitem, ładnie opisanym.

Pliki pas i dfm dobrze się mergują, ale to nie ma znaczenia czy to git czy nie - git tego nie robi tylko odpala mergetoola/difftoola. Pliki PAS i DFM fajnie się łączyło w k3diff, WinMerge czy AraxisMerge. Pierwsze dwa sa darmowe.

Oczywiście nie ma złotego środka na konflikty jak wiele osób robi modyfikacje - ale tutaj to pomaga tylo BHP - każdy powinien pracowac na osobnym feature branchu, robić merge developa -> feature branch, robić rebase żeby zmiany tematowe były "na górze", potem squash a na końcu PR lub merge. To ułatwia potem mergowanie zmian. Nie powinien też mergować do developa przed zakończeniem zmian i testami developerskimi.

Wiele lat pracowałem tak w zespole z kilkunastoma programistami.