Cóż, szczerze mówiąc, prawidłowy przepływ pracy wymaga dobrej komunikacji i zarządzania. Członkowie zespołu nie powinni Często pracować nad tym samym i powodować konflikty. Rzeczy takie jak codzienne standy i uważny menedżer, który wie, co robi każdy członek zespołu - przynajmniej w ogóle - w wielu przypadkach pójdą długą drogę, aby to ograniczyć.

Zależy to oczywiście od dokładnej natury produktu, ale jest to bardziej kwestia organizacyjna niż kwestia Gita. W faktem jest, że konflikty są często postrzegane jako "dobre" rzeczy, ponieważ sprawiają, że ludzie wstają z biurka lub dzwonią do siebie, aby porozmawiać o tym, dlaczego doszło do konfliktu i co należy z nim zrobić w przyszłości. Jest to szansa, aby dowiedzieć się, że jedna osoba powinna posiadać jeden obszar, lub zestaw plików, lub przynajmniej być punktem kontaktowym do omawiania zmian w tej sekcji.

Poza tworzeniem planu z góry, nie ma sposobu, aby uniknąć konfliktów w git, ale byłby to ten sam problem w dowolny system wersjonowania. Za każdym razem, gdy dwie osoby zmienią ten sam fragment kodu, musisz dowiedzieć się, kto wygra. Z tego powodu nie jest właściwe szukanie rozwiązania w wersjonerze, ale spojrzenie na metody i praktyki Twojego zespołu. Dwa samochody nie mogą przejechać przez skrzyżowanie w tym samym czasie, ale bardzo trudno jest wymyślić samochody, które mogą przejeżdżać przez siebie, więc zamiast tego wymyśliliśmy systemy sterowania znakami stop i sygnałami drogowymi. Jest to podobny problem. Naprawdę nie możemy wprowadzić dwie zmiany w tej samej rzeczy nie konflikt, więc musimy kontrolować, jak pracujemy z plikami.

Ty mógłbyś rozważyć jeden z front-endów, który pozwala na blokowanie w git, ale nie bardzo Zgadzam się z tym pojęciem, poza nie-scalającymi się typami plików. Myślę, że lepiej jest wymyślić lepszy obieg pracy zespołowej, a tymczasem wykorzystaj to jako okazję do naprawdę dobrego łączenia plików. Zrobiłem to, a teraz po miesiącach robienia tego, konflikty nie są dla mnie przykre.

Jest tylko jeden sposób na uniknięcie konfliktów: nie ma potrzeby, aby różni ludzie edytowali ten sam plik w tym samym czasie. Zasadniczo każdy plik ma właściciela, który jest odpowiedzialny za wszystkie zmiany i który może przekazać własność innemu. Własność pliku może być przekazywana w oparciu o konkretną funkcję/gałąź lub codziennie, o ile własność jest jasna.

Jeśli okaże się, że nie można dać jednego właściciela każdemu plikowi to:

• musisz podzielić pliki na mniejsze pliki, które mogą być przypisane do jednego właściciela
• absolutnie wymagają, aby konflikty w GIT zostały rozwiązane (wszyscy redaktorzy siedzą razem, aby rozwiązać poszczególne konflikty).
• użyj dobrego narzędzia multi-merge do wizualizacji, a następnie rozwiązania konfliktów.

Zamawianie.

Jest kilka innych rzeczy, które możesz zrobić, które również mogą pomóc. Będzie jaśniej, jeśli opublikuję je osobno.

Gdzie wstawiasz nowe rzeczy pomoże określić, czy tworzysz konflikty.

Wyobraź sobie listę nazwisk pracowników

Andy, 
Oliver, 
Ivan,

Merge branch 'Patrick' into Brad

Conflicts:
    names.txt

@@@ -1,4 -1,4 +1,8 @@@
  Andy, 
  Oliver, 
  Ivan,
  <<<<<<< HEAD
 +Brad,
  =======
+ Patrick,
  >>>>>>> Patrick

Teraz Załóżmy, że zrobiliśmy to samo, ale wprowadziliśmy prostą alfabetyczną regułę porządkowania na naszej liście. Teraz, gdy doszliśmy do połączenia dwóch gałęzi, wyniki są nieco bardziej przyjemne : - {]}

Andy,
Ivan,
Oliver,

Dodaj jedną nazwę samodzielnie, a następnie połącz zmianę drugiej osoby z Gitem, aby dodać drugą nazwę.

Auto-merging names.txt
Merge made by the 'recursive' strategy.
 names.txt | 1 +
 1 file changed, 1 insertion(+)

I otrzymujemy

Andy,
Brad,
Ivan,
Oliver,
Patrick,

Ponieważ nie wiemy, kto dołączy do firmy, skutecznie dodajemy do listy losowo, a wstawiając w losowych miejscach, konflikty lokalizacji w plikach są mniej prawdopodobne.

Użyj dołączonych bloków

W takim oprogramowaniu ...

function chess() 
{
    while (!end_of_game)
    {
        make_move()

Linie rozpoczynające bloki z otwartymi szelkami łatwo można pomylić z innymi liniami w oprogramowaniu składającymi się z pojedynczych szelek otwierających. Jeśli to samo oprogramowanie jest napisane w ten sposób, dołączanie bloku rozpoczyna się w poprzednich wierszach ...

function chess() {
    while (!end_of_game) {
        make_move()

co mi się osobiście nie podoba, ale Git tak, jest dużo mniej linii, które wyglądają podobnie do Git i mylą się ze sobą, tzn. Git jest bardziej prawdopodobne, że postrzega edycję w ten sam sposób, co my, ułatwiając rozwiązywanie wszelkich konfliktów.

I komentarze do zakończeń bloków

Użyj komentarzy, aby odróżnić podobne linie.

Jeśli piszesz dużo javascript i JSON, możesz mieć wiele linii, które wyglądają trochę tak.

            }
        }
    }
)

Jeśli skomentujesz rzeczy, mogą one stać się rozróżnialne.

            }
        }
    }
) // end of weekdays()

I

            }
        }
    }
) // end of weekend()

Nie wygląda już tak samo dla Gita. To może pomóc git, aby lepiej zrozumieć twoje zmiany. Jeśli coś dodasz, np.

function a()
{
    ...
} // end of a()

Git jest bardziej prawdopodobne, że postrzega to jako jednostkę zmian i nie myśli, że dodałeś coś w rodzaju

}

function a()
{
    ...

Tuż przed końcem jakiejś innej funkcji. Nawet jeśli nie zapobiega to konfliktom, jeśli git widzi i prezentuje twoje zmiany rozsądnie (tj. sposób, w jaki je postrzegamy mentalnie), możesz być może łatwiej rozwiązać konflikty. Nagłówek opisowy komentujący to, co robią funkcje, parametry, które take, etc, dodatkowo pomoże zapobiec zagmatwaniu zawartości sąsiednich funkcji razem.

Aby zmniejszyć liczbę konfliktów w kontroli wersji bez martwienia się o to, kto co edytuje, wystarczy wprowadzić mniejsze zmiany i zatwierdzić / popchnąć je stopniowo. Podziel problem na wystarczająco małe kawałki, aby można Szybko zmodyfikować pliki i przesunąć je z powrotem do bagażnika. Im krótsze są Twoje gałęzie, tym mniejsza szansa na konflikty scalające.

Nawet wtedy, w pewnym momencie dwie osoby będą edytować ten sam plik w tym samym czasie bez winy własne. Oczywistym pytaniem, Kiedy to się stanie jest:

"Jak mogę pozbyć się bólu związanego z rozwiązywaniem konfliktów Gita?"

Odpowiedź jest taka, że powinieneś często ciągnąć trunk i rebaseować na nim swoją gałąź, a konflikty zauważysz jak najwcześniej, gdy są jeszcze małe. W tym momencie obaj deweloperzy powinni usiąść razem i spokojnie omówić najlepszy sposób postępowania, podczas gdy zmiany są świeże w ich umysłach.

Kontrastuje to podejście z próbą rozwiązuj konflikty na ogromnych, długowiecznych gałęziach w panice tuż przed terminem premiery, kiedy deweloperzy zmagają się z myślą o wszystkich zmianach, które wprowadzili jakiś czas temu.

Użyj UTF-8 nie UTF-16 dla plików tekstowych.

Wiele wersji Git (tj. każda wersja, z której korzystałem, o ile wiem) może traktować pliki UTF-16 jako pliki binarne ze względu na obecność wielu zerowych bajtów w typowym pliku tekstowym UTF-16.

Gdy Git uzna, że plik jest plikiem binarnym, prawdopodobnie będzie nadal traktował plik jako plik binarny, nawet jeśli zostanie zmieniony. Oznacza to, że kontrola wersji odbywa się przez przechowywanie pełnych wersji pliku, a nie różnic między nimi a niektóre z zalet systemu kontroli wersji są utracone. (Edit: Nie Testowałem to ostatnio zmieniając plik UTF - 16 na UTF-8, edytując go i zatwierdzając ponownie - i zaczęło traktować zmiany jako zmiany tekstu, gdy zarówno oryginalne, jak i edytowane pliki były UTF-8.)

Większość współczesnych edytorów rozpoznaje kodowanie znaków i styl zakończenia linii pliku i zapisuje plik w tym samym formacie. Niektóre edytory (np. Babelpad) pozwolą Ci wybrać, czy zapisz plik w UTF-8 lub UTF-16, z lub bez znaku kolejności bajtów itp.

Jeśli plik, który chcesz kontrolować, jest (i) w formacie UTF-16 I (ii) będzie działał równie dobrze w UTF-8-na przykład program źródłowy dla porządnego współczesnego kompilatora-warto rozważyć konwersję go do UTF-8.

Jeśli Git uważa, że Twój tekst źródłowy jest plikiem binarnym przed jego pierwszym zatwierdzeniem, spójrz na niego i zobacz, czy warto załadować go do edytora i zapisać w innym formacie, który Git rozpoznaje jako tekst.

(Uwaga. Pliki linuksowe mają domyślnie UTF-8. Niektóre programy Windows miały zwyczaj tworzenia UTF-16. Więc to użytkownicy systemu Windows są najbardziej narażeni na problem. Zauważ również, że chcesz to poprawić przed pierwszym zatwierdzeniem pliku, zanim Git uzna, że posiada plik binarny!)

Użyj Git rerere

Użyj ponownie nagranej rozdzielczości!

Https://git-scm.com/book/en/v2/Git-Tools-Rerere

Poinformuj kolegów, kiedy przesuniesz zmiany

Innym sposobem na zmniejszenie bólu związanego z konfliktami jest po prostu poinformowanie kolegów, kiedy przesunąłeś zmiany. To pozwala im wyciągnąć swoje zmiany i rozwiązać niektóre konflikty tam i wtedy. Wszelkie konflikty mogą być między twoją ostatnią zmianą, świeżą w twoim umyśle, a tym, nad czym pracują, świeżą w swoich umysłach.

Jeśli ludzie nie wyciągną zmian z głównej gałęzi, dopóki nie zakończą dużego rozwoju a potem mieć konflikty ze zmianami wprowadzonymi przez wiele osób, wszystkie w tym samym obszarze, wtedy będzie trudniej rozwiązać.

Użyj mergetool

Jednym z celów Gita jest kontrola wersji. Inne programy specjalizują się w łączeniu plików i rozwiązywaniu konfliktów. Jeśli skonfigurujesz mergetool do użycia z git, to może on automatycznie rozwiązać wiele problemów, które git uważa za konflikt, lub przynajmniej zrobić bardzo dobry domysł, aby sprawdzić i po prostu zostawić nietknięty, jeśli wygląda dobrze, albo ufasz narzędziu.

To pozostawia mniej prawdziwych konfliktów, które wymagają inteligentnej decyzji do rozwiązania.

Użyj mniejszych plików

Dodaję nowy kontroler na dole mycontrollerów.js i dodajesz nowy kontroler na dole yourcontrollers.js: żaden problem.

Obaj dodajemy nowy kontroler na dole allcontrollers.js: konflikt.

(pamiętaj jednak o radach dotyczących porządkowanie rzeczy Alfabetycznie też. myNewController () zaczynające się od M może znajdować się w środku pliku, a yourNewController() zaczynające się od Y może znajdować się na końcu tego samego pliku, ponownie bez konfliktu.)