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?
git
github
solo-development
VirtuosiMedia
źródło
źródło
Odpowiedzi:
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
źródło
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:
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.
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.
źródło
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.
źródło
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 ):
źródło