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.

odpowiadając na pytanie @LukeJL chodzi o to ze jeżeli np zmienimy name komponentu w dfm to w pas też musi być zmieniona nazwa pola w klasie

ja bym powiedział że git jest najlepszy do kodu niezależnie od języka wiec czy to Pascal czy coś innego to w sumie bez znaczenia, musisz tylko trochę poznać narzędzie i ustalić jakieś standardy:
np. w git możesz dodać zmianę w pliku na poziomie linii a nie na poziomie pliku wiec zanim coś wysyłasz robisz przegląd zmian kodu i dodajesz tylko co istotne a nie wszystko jak leci.
To rozwiązuje np. problem że otworzysz formę w IDE a Ci się masa właściwości przestawia bo masz trochę inny monitor , jak wszyscy będą wysyłać takie zmiany to rzeczywiście przy merge będzie problem.

i kolejna sprawa to najlepiej jak najmniej w DFM , tyle problemów znika jak sie stosuje tą zasadę

Git po prostu trzyma snapshoty projektu takie jakie są. Jedyne problemy jakie mogą z tego wynikać to wydajność, bo git wszystko traktuje jako tekst co np. jest słabe gdy w repo trzymasz duże pliki jak obrazki czy binarki

odpowiadając na pytanie @LukeJL chodzi o to ze jeżeli np zmienimy name komponentu w dfm to w pas też musi być zmieniona nazwa pola w klasie

To nie brzmi jak zadanie dla gita. Normalnie to zakłada się, że w każdym commicie jest działający kod i autor to sprawdził. Takie zachowanie możesz wymusić poprzez:

• konwencję. Jak coś jest mergowane to przez githuba a tam jest CI
• coś w stylu https://pre-commit.com/ , gdzie ta praca jest wykonywana lokalnie

git ma LFS "Large File Storage" i to jest dedykowane właśnie do binarnych i dużych plików.

też uważam że git nie ma związku z synchronizacją PAS i DFM to bardziej kwestia jak projekt jest prowadzony, trzeba otworzyć umysł na nowe narzędzia zapomnieć rozwiązania z początku wieku bo już ćwierć wieku "pykło", no chyba że chcemy dotrwać do emerytury na VCS