Zatímco uživatelé Git mají na výběr desítky průvodců pro začátečníky a GitHub nabízí řadu vlastních průvodců, stále není snadné najít sbírku užitečných tipů pro vývojáře, kteří chtějí s Git a GitHub pracovat chytřeji. Pojďme to opravit.
Pro ty z vás, kteří nejsou obeznámeni s Gitem nebo GitHubem, vám několik následujících odstavců poskytne dostatek pozadí k pochopení tipů. Na konci tohoto článku uvedeme asi tucet užitečných zdrojů.
Git je distribuovaný systém pro správu verzí, původně napsaný Linusem Torvaldsem v roce 2005 pro komunitu jádra Linuxu as pomocí komunity Linuxu. Nejsem tady, abych vás prodal na Gitu, takže vás ušetřím informací o tom, jak rychlé a malé a flexibilní a populární je, ale měli byste vědět, že když naklonujete úložiště Git (zkráceně „repo“) , získáte na svém počítači celou historii verzí, nejen snímek z jedné větve najednou.
Git začínal jako nástroj příkazového řádku, který odpovídá jeho původu v komunitě jádra Linuxu. Pokud chcete, můžete stále použít příkazový řádek Git, ale nemusíte. Zejména pokud používáte GitHub jako svého hostitele, můžete použít bezplatného klienta GitHub Desktop na Windows nebo Mac. Na druhou stranu bude příkazový řádek Git fungovat pro libovolného hostitele a je předinstalován na většině systémů Mac a Linux.
Pouze vy můžete rozhodnout, zda vám nejlépe vyhovuje použití příkazového řádku nebo nativního klienta s grafickým uživatelským rozhraním. Pokud máte rádi grafické uživatelské rozhraní, můžete kromě klienta GitHub (Windows a Mac) zvážit také SourceTree (Windows a Mac, zdarma), TortoiseGit (pouze Windows, zdarma) a Gitbox (pouze Mac, 14,99 $). Nebo můžete použít editor nebo IDE, které interně podporuje Git (viz tip č. 11).
Tip Git / GitHub č. 1: Klonujte téměř cokoli
Z GitHubu a dalších veřejných úložišť Git je k dispozici mnoho zajímavých projektů, které můžete volně klonovat do svého počítače. Proč bys to chtěl dělat? Jedním z důvodů je naučit se něco o stylu kódování, praxi a nástrojích v jazyce, o který se zajímáte, včetně stylu komentáře potvrzení protokolu (viz tip č. 4). Druhým důvodem je zjistit, jak daný projekt dosahuje svých cílů. Třetím důvodem, pokud vám to licencování umožňuje a dává to smysl vašim účelům, by bylo začlenění projektu do vašeho vlastního snažení nebo produktu. Mimochodem dvakrát zkontrolujte licenci, abyste se později nedostali k problémům s dodržováním předpisů.
Definice git klon z manuálové stránky:
Klonuje úložiště do nově vytvořeného adresáře, vytváří větve vzdáleného sledování pro každou větev v klonovaném úložišti (viditelné pomocí git větev -r) a vytvoří a zkontroluje počáteční větev, která je rozvětvena z aktuálně aktivní větve klonovaného úložiště.
Po klonu rovina git načíst bez argumentů aktualizuje všechny větve vzdáleného sledování a a git pull bez argumentů navíc sloučí vzdálenou hlavní větev do aktuální hlavní větve, pokud existuje.
Tip Git / GitHub č. 2: Často táhněte
Jedním z nejjednodušších způsobů, jak si s Gitem (a samozřejmě s jakýmkoli systémem pro správu verzí) udělat nepořádek, je umožnit synchronizaci souborů. jestli ty git pull často budete udržovat svou kopii repo aktuální a budete mít příležitost sloučit svůj změněný kód se změnami ostatních, zatímco sloučení je snadné pochopit a dosáhnout - v ideálním případě, když je to tak snadné, že to lze provést automaticky. Důsledkem tohoto tipu je sledovat stav vašeho projektu. Mnoho klientů Git vám automaticky zobrazí, když potřebujete aktualizovat, abyste zůstali aktuální.
Git / GitHub tip č. 3: Dopouštějte se brzy a často
Commit je podrobná aktualizace projektu, která obsahuje jednu nebo více změn jednoho nebo více souborů. Přemýšlejte o tom jako o záznamu dokončené jednotky práce, kterou lze použít nebo odebrat z projektu jako logický celek. Proveďte každou logickou změnu, kterou dokončíte, ještě před jejím testováním. Závazky se vztahují pouze na místní úložiště. Důsledky tohoto tipu viz tipy č. 4 a 5.
Definice git commit z manuálové stránky:
Uloží aktuální obsah indexu do nového potvrzení spolu se zprávou protokolu od uživatele popisující změny.
Tip č. 4 na Git / GitHub: Komentujte své závazky tak, jak chcete, aby ostatní komentovali jejich
Existuje 10 druhů kodérů: ti, kteří komentují své závazky, a ti, kteří ne. (Starý vtip. Tip: Jakou základnu používám?)
Svobodně přiznávám, že jsem držitelem dobrých zpráv protokolu o potvrzení. Nastavil jsem svá úložiště tak, aby vyžadovala zprávy pro každé potvrzení, a bylo mi známo, že rozesílám otravné pozdní noční zprávy, když spáchá zemi s protokoly v řádu „xx“. Pokud jste ten typ vývojáře, který si myslí, že (1) by měl kód mluvit sám za sebe a (2) řádkové komentáře jsou mnohem důležitější než protokoly změn, zkuste klonovat úložiště, které jste nikdy předtím neviděli, a identifikovat nedávné potvrzení, které mohlo způsobit poslední zveřejněný problém bez přečtení celého kódu. Jak vidíte, přesné protokoly odevzdání jsou dvojnásobné plus dobré.
Tip č. 5 Git / GitHub: Když jsou vaše změny testovány, stiskněte
Nejhorší chyba související s Gitem, o které jsem kdy měl tu smůlu, se stala, když přešla outsourcingová společnost ze Subversion, ale necvičila své vývojáře o rozdílech mezi distribuovaným a centralizovaným zdrojovým řízením. Asi o měsíc později projekt vyvinul podivné chyby, které nikdo nemohl sledovat. Na denních stand-up setkáních vývojáři odpovědní za oblast aplikace, která se chovala, protestovali: „Opravil jsem to před dvěma týdny!“ nebo obvinit jiného vývojáře, že se neobtěžoval stáhnout změny, které tak pečlivě zkontrolovali.
Nakonec někdo problém identifikoval a naučil všechny vývojáře, jak a kdy tam jejich revize: Stručně řečeno, kdykoli se revize úspěšně otestují v místním sestavení. Poté společnost provedla dvoudenní slučovací festival, než mohla sestavit a nasadit aktualizovaný integrovaný produkt.
Tip Git / GitHub č. 6: Pobočka volně
Jednou z největších výhod, které má Git oproti jiným systémům pro správu verzí, je to, že slučování obvykle funguje dobře, alespoň částečně proto, že Git automaticky vybere nejlepšího společného předka, který se použije pro sloučení. Většina vývojářů softwaru musí začít ve svých projektech častěji vytvářet pobočky. Mělo by se jednat o rutinní každodenní událost, nikoli o téma strategického setkání všech rukou. Pravděpodobnost je, že až bude projekt pobočky dokončen, přijat a připraven k přesunu do hlavního projektu, sloučení nebude představovat nepřekonatelné problémy.
Vím, že to vyžaduje určitou úpravu, zvláště pokud jste uvízli ve společnosti, která ovládá zdrojový kód pomocí CVS. Ale zkuste to. Je to mnohem lepší, než když zákazníci omylem uvidí váš nedokončený experimentální kód, když musí být hlavní projekt publikován kvůli zlomené chybě. (Tento článek vysvětluje základní větvení a slučování.)
Tip Git / GitHub č. 7: Sloučte opatrně
Zatímco fúze s Gitem obvykle fungují dobře, pokud je provedete bez přemýšlení, občas se můžete setkat s obtížemi. Prvním krokem je ujistit se, že nemáte žádné nepotvrzené změny. Z git sloučit manuální stránka:
Před provedením vnějších změn byste měli dostat svou vlastní práci do dobré kondice a angažovat se místně, takže v případě konfliktů nebude ovlivněna. Viz také git-stash.
Viz také tip č. 8.
I když to všechno jde na jih během git sloučit, nemáte hosed:
Pokud jste vyzkoušeli sloučení, které vyústilo ve složité konflikty a chcete začít znovu, můžete se zotavit pomocí git merge - abort.
Následný příkaz do git sloučit je obvykle git mergetool, za předpokladu, že chcete ke sloučení použít grafické uživatelské rozhraní. Pokud dáváte přednost metodě staré školy, můžete upravit soubory, které jsou v konfliktu s vaším oblíbeným programovacím editorem, zcela odstranit <<<<<<<, =======, a >>>>>>> řádky, uložte revidované soubory a git přidat každý soubor, který jste opravili.
Tip Git / GitHub č. 8: Ukrytí před přepnutím větví
Pracovní postup vývojáře softwaru je zřídka lineární. Uživatelé mají tu drzost hlásit chyby, manažeři mají tu drzost upřednostňovat jiné tikety, než na kterých jste se rozhodli pracovat, a vy sami si můžete rozmyslet, co chcete dělat.
Tady jste, se třemi soubory potvrzenými pro vydání a čtvrtým souborem ve změněném, ale nepracujícím stavu. (The stav git příkaz vám to všechno řekne, pokud si náhodou nepamatujete, kde jste byli.) Najednou musíte pracovat na opravě chyby v produkční verzi. Musíte změnit větve pronto, ale nemůžete. Váš pracovní adresář je špinavý a máte dvě hodiny práce, o které nechcete přijít.
Enter git skrýš. Voilà! Nyní máte všechny své změny uložené ve větvi WIP (work in progress) a můžete přejít na produkční větev ze svého čistého adresáře. Až to dokončíte, přepněte zpět na místo, kde jste byli git stash platí.
Tip č. 9 na Git / GitHub: Pomocí gistů sdílejte úryvky a pasty
„Gist“ GitHub - sdílené fragmenty kódu - nejsou funkcí Git, ale používají Git. Všechny seznamy jsou úložiště Git a GitHub Gist usnadňuje jejich sdílení. V Gist můžete vyhledávat veřejné seznamy podle témat, programovacího jazyka, vidlicového stavu a stavu označeného hvězdičkou. Můžete také vytvořit tajné seznamy a sdílet je pomocí adresy URL.
Tip Git / GitHub č. 10: Prozkoumejte GitHub
Mnoho zajímavých open source projektů má úložiště na GitHubu. Prozkoumat GitHub poskytuje rozhraní pro procházení, kde najdete některé z nich, ale většinou je snazší zadat do vyhledávacího pole několik písmen názvu projektu, abyste našli jeho repozitáře. Zadejte například jq nebo zadní nebo ang najít tři z hlavních frameworků JavaScript s otevřeným zdrojovým kódem.
Tip č. 11 na Git / GitHub: Přispějte k projektům s otevřeným zdrojovým kódem
Pokud procházíte projekty typu open source, proč do nich nepřispívat? Není to tak těžké, jak si možná myslíte, a hodně se dozvíte. Můžete například naklonovat projekt jquery / jquery (jQuery Core) a procházet soubor README.MD. V horní části uvidíte:
V duchu vývoje softwaru s otevřeným zdrojovým kódem jQuery vždy podporuje příspěvek kódu komunity. Abychom vám pomohli začít, a než se pustíte do psaní kódu, přečtěte si důkladně tyto důležité pokyny pro příspěvky ...
Poté následují tři odkazy. První ze tří vám pomůže začít poměrně rychle. Ne každý projekt s otevřeným zdrojovým kódem stanoví plán tak jasně, ale všichni se o to snaží.
Pochopte, jaký je rozdíl mezi přispěvatelem a přispěvatelem. Přispěvatel podepsal požadované dohody a zpřístupnil příspěvek projektu. Zprostředkovatel je oprávněn skutečně odevzdat nabízený příspěvek do úložiště projektu. Vzhledem k tomu, že účastník otestuje váš příspěvek a nebude se vám chtít svázat hlavní větev, dojde ke zpoždění, měli byste provést změny v jiné větvi (viz tip č. 6) před odesláním žádosti o stažení (viz tip č. 16).
