27 podstawowych wskazówek dla użytkowników Git i GitHub

Chociaż użytkownicy Git mają do wyboru dziesiątki przewodników wprowadzających, a GitHub oferuje szereg własnych przewodników, nadal nie jest łatwo znaleźć zbiór przydatnych wskazówek dla programistów, którzy chcą pracować mądrzej z Git i GitHub. Naprawmy to.

Dla tych z Was, którzy nie znają Git lub GitHub, kilka następnych akapitów zapewni wystarczające podstawy do zrozumienia wskazówek. Na końcu tego artykułu wymienimy kilkanaście przydatnych zasobów.

Git to rozproszony system kontroli wersji, pierwotnie napisany przez Linusa Torvaldsa w 2005 roku dla iz pomocą społeczności jądra Linuksa. Nie jestem tutaj, aby sprzedawać ci w Git, więc oszczędzę ci gadania o tym, jak szybki, mały, elastyczny i popularny jest, ale powinieneś wiedzieć, że kiedy klonujesz repozytorium Git (w skrócie „repo”) , otrzymujesz całą historię wersji na swoim komputerze, a nie tylko migawkę z jednej gałęzi naraz.

Git zaczynał jako narzędzie wiersza poleceń, jak przystało na jego pochodzenie w społeczności jądra Linuksa. Jeśli chcesz, nadal możesz używać wiersza poleceń Git, ale nie musisz. W szczególności, jeśli używasz GitHub jako swojego hosta, możesz użyć bezpłatnego klienta GitHub Desktop na Windows lub Mac. Z drugiej strony wiersz poleceń Git będzie działał na każdym hoście i jest fabrycznie zainstalowany w większości systemów Mac i Linux.

Tylko Ty możesz zdecydować, czy najwygodniej Ci będzie używać wiersza poleceń, czy natywnego klienta z graficznym interfejsem użytkownika. Jeśli podoba Ci się GUI, oprócz klienta GitHub (Windows i Mac), możesz rozważyć SourceTree (Windows i Mac, bezpłatny), TortoiseGit (tylko Windows, bezpłatny) i Gitbox (tylko Mac, 14,99 USD). Możesz też użyć edytora lub IDE, które wewnętrznie obsługuje Git (patrz wskazówka nr 11).

Wskazówka Git / GitHub nr 1: Klonuj prawie wszystko

Istnieje wiele interesujących projektów dostępnych z GitHub i innych publicznych repozytoriów Git, które możesz swobodnie sklonować na własny komputer. Dlaczego chcesz to zrobić? Jednym z powodów jest poznanie stylu kodowania, praktyki i narzędzi w języku, który Cię interesuje, w tym stylu komentowania dziennika zmian (patrz wskazówka nr 4). Drugim powodem jest poznanie, w jaki sposób dany projekt realizuje swoje cele. Trzecim powodem, jeśli licencja zezwala na to i ma sens dla twoich celów, byłoby włączenie projektu do własnego przedsięwzięcia lub produktu. Nawiasem mówiąc, dokładnie sprawdź licencję, aby później nie napotkać problemów ze zgodnością.

Definicja git cloneze strony podręcznika:

Klonuje repozytorium do nowo utworzonego katalogu, tworzy gałęzie zdalnego śledzenia dla każdej gałęzi w sklonowanym repozytorium (widoczne przy użyciu git branch -r) oraz tworzy i sprawdza początkową gałąź, która jest rozwidlona z aktualnie aktywnej gałęzi sklonowanego repozytorium.

Po sklonowaniu zwykły git fetchbez argumentów zaktualizuje wszystkie gałęzie zdalnego śledzenia, a git pullbez argumentów dodatkowo połączy zdalną gałąź główną z bieżącą gałęzią główną, jeśli taka istnieje.

Porada Git / GitHub nr 2: Często ciągnij

Jednym z najłatwiejszych sposobów na zrobienie sobie bałaganu z Gitem (a właściwie z każdym systemem kontroli wersji) jest zezwolenie na brak synchronizacji plików. Jeśli będziesz git pullczęsto, będziesz aktualizować swoją kopię repozytorium i będziesz mieć możliwość scalenia zmienionego kodu ze zmianami innych osób, podczas gdy scalanie jest łatwe do zrozumienia i wykonania - najlepiej, gdy jest to tak łatwe, że może odbywać się automatycznie. Następstwem tej wskazówki jest obserwowanie statusu projektu. Wielu klientów Git automatycznie pokazuje, kiedy należy przeprowadzić aktualizację, aby być na bieżąco.

Wskazówka Git / GitHub nr 3: Zatwierdź wcześnie i często

Zatwierdzenie to szczegółowa aktualizacja projektu, która obejmuje jedną lub więcej zmian w co najmniej jednym pliku. Potraktuj to jako zapis wykonanej jednostki pracy, którą można zastosować lub usunąć z projektu jako logiczną całość. Zatwierdź każdą wprowadzoną zmianę logiczną, nawet przed jej przetestowaniem. Zatwierdzenia dotyczą tylko lokalnego repozytorium. Zobacz wskazówki nr 4 i 5, aby zapoznać się z następstwami tej wskazówki.

Definicja git commitze strony podręcznika:

Przechowuje bieżącą zawartość indeksu w nowym zatwierdzeniu wraz z komunikatem dziennika od użytkownika opisującym zmiany.

Wskazówka Git / GitHub nr 4: Komentuj swoje zatwierdzenia tak, jakby inni komentowali ich

Jest 10 rodzajów programistów: ci, którzy komentują swoje zobowiązania i ci, którzy tego nie robią. (Stary żart. Wskazówka: jakiej podstawy używam?)

Przyznaję, że jestem zwolennikiem dobrych komunikatów dziennika zmian. Skonfigurowałem swoje repozytoria tak, aby wymagały komunikatów dla każdego zatwierdzenia i byłem znany z wysyłania irytujących wiadomości późną nocą, gdy zatwierdzenia trafiają z dziennikami rzędu „xx”. Jeśli jesteś typem programisty, który uważa, że ​​(1) kod powinien mówić sam za siebie, a (2) komentarze w wierszu są o wiele ważniejsze niż dzienniki zmian, spróbuj sklonować repozytorium, którego nigdy wcześniej nie widziałeś i zidentyfikować ostatnie zatwierdzenie, które mogło spowodować ostatni opublikowany problem bez czytania całego kodu. Jak widać, dokładne dzienniki zatwierdzeń są podwójnie dobre.

Porada Git / GitHub nr 5: Wciśnij, gdy zmiany są testowane

Najgorszy błąd związany z Gitem, o jakim kiedykolwiek miałem nieszczęście wiedzieć, wydarzył się, gdy firma outsourcingowa przeszła z Subversion, ale nie przeszkoliła programistów w zakresie różnicy między rozproszoną kontrolą źródła a scentralizowaną kontrolą źródła. Około miesiąc później w ramach projektu pojawiły się dziwne błędy, których nikt nie mógł wyśledzić. Na codziennych spotkaniach stand-up deweloperzy odpowiedzialni za obszar aplikacji, który działał nieprawidłowo, protestowali: „Naprawiłem to dwa tygodnie temu!” lub oskarżyć innego programistę o to, że nie zadał sobie trudu, aby pobrać zmiany, które tak dokładnie sprawdzili.

W końcu ktoś zidentyfikował problem i nauczył wszystkich deweloperów, jak i kiedy pushzatwierdzać zmiany: Krótko mówiąc, ilekroć zatwierdzenia zakończą się pomyślnie w lokalnej kompilacji. Następnie firma przeprowadziła dwudniową fuzję, zanim była w stanie zbudować i wdrożyć zaktualizowany, zintegrowany produkt.

Porada Git / GitHub nr 6: Rozgałęziaj się swobodnie

Jedną z największych zalet Git w porównaniu z innymi systemami kontroli wersji jest to, że scalanie zwykle działa dobrze, przynajmniej częściowo dlatego, że Git automatycznie wybiera najlepszego wspólnego przodka do użycia do scalenia. Większość programistów musi częściej rozpoczynać tworzenie oddziałów w swoich projektach. Powinien być codziennym rutynowym wydarzeniem, a nie przedmiotem udręczonego spotkania strategicznego obejmującego wszystkie ręce. Jest prawdopodobne, że gdy projekt branżowy zostanie ukończony, zaakceptowany i gotowy do przejścia do projektu głównego, połączenie nie będzie stwarzać żadnych problemów nie do przezwyciężenia.

Wiem, że wymaga to pewnych poprawek, zwłaszcza jeśli utknąłeś w firmie, która kontroluje kod źródłowy za pomocą CVS. Ale spróbuj. Jest to o wiele lepsze niż przypadkowe wyświetlenie przez klientów niedokończonego kodu eksperymentalnego, gdy projekt trunk musi zostać opublikowany z powodu zepsutego błędu. (W tym artykule dobrze wyjaśniono podstawowe rozgałęzianie i scalanie).

Porada Git / GitHub nr 7: Scal ostrożnie

Chociaż połączenia z Git zwykle działają dobrze, jeśli robisz je bez zastanowienia, czasami możesz napotkać trudności. Pierwszym krokiem jest upewnienie się, że nie masz niezatwierdzonych zmian. Ze strony git mergepodręcznika:

Przed zastosowaniem zmian zewnętrznych, powinieneś zadbać o to, aby Twoja praca była w dobrej kondycji i była zaangażowana lokalnie, aby nie została ona zablokowana w przypadku konfliktów. Zobacz także git-stash.

Zobacz także wskazówkę nr 8.

Nawet jeśli wszystko pójdzie na południe w czasie git merge, nie jesteś podłączony:

Jeśli próbowałeś scalić, które spowodowało złożone konflikty i chcesz zacząć od nowa, możesz odzyskać za pomocą git merge —abort.

Następujące polecenie git mergeto zwykle git mergetool, zakładając, że lubisz używać GUI do scalania. Jeśli wolisz metodę starej szkoły, można edytować pliki w konflikcie ze swoim ulubionym edytorze programowania całkowicie usunąć <<<<<<<, =======i >>>>>>>wiersze, zapisać zmienionych plików, a git addkażdy plik stałe.

Porada Git / GitHub nr 8: Skryj przed przełączeniem gałęzi

Przepływ pracy programisty rzadko jest liniowy. Użytkownicy mają czelność zgłaszać błędy, menedżerowie mają odwagę nadawać priorytet zgłoszeniom innym niż ten, nad którym zdecydowałeś się pracować, a Ty sam możesz zmienić zdanie na temat tego, co chcesz zrobić.

Proszę, z trzema plikami zatwierdzonymi do wydania, a czwartym plikiem w zmienionym, ale niedziałającym stanie. ( git statusPolecenie powie ci to wszystko, jeśli nie pamiętasz, gdzie byłeś). Nagle musisz popracować nad naprawą błędu w wersji produkcyjnej. Musisz szybko zmienić gałęzie, ale nie możesz. Twój katalog roboczy jest brudny i masz dwie godziny pracy, których nie chcesz stracić.

Wejdź git stash. Voilà! Teraz wszystkie zmiany są zapisane w gałęzi WIP (praca w toku) i możesz przełączyć się do gałęzi produkcyjnej z czystego katalogu. Kiedy skończysz, wróć do miejsca, w którym byłeś git stash apply.

Wskazówka Git / GitHub nr 9: Użyj streszczeń, aby udostępniać fragmenty i pasty

„Gists” GitHub - udostępnione fragmenty kodu - nie są funkcją Git, ale używają Git. Wszystkie gists są repozytoriami Git, a GitHub Gist ułatwia ich udostępnianie. Możesz przeszukiwać Gist w poszukiwaniu publicznych streszczeń według tematu, języka programowania, statusu rozwidlenia i statusu oznaczonego gwiazdką. Możesz także tworzyć tajne streszczenia i udostępniać je za pomocą adresu URL.

Porada Git / GitHub nr 10: Eksploruj GitHub

Wiele interesujących projektów open source ma repozytoria na GitHub. Przeglądaj GitHub zapewnia interfejs przeglądania, aby znaleźć niektóre z nich, ale przede wszystkim łatwiej jest wpisać kilka liter nazwy projektu w polu wyszukiwania, aby znaleźć jego repozytoria. Na przykład wpisz jqlub backlub, angaby znaleźć trzy główne frameworki JavaScript typu open source.

Wskazówka Git / GitHub nr 11: Wspieraj projekty open source

Jeśli przeglądasz projekty typu open source, dlaczego nie współtworzyć ich? To nie jest tak trudne, jak mogłoby się wydawać, i wiele się nauczysz. Na przykład można sklonować projekt jquery / jquery (jQuery Core) i przeglądać plik README.MD. U góry zobaczysz:

W duchu rozwoju oprogramowania open source, jQuery zawsze zachęca do tworzenia kodu społeczności. Aby pomóc Ci zacząć i zanim zaczniesz pisać kod, przeczytaj dokładnie te ważne wskazówki dotyczące wkładu ...

Następnie znajdują się trzy linki. Pierwsza z trzech pozwoli ci dość szybko zacząć. Nie każdy projekt open source tak jasno przedstawia plan, ale wszyscy próbują.

Zrozum różnicę między byciem współautorem a popularyzatorem. Współautor podpisał wymagane umowy i wniósł wkład do projektu. Podmiot zatwierdzający jest upoważniony do faktycznego przekazania zaproponowanego wkładu do repozytorium projektu. Ponieważ inicjator testuje Twój wkład, wystąpi opóźnienie i nie będziesz chciał wiązać swojej głównej gałęzi, powinieneś wprowadzić zmiany w innym oddziale (patrz wskazówka nr 6) przed wysłaniem żądania ściągnięcia (patrz wskazówka nr 16).