Jako jedyny programista (na razie), jak powinienem używać Git? [Zamknięte]

60

Mam wiele projektów na Git, do których ostatecznie chcę zachęcić innych. Jednak w tej chwili jestem tylko ja i używam Git i GitHub w bardzo uproszczony sposób: żadnych gałęzi i po prostu używam commits jako kopii zapasowej moich plików lokalnych. Czasami wracam i sprawdzam poprzednie wersje moich plików w celach informacyjnych, ale do tej pory nie musiałem dokonywać żadnych wycofań, choć doceniam opcję, jeśli będę jej potrzebować w przyszłości.

Jako jedyny programista, jakie funkcje Git lub GitHub mogę z tego skorzystać, przyniosłyby mi teraz korzyści? Jaki powinien być mój przepływ pracy?

Czy są też jakieś szczególne praktyki, które muszę zacząć, aby w przyszłości dodać inne do moich projektów?

VirtuosiMedia
źródło
3
Jak wyjaśnili inni, Git daje dużą moc. Jako jedyny programista, dużą rzeczą, którą później docenisz, jest to, że jeśli daje ci zapis dokonanych zmian (grupowanie zmian w kilku plikach w jednym zestawie), kiedy je wprowadziłeś i dlaczego! To także świetna praktyka, gdy stajesz się częścią zespołu.
Wiodący Geek
1
Zamknięte, ponieważ interesujące. :)
@ user93458 jak zawsze! Zamknięte tematy są zwykle dokładnie tym, czego szukam.
Miroslav Popov
doskonałe pytanie, które nigdy nie powinno być zamknięte.
tom pierwszy

Odpowiedzi:

64

Czy są też jakieś szczególne praktyki, które muszę zacząć, aby w przyszłości dodać inne do moich projektów?

Oczywiście. Istnieje prosta dobra praktyka, z której możesz skorzystać, nawet jeśli nie masz obecnie zespołu: utwórz oddzielną gałąź dla rozwoju. Chodzi o to, aby gałąź główna zawierała tylko zwolnione wersje kodu lub główne zmiany. Mogą to łatwo przyjąć nowi programiści dołączający do twojego projektu.

Poza tym rozgałęzianie jest przydatne, nawet jeśli pracujesz solo. Na przykład znajdziesz błąd podczas kodowania nowej funkcji. Jeśli nie korzystasz z gałęzi, musisz wykonać jedno i drugie: dodać nowe funkcje i naprawić błąd w tej samej gałęzi. To nie jest dobre: ​​P Z drugiej strony, jeśli utworzyłeś nową gałąź do tworzenia nowej funkcji, możesz po prostu pobrać gałąź rozwoju, naprawić błąd i wycofać nową gałąź funkcji.

To tylko krótki przykład tego, co możesz zrobić będąc jedynym programistą. Jestem pewien, że musi być więcej dobrych praktyk.

Bardzo polecam ten artykuł: Udany model rozgałęziania Git

Cristian
źródło
+1 - To ma sens. Przyjrzę się również temu artykułowi, wygląda na bardzo przydatny.
VirtuosiMedia,
Nie jestem specjalistą od gitów, głównie użytkownikiem Mercurial. Czy ta rada deweloperów nadal obowiązuje w przypadku Mercurial? Wygląda na to, że tak, ale może niektóre różnice sprawiają, że nie jest to dobry pomysł w tym przypadku?
Klaim
2
Tak, w zasadzie dotyczy całej kontroli źródła. W rzeczywistości robię to wstecz z SVN; „główny” bagażnik jest przeznaczony dla najnowszych osiągnięć, które pojawiają się codziennie lub nawet częściej. Gdy wymagane jest wydanie, kod jest zamrażany i wycinany jest oddział. Ta gałąź otrzymuje tylko drobne aktualizacje, aby naprawić poważne problemy z wydaniem, a następnie tworzona jest dystrybucja. W ten sposób mam gałąź kodu źródłowego za każdą wydaną wersją. Jest to lepsze niż zwykłe oznaczanie lub etykietowanie czarno-białe, jeśli zatwierdzenia pojawiają się po etykiecie, ale przed wydaniem nie wiadomo, czy faktycznie zostały wykluczone.
KeithS
+1 za artykuł; @Klaim - tak, działa również świetnie dla hg. naprawdę powinien być nazwany „udanym modelem rozgałęziającym DCVS”
Wyatt Barnett,
+1 dzięki za link, to zmieniło sposób, w jaki będę pracować z gitem, nie przez ciebie, ale jak mówią, wszystko trochę pomaga!
Newtopian
14

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.

Newtopian
źródło
4

Jestem dobrze zaznajomiony z kilkoma wyrafinowanymi modelami rozgałęziającymi i używam ich w pracy. Jednak kiedy pracuję sam nad projektami, robię prawie dokładnie to, co teraz robisz. Zawsze mogę utworzyć gałąź po fakcie, jeśli jej potrzebuję, ale prawie nigdy tego nie robię. Pracując samotnie, rzadko mam poprawki błędów, które nie mogą czekać, aż moje bieżące zadanie zostanie zakończone. Radzę zapoznać się z niektórymi modelami rozgałęziającymi, ale nie ma sensu komplikować rzeczy, dopóki nie trzeba.

Karl Bielefeldt
źródło
4

Aby uzyskać prostszy model, możesz zobaczyć, co robi GitHub. „Przepływ GitHub” jest bardzo prosty, a tutaj jest doskonały przewodnik: https://guides.github.com/introduction/flow/index.html

Podsumowanie (z bloga Scott Chacon ):

Czym jest GitHub Flow?

  • Wszystko w gałęzi master jest możliwe do wdrożenia
  • Aby pracować nad czymś nowym, utwórz opisowo odgałęzioną gałąź master (tj .: new-oauth2-scopes)
  • Zaangażuj się w tę gałąź lokalnie i regularnie wypychaj swoją pracę do tej samej gałęzi o nazwie na serwerze
  • Jeśli potrzebujesz informacji zwrotnej lub pomocy lub uważasz, że oddział jest gotowy do scalenia, otwórz żądanie ściągnięcia
  • Po sprawdzeniu i wylogowaniu się przez użytkownika z funkcji możesz połączyć ją w master
  • Po scaleniu i przekazaniu do „master”, możesz i powinieneś natychmiast wdrożyć
AdrianoFerrari
źródło