Jestem dokładnie w tej sytuacji, ale zdecydowałem się na nieco bardziej skomplikowany, choć niekoniecznie bardziej skomplikowany przepływ pracy z Git.
Na początku celem było nauczenie się git, więc trochę się zgłębiłem. następnie powróciłem do opisanego przepływu pracy.
Po pewnym czasie stało się to trudne, ponieważ pojawiły się pewne sytuacje, a także dało mi złe nawyki, które trudno byłoby przełamać, kiedy dołączę do zespołu.
więc zdecydowałem się na następujące:
- Lokalne repozytorium do pracy.
- Oddział główny jako stabilny pień dla aplikacji
- Jedna gałąź dla każdej funkcji / refaktora, w zasadzie jedna gałąź dla każdej znacznej zmiany, która zostanie wprowadzona.
- Połącz z powrotem do pnia, gdy gałąź jest stabilna, a wszystkie testy zakończone pomyślnie.
Skonfigurowałem również konto git hub, w którym synchronizuję łącze. To pozwoliło mi łatwo rozpocząć pracę na różnych komputerach. Było to z konieczności, ale pozwoliło mi znaleźć błędy związane ze środowiskiem, w którym byłem, i które nie było dostępne na innych komputerach. Dlatego teraz przyzwyczajam się do wypróbowania projektu na innym systemie „dziewiczym” przynajmniej raz. Oszczędza mi wielu problemów, gdy przychodzi czas na wdrożenie u klienta.
- Oznaczam każdą wersję, która zamienia ją w github, jako wersję do zwolnienia.
- Jeśli zostanie wydany klientowi, uruchomię tę wersję, aby utworzyć drugi stabilny bagażnik dla poprawionych błędów zadeklarowanych przez klienta.
Wiele oddziałów początkowo wydawało się przesadą, ale NAPRAWDĘ bardzo pomogło. Mógłbym założyć pomysł w gałęzi, popracować nad nim przez chwilę, a kiedy zacząłem tworzyć kręgi, poddałem się i założyłem inną gałąź, aby pracować nad czymś innym. Później przyszedł pomysł, że wrócę do na wpół upieczonej gałęzi i zbadam ten pomysł. ogólnie rzecz biorąc, sprawiłem, że O wiele DUŻO byłem bardziej produktywny, ponieważ mogłem bardzo szybko działać z błyskami i pomysłami i sprawdzać, czy zadziałało. Koszt zmiany gałęzi za pomocą GIT jest bardzo niski, co sprawia, że jestem bardzo zwinny dzięki mojej bazie kodu. To powiedziawszy, wciąż muszę opanować koncepcję rebase, aby oczyścić moją historię, ale ponieważ jestem sam, wątpię, czy naprawdę muszę. Uczyniłem to „przyjemnym do nauki”.
Kiedy wszystkie rozgałęzienia stały się skomplikowane, zbadałem opcję dziennika, aby narysować drzewo zmian i zobaczyć, gdzie jest gałąź.
Krótko mówiąc, git nie jest jak SVN, CVS lub (brrr) TFS. Rozgałęzianie jest bardzo tanie, a popełnianie błędów, które wymażą pracę, jest w rzeczywistości dość trudne. Tylko raz straciłem trochę pracy, a to dlatego, że moje zobowiązania były zbyt duże (patrz złe nawyki powyżej). Jeśli często popełniasz błędy, git na pewno będzie twoim najlepszym sprzymierzeńcem.
Git otworzył mi umysł na to, na czym tak naprawdę polega kontrola źródła. Cokolwiek innego wcześniej było tylko próbami zdobycia go, git jest pierwszym, który, moim zdaniem, rozumiem. To powiedziawszy, nie próbowałem innych DVCS, być może to stwierdzenie można by rozszerzyć na całą rodzinę.
Ostatnia rada: wiersz poleceń to twój przyjaciel. Nie mówiąc już o tym, że narzędzia graficzne nie są dobre, wręcz przeciwnie, ale naprawdę zasmuciłem gita, kiedy zszedłem do linii poleceń i wypróbowałem to sam. W rzeczywistości jest bardzo dobrze wykonany, łatwy do naśladowania dzięki bardzo kompleksowemu systemowi pomocy. Moim największym problemem było przywiązanie do brzydkiej konsoli w systemie Windows, dopóki nie znalazłem alternatywy.
Teraz używam zarówno integracji Eclipse z Gitem, aby zobaczyć, co się dzieje w czasie rzeczywistym i wykonywać niektóre operacje, takie jak różnice, przeglądać historię pliku itp. Oraz wiersz poleceń do rozgałęziania, łączenia, wypychania, pobierania i bardziej złożonych drzew dzienników . podstawowe skrypty i nigdy nie byłem tak produktywny w zakresie kontroli źródła i nigdy nie miałem tak dużej kontroli nad moim źródłem.
Powodzenia, mam nadzieję, że to pomogło.