Jak zapobiec scaleniu git w konkretny plik z pnia w gałąź i odwrotnie?

Question

Używam git podczas rozwijania kodu VHDL. Robię programowanie na komponencie w gałęzi git: comp_dev. Interfejs komponentu się nie zmienia, tylko kod wewnątrz komponentu. Komponent ten istnieje już w gałęzi głównej, ale w wersji bardziej stabilnej, wystarczającej dla innych programistów do korzystania z komponentu. Pozostali programiści mają również gałęzie do swojej pracy, a gdy ich kod jest dobry, łączą swoje oddziały z powrotem do opanowania.

Na tym etapie muszę być w stanie scalić wszystkie zmiany z wzorca z powrotem do mojej gałęzi comp_dev, która zasadniczo nie stanowi problemu, ale czasami stabilna wersja komponentu, nad którym pracuję, zmienia się jako część innych projektanci działają, ale nie interfejs. Muszę wykonać ręczne git merge -s nasz na tym konkretnym pliku za każdym razem, gdy chcę się połączyć, w przeciwnym razie dostaję konflikt, który muszę rozwiązać ręcznie, wyrzucając ich pracę.

To samo stanie się, jeśli chcę scalić zmiany w innych plikach z powrotem do wzorca. Jeśli zapomnę wykonać git merge -s nasz src/rx/state_machine.vhd comp_dev zanim wykonam scalenie git, to zakończę albo ręcznym scaleniem, albo przypadkowo scalę niestabilną wersję automatu stanów na górze stabilny.

Czy istnieje sposób tymczasowego wykluczenia jednego pliku z scaleń?

Answer 1

Jeśli dobrze rozumiem, chcesz odroczyć konieczność scalenia zmian z tym komponentem (nazwijmy go "C"), podczas gdy praca koncentruje się na innym module. Efektem ubocznym twojej pracy są drobne zmiany w "C", które zdarzają się w konflikcie z cudzymi dziełami, ale nie chcesz kłopotów z scalaniem "C" za każdym razem, gdy popychasz swoją pracę fokusową do miejsca, gdzie znajduje się twój "mistrz" jest.

AFAIK, zestaw zmian w git jest atomowy i nie wie o plikach; więc nie ma możliwości wyłączenia pliku z scalania, co nie rozwiązuje konfliktu scalania na rzecz preferowanej wersji.

Może być jednak inne wyjście z twojej sytuacji.

Prawdopodobnie chcesz, aby czynnik "C" znalazł się w oddzielnej bibliotece i osobne repozytorium git dla niego. Twój projekt zostanie podzielony na wiele repozytoriów. Ale nie bój się, git pozwoli ci to zarządzać poprzez submoduły. Aby uzyskać szczegółowe informacje, należy wykonać

.

Submodules pozwala na sprawdzenie danej wersji "C" i skupienie się na pracy nad inną częścią źródła. Następnie możesz edytować, zatwierdzać i scalać swoją pracę niezależnie od zmian, które ktoś wprowadził w "C".

W odniesieniu do zarządzania równoczesnymi zmianami, zwykle stanowisko z kontrolą wersji open-source jest takie, że VC nie jest substytutem komunikacji z członkami zespołu. Zaakceptuj ogólne podejście do rozwoju, zminimalizuj jednoczesne niekompatybilne zmiany, a proces rozwoju stanie się mniej dokuczliwy.

Answer 2

Rozmawiałem o tym trochę z kilkoma przyjaciółmi i pomyślałem, że podzielę się tym, jeśli okaże się to przydatne.

Rozbijanie i scalanie może nie być zbyt przydatne dla tego, co próbujesz zrobić. Bezpieczniejsze, łatwiejsze, nudniejsze i bardziej przewidywalne podejście do pobierania tylko niektórych fragmentów kodu lub pewnych plików byłoby przy użyciu metod dostarczanych przez git dla ręcznego przenoszenia łat, takich jak (a) indywidualne wybieranie wiśni lub (b) łatanie formatu i rano. Jeśli potrzebujesz poprawić wynik (np. Usuwając plik), zrób to i wyjaśnij dlaczego w nowym zatwierdzeniu. Lub po prostu zmieniaj rzeczy podczas wybierania czereśni lub nakładania łat.am może być --interactive, a pick-pick może być modyfikowany za pomocą commit -amend.

Próbowałem innego halsu z długoletnim odgałęzieniem: scal wszystko, a następnie ręcznie przywróć rzeczy, które naprawdę nie chciałem scalić. To też zadziałało dobrze.

Coś jeszcze, co wydaje się świetnym pomysłem, to using fine-grained branches.

Sądzę, że mam wrażenie, że jedną z kluczowych wiadomości typu "take-home" jest to, że zwracanie uwagi na kod i dobre testy automatyczne, które są często uruchamiane, są ważniejsze niż opanowanie konkretnej strategii Git-Patch/scalania.

Answer 3

napisałem rozwiązanie, które działa na mnie here

Answer 4

zacząłem używać git merge --no-commit --no-ff other_branch jak wspomniano w:

https://gist.github.com/katylava/564416

chociaż nie robię go w tymczasowym oddziału, po prostu w mojej działającej gałęzi funkcji.

Wymaga to trochę więcej pracy przy wyborze zachowań, które chcesz zachować, i odrzuceniu reszty, ale przynajmniej wiesz na pewno, co trzymasz i co wyrzucasz.