Git - jak wymusić konflikt scalania i ręczne scalanie na wybranym pliku

Utrzymujemy aplikację internetową, która ma wspólną gałąź główną i wiele gałęzi równoległych, po jednej dla każdej instalacji, każda ma kilka specyficznych zmian. Kod źródłowy jest zarządzany w git i jest świetnym narzędziem, gdy potrzebujemy przenoszenia funkcji i poprawek błędów z gałęzi głównej do równoległej. Ale jest kilka plików, które są wrażliwe, a automatyczne scalanie zwykle daje złe wyniki. Tak więc scalanie byłoby znacznie łatwiejsze, gdyby można je było w jakiś sposób oznaczyć, a każde scalenie powodowałoby konflikt wymagający ręcznego scalenia.

Szukałem odpowiedzi:

1. Używam opcji scalania --no-commit i --no-ff , ale to nie to samo.
2. Tu i tu ktoś zadaje to samo pytanie, ale bez rozwiązania.
3. Wydaje się, że podobny przypadek dotyczy tego, jak zapobiec scalaniu pliku za pomocą .gitattributes zawierającego: somefile.php merge = ours . Próbowałem znaleźć opcję scalania, która generowałaby konflikt lub wymuszała ręczne scalanie, ale jak dotąd nie znalazłem.
4. .gitattributes zawierające: somefile.php -merge nigdy nie jest scalane automatycznie i dlatego wymusza ręczne scalanie. Jest to rozwiązanie w 90%, ale szukam sposobu na automatyczne scalenie i oznaczenie go jako konfliktu, niezależnie od tego, czy się powiedzie, czy nie. Ale to jest jak dotąd najbliższe rozwiązania. (... dzięki Charlesowi Baileyowi za wyjaśnienie ...)
5. Ktoś sugeruje napisanie niestandardowego sterownika scalania ( 1 , 2 ), ale jak to zrobić, nie jest dla mnie jasne.

edycja: wariant 4. opis

Opcja 5, niestandardowy sterownik scalania, jest prawdopodobnie sposobem na zbliżenie się do tego, co chcesz. Jest to zaskakująco łatwe. Poniżej znajduje się przykład takiego, który moim zdaniem powinien zbliżyć Cię do pożądanego zachowania.

Najpierw utwórz skrypt sterownika scalającego o nazwie merge-and-verify-driver. Spraw, aby był wykonywalny i umieść go w odpowiedniej lokalizacji (możesz rozważyć sprawdzenie tego skryptu w repozytorium, nawet jeśli plik konfiguracyjny repozytorium będzie od niego zależał). Git wykona ten skrypt powłoki, aby połączyć wrażliwe pliki:

#!/bin/bash
git merge-file "${1}" "${2}" "${3}"
exit 1

To po prostu robi domyślne zachowanie scalania, które normalnie robi sam Git. Kluczowa różnica polega na tym, że skrypt zawsze zwraca wartość różną od zera (aby wskazać, że wystąpił konflikt, nawet jeśli scalanie zostało faktycznie rozwiązane bez konfliktów).

Następnie musisz powiedzieć Gitowi o istnieniu Twojego niestandardowego sterownika scalającego. Robisz to w pliku konfiguracyjnym repozytorium ( .git/config):

[merge "verify"]
        name = merge and verify driver
        driver = ./merge-and-verify-driver %A %O %B

W tym przykładzie umieściłem merge-and-verify-driverw katalogu najwyższego poziomu repozytorium ( ./). Będziesz musiał odpowiednio określić ścieżkę do skryptu.

Teraz wystarczy nadać poufnym plikom odpowiednie atrybuty, aby podczas łączenia tych plików był używany niestandardowy sterownik scalania. Dodaj to do swojego .gitattributespliku:

*.sensitive merge=verify

Tutaj powiedziałem Gitowi, że każdy plik o nazwie pasującej do wzorca *.sensitivepowinien używać niestandardowego sterownika scalania. Oczywiście musisz użyć wzorca odpowiedniego dla twojego pliku (plików).

Wydaje się, że te dwa polecenia mają taki sam efekt, jak użycie niestandardowego sterownika scalania:

git merge --no-commit your_target_branch
git checkout --conflict merge .   (do not forget the . and run it in the top dir of the repository)

Pierwsze polecenie zatrzymuje scalanie przed utworzeniem zatwierdzenia scalającego, a drugie oznacza wszystkie pliki zmodyfikowane w dwóch gałęziach jako konflikt do rozwiązania, nawet jeśli pierwotnie nie było konfliktu.

Uwaga: ten artykuł „ Pisanie sterownika git merge dla plików PO ” ilustruje rodzaj manipulacji, które można wykonać podczas ręcznego scalania pliku: można go wstępnie przetworzyć, aby ręczne scalanie było gotowe.

git merge-filemożna na przykład wykorzystać do ODSZYFROWANIA (i ponownego zaszyfrowania) plików przed scaleniem (!)

W twoim przypadku wychodzenie ze sterownika scalającego ze statusem innym niż 0 zapewnia, że ​​scalenie będzie ręczne.