Prawidłowa procedura (najlepsza praktyka?), Aby zachować synchronizację ze zdalnym repozytorium Mercurial?

Question

Jako poprzedni użytkownik Subversion, zdecydowaliśmy się przejść na Mercurial dla SCM i trochę nas to myli. Chociaż Mercurial jest rozproszonym narzędziem SCM, używamy zdalnego repo, aby zachować zmiany, które tworzymy z kopii zapasowej na serwerze, ale znajdujemy kilka problemów ząbkujących.

Na przykład, gdy dwóch lub trzech z nas pracuje na naszych repo lokalnych, zobowiązujemy się następnie do zdalnego repo, okazuje się, że wiele głowic (?) Są tworzone. To myliło nas z piekłem i musieliśmy dokonać scalenia itp., Żeby to rozwiązać.

Jaki jest najlepszy sposób na uniknięcie tylu głowic i utrzymanie zdalnego repo w synchronizacji z wieloma programistami?

Obecnie pracuję tak:

1. zmienić plik.
2. Wyciągnij z zdalnego repo.
3. Zaktualizuj lokalną kopię roboczą.
4. Scalać? (dlaczego?)
5. Zatwierdź zmiany w lokalnym repozytorium.
6. Przekaż do zdalnego repozytorium.

Czy to najlepsze postępowanie?

Mimo że to zadziałało dobrze dzisiaj, nie mogę oprzeć się wrażeniu, że robię to źle! Szczerze mówiąc, nie rozumiem, dlaczego połączenie musi być wykonane na etapie ściągania, ponieważ inne osoby pracują nad różnymi plikami?

Czy możesz mi powiedzieć, że jeśli nie masz RTFM, masz jakieś wskazówki dotyczące używania Mercurial? Jakieś dobre zasoby online, aby dowiedzieć się, dlaczego mamy tak wielu głów?

UWAGA: Przeczytałem instrukcję obsługi, ale nie daje ona zbyt wiele szczegółów i nie sądzę, żebym chciał rozpocząć kolejną książkę z minuty na minutę.

Answer 1

Powinieneś zdecydowanie znaleźć zasoby edukacyjne.

mogę polecić następujące:

• hginit.com
• Tekpub: Mercurial

Co do konkretnej kwestii, "jest to najlepsza procedura", to musiałbym powiedzieć, że nie.

Oto kilka wskazówek.

Przede wszystkim nie musisz być "zsynchronizowany" z centralnym repozytorium przez cały czas. Zamiast tego postępuj zgodnie z poniższymi wytycznymi:

• Przekaż z lokalnego repozytorium do centralnego, gdy jesteś zadowolony ze zmian, które popełniłeś. Pamiętaj, że może to być kilka zestawów zmian
• Wyciągnij, jeśli potrzebujesz zmian od razu wykonanych przez innych, np. istnieje poprawka, którą naprawił twój kolega, abyś mógł kontynuować swoją pracę.
• Pull przed naciśnięciem
• Merge żadnych dodatkowych głowic ty przesunięte w dół z własnymi zmianami, przed pchania lub kontynuować pracę

Innymi słowy, oto typowy dzień.

Wyciągasz najnowsze zmiany, kiedy przychodzisz rano, dzięki czemu masz aktualnego lokalnego klona. Nie zawsze możesz to zrobić, jeśli jesteś w trakcie większych zmian, które nie zostały wczoraj zakończone.

Następnie zaczniesz działać.Wprowadzasz małe zmiany z pojedynczymi zmianami Nie oznacza to, że dzielisz większy błąd na wiele mniejszych zatwierdzeń tylko dlatego, że modyfikujesz wiele plików, ale starasz się unikać naprawiania więcej niż jednego błędu na raz lub implementacji więcej niż jednej funkcji na czas. Staraj się skupić.

Następnie, gdy jesteś zadowolony ze wszystkich zestawów zmian dodanych lokalnie, zdecydujesz się przekazać na serwer. Kiedy spróbujesz to zrobić, otrzymasz komunikat o przerwaniu mówiący, że dodatkowe głowy zostałyby przekazane na serwer, a to nie jest dozwolone, więc naciśnięcie zostało przerwane.

Zamiast ciągnąć. To zawsze można zrobić, ale oczywiście teraz doda dodatkowe głowy w lokalnym klonie, zamiast na serwerze.

Potem łączysz dodatkową głowę, którą dostajesz z serwera, z własną głową, tą, którą stworzyłeś w ciągu dnia, poprzez wprowadzenie nowych zmian do twojego klona. Rozwiązujesz wszelkie konflikty scalania.

Następnie naciskasz, a teraz powinno się powieść. W sytuacji, gdy ktoś zdążył wcisnąć więcej zestawów zmian do centralnego repozytorium, gdy byłeś zajęty łączeniem, otrzymasz kolejną przerwę i musisz spłukać i powtórzyć.

Historia będzie teraz pokazywać wiele równoległych gałęzi rozwoju, ale powinna zawsze pozostać na maksymalnie 1 głowie w centralnym repozytorium. Jeśli, później, zaczniesz używać nazwanych gałęzi, możesz mieć 1 głowę na nazwaną gałąź, ale staraj się tego unikać, dopóki nie zawiesisz tylko domyślnej gałęzi.

Co do tego, dlaczego chcesz się połączyć? Mercurial zawsze pracuje z wersjami będącymi migawkami całego projektu, co oznacza, że ​​dwie gałęzie, nawet jeśli zawierają zmiany w różnych plikach, są uważane za dwie różne wersje całego projektu i musisz powiedzieć Mercurial, że powinien on łączyć im wrócić do jednej wersji.

Answer 2

Po jednej, możesz ciągnąć w dowolnym momencie; Ciągnięcie powoduje jedynie dodanie zmian do repozytorium, ale nie powoduje zmiany lokalnych plików roboczych (chyba że zainstalowałeś aktualizację post-pull).

Scalenie jest konieczne, jeśli ktoś inny dokonał zmian w tym samym oddziale, nad którym obecnie pracujesz. Stworzyło to niejawną gałąź, a scalenie jedynie sprowadza je do siebie. Widać to ładnie z "torów kolejowych" w widoku repozytorium. Zasadniczo, dopóki nie łączą się, pozostajesz na swojej własnej "prywatnej" ścieżce, a kiedy chcesz dodać swoje zmiany (może to być dowolna liczba zestawów zmian), scalasz ją z powrotem do gałęzi docelowej (zazwyczaj "domyślnie"). Jest bezbolesny - nie przypomina łączenia starszych wersji SVN!

Tak więc przepływ pracy nie jest tak sztywny, jak to pokazałeś; to nic więcej jak to:

• Pull jak lubisz
• Wprowadź zmiany i zobowiązać się lokalnie, jak często, jak chcesz
• Kiedy zmiany powinny być włączone, połączenie z branży docelowej (może być niższa wersja niż najnowsza), zatwierdzanie i przesyłanie

Ten przepływ pracy może być nieco zestrojony, na przykład za pomocą nazwanych gałęzi, a czasami za pomocą rebase. Jednak Ty i Twój zespół powinniście zdecydować się na przepływ pracy, który ma być użyty; Mercurial jest dość elastyczny pod tym względem.

Answer 3

http://hginit.com ma dobry samouczek.

W szczególności, znajdziesz listę kroków masz tutaj: http://hginit.com/02.html (na dole strony)

różnica między tymi etapami, a twoje jest, że należy zobowiązać po kroku 1. W rzeczywistości zazwyczaj wykonasz kilka razy w lokalnym repozytorium, zanim przejdziesz do etapu pobierania/scalania/wypychania. Nie musisz od razu udostępniać wszystkich commitów pozostałym deweloperom. Często ma sens robienie kilku powiązanych zmian, a następnie popchnięcie tego całego.