Używając Git lub Mercurial, jak byś wiedział, kiedy robisz klon lub ciągnięcie, nikt nie sprawdza plików (przesuwając go)?

Question

Używając Git lub Mercurial, jak byś wiedział, kiedy robisz klon lub ciągnięcie, nikt nie sprawdza plików (przesuwając go)? Może być ważne, aby:

1) Nigdy nie wiesz, że jest niespójny, więc spróbuj przez 2 godziny próbować debugować kod, gdy kod jest niespójny.

2) Przy całym kodzie źródłowym (takim jak Ruby on Rails) - potencjalnie setki plików - jeśli niektóre pliki są niezgodne z innymi, nie mogą spowodować uszkodzenia lub niespójności w kodzie rake db:migrate lub script/generate controller baza?

Answer 1

Pociągnięcia i pchnięcia są atomowe w Git i Mercurial. Oznacza to, że nigdy nie pozwolą ci uzyskać częściowo przesuniętych zestawów zmian. Zawsze otrzymasz cały zestaw zmian.

Aktualizacja: Po prostu pomyślałem, że możesz się bać "Co jeśli ktoś naciska serię zestawów zmian, a ja dostanę niektóre z nich". W takim razie chodzi o komunikację i przepływ pracy, które są akceptowane w projekcie.

Często się zgadza, że ​​każde zatwierdzenie do magistrali (master lub jak to się nazywa) powinno pozostawić kod w spójnym stanie. Jeśli ktoś wie, że wprowadzi zmiany, które spowodują chwilowe niespójności, powinien zrobić to w oddziale i jeśli jest gotowy, połączyć go z pniem. Następnie pień jest przenoszony do stanu oddziału w jednym zatwierdzeniu, aby zawsze był spójny.

Aktualizacja 2: Jak powiedział tonfa - w Mercurial push jest atomowa. Zrobiłem prosty test w git, a popchnięcia są tutaj również atomowe. Więc nie musisz obawiać się takich niespójności, jeśli wiesz, że inni deweloperzy naciskają na zmiany robocze. (chociaż wcześniejsze stwierdzenia dotyczące oddziałów są nadal aktualne).

Answer 2

Kiedy zrobić pull w Hg, jeśli nie ma żadnych zmian, otrzymuję:

pulling from <REPOSITORY NAME> 
searching for changes 
no changes found 

Więc wiem, że nie było żadnych zmian od czasu ostatniego wyciągnąłem. Ponadto zawsze możesz przeglądać historię repozytorium i zobaczyć, jakie zmiany zostały wprowadzone.

Answer 3

Jak powiedzieli inni, commits są atomowe, więc nie będziesz mieć problemu z niespójnością z powodu częściowego zatwierdzenia.

To, co ta odpowiedź dodaje do konwersacji, to możliwość dodania haków poprzedzających zatwierdzenie, które wymuszają czysty przebieg zestawu testów, zanim zatwierdzenie jest dozwolone.

http://git-scm.com/docs/githooks

https://www.mercurial-scm.org/wiki/Hook