Jak przebiega praca z 2 osobami przy projekcie

Przychodzę do ciebie jako początkujący programista, który pracuje nad własnym projektem (który postępuje dobrze). Mój współzałożyciel również nauczył się programować i doszedł do punktu, w którym prawdopodobnie mógłby zacząć naprawiać niektóre rzeczy i sprawiać, że niektóre rzeczy się dzieją.

Zadał bardzo dobre pytanie: „jak to zadziała”. Coś, o czym mógłbym tylko teoretykować, ponieważ nigdy nie programowałem z kimś innym. Czy mógłbyś mi doradzić w sprawie najlepszego przepływu pracy. Używamy git.

Czy powinniśmy posiadać określone części systemu? Sprawdzasz kod? Przegląd kodu?

Jak pracujesz z> 1 programistą?

Pracuję w zespole używającym git, w którym ponad 40 programistów pracuje nad wieloma repozytoriami kodów (100+) w dowolnym momencie. Zaczęliśmy też od bardzo niewielu programistów, zwiększając rozmiar zespołu w ciągu kilku lat. Na początku jednak z kilkoma osobami możesz uciec od znajomości minimum git. Z czasem poprawisz swoje git fu, odkrywając potężne funkcje.

1. Potrzebujesz miejsca do przechowywania kodu. Zastanów się nad użyciem github lub gitorious . Oba są bezpłatne, ale Twoje repozytoria będą publiczne i widoczne dla innych. Jeśli chcesz prywatne repozytoria , możesz je hostować na github za darmo lub zainstalować i hostować swój wspaniały serwer .
2. Na początku lepiej nie martwić się o zaawansowane przepływy pracy, które obejmują rozwidlenia, żądania ściągania. Możesz zacząć od korzystania z git w sposób scentralizowany (dreszcz!). Traktuj hostowaną kopię jako wiarygodną kopię kodu źródłowego. Nazwijmy to repozytorium upstream.
3. Jeden z was zatwierdza cały kod do lokalnego repozytorium git i przekazuje go do tego upstreamrepozytorium.
4. Drugi członek zespołu może sklonować to repozytorium.
5. Zestaw poleceń minimalnych musisz dowiedzieć się clone, pull, push, add, commit, log, status, diff, branch, stash, apply, reset, format-patch, branch. Dowiedz się więcej o nich z gittutoriala .
6. Każdy z was może teraz pracować nad dowolną częścią kodu. Nie martw się, co się stanie, gdy oboje edytujecie ten sam plik. Git jest naprawdę dobry w obsłudze połączeń i naprawianiu konfliktów.
7. Wykonuj małe atomowe zmiany i pisz dobre wiadomości z dziennika . Użyj czasu teraźniejszego dla dzienników zatwierdzeń. Możesz wykonać dowolną liczbę zatwierdzeń do swojej lokalnej kopii, ponieważ nie wpływa to na pracę drugiej osoby.
8. Jeśli uważasz, że Twój kod jest gotowy do udostępnienia innym, opublikuj go w upstreamrepozytorium. Dobrą praktyką jest ciągnięcie zawsze przed pchnięciem . W ten sposób utrzymujesz swoje repozytorium w synchronizacji z innymi zmianami.
9. Powtórz kroki 7i 8.

Gdy już poczujesz się komfortowo z tym przepływem pracy, możesz przejść do bardziej zaawansowanych rzeczy, takich jak: odgałęzienia tematyczne, rozwidlanie, żądania ściągania, scalanie, interaktywne ponowne zatwierdzanie zatwierdzeń itp.

Jeśli naprawdę potrzebujesz recenzji kodu, możesz to zrobić za pomocą samego git i poczty e-mail. Gdy Twój zespół wzrośnie powyżej 10+, najlepiej jest to zrobić lepiej za pomocą jakiegoś narzędzia online. W praktyce jest na to wiele sposobów, a to tylko jeden prosty sposób:

1. Utwórz zestaw zatwierdzeń do sprawdzenia git format-patch. Wygeneruje to zestaw plików łatek. Prześlij te poprawki e-mailem do recenzenta.
2. Recenzent może zastosować łatki za pomocą git apply. To dotyczy poprawki, ale nie tworzy zatwierdzenia.
3. Przejrzyj kod i odeślij e-maila z sugestiami.
4. Powtarzaj 1-2-3, aż zadowalające.
5. Recenzent potwierdza, że ​​łatki można przesuwać upstream.

Używam do tego github i całej jego funkcjonalności. sprawdź to na stronie http://www.github.com/ Abyś mógł korzystać z oddziałów, rozwidleń, problemów, wyciągać wnioski o współpracę z partnerem.

Pierwszą rzeczą, którą bym zrobił, to zajrzeć do centralnego repozytorium kodu, aby zmiany mogły być scalane i synchronizowane między Twoimi projektami. SVN jest dość łatwy, z którego korzystałem w przeszłości i istnieje wystarczająco długo, aby był dość dojrzałym SVN .

Następnie zidentyfikuję między wami role, które każdy z was będzie odgrywał, tj

1. Czy zamierzasz napisać funkcjonalność kodu w tandomie, czy też jedna osoba będzie naprawiać błędy, podczas gdy druga będzie dalej z funkcjami.
2. Czy chcesz utworzyć zestaw podstawowych standardów kodowania, tj. Pozycję nawiasów klamrowych, nazewnictwo zmiennych członków prywatnych, konwencje nazewnictwa zmiennych i metod (CamelCase itp.)
3. Jak często musisz się zameldować. Sugerowałbym przynajmniej raz dziennie, aby upewnić się, że oboje widzicie, co robi drugi szczególnie wcześnie. Chociaż zawsze upewnij się przed zameldowaniem, kod można zbudować.
4. On jest szefem, ale czy będziesz programistą?

Powodzenia!