Jak nenaplnit své lokální soubory Git částí 2

Potvrzuje, tlačí a táhne

Tento článek je pokračováním části 1, přestože se tento článek můžete učit a užívat si, aniž byste si přečetli první, doporučujeme vám podívat se zpět na etiketu poboček a pracovního postupu, protože budu používat stejné koncepty jako v prvním.

Rozsah tohoto článku

Závazky jsou chléb a máslo Git a Github, které organizují celý váš kód, měli byste jim usnadnit porozumění ostatním vývojářům, aby mohli vidět, co jste změnili a jak projekt a váš kód postupují.
Část 2 se zaměří na etiketu odevzdání a na to, jak zvládat tahy a tahy.

Nástroje

Stejně jako dříve budeme pro úžasnou integraci Git používat pouze klienta Git a kód Visual Studio.

Základy

Za prvé, na co se používají závazky? Ukládají kód, to je druh práva, ale dělají mnohem víc než to: Odhodlání uspořádat váš kód do malých bitů, které lze snadno pochopit a roztřídit.

Dobří vývojáři využívají odevzdání po jejich zveřejnění, aby pochopili, jak se věci dělají a které soubory byly upraveny. Myslete na svou aplikaci jako na opravdu dobrou knihu.

Kapitoly jsou ekvivalentem závazků (druh, ne doslovně), pokud chcete vědět, kde v knize Alice spadne do králičí díry, zjistíte, že to dělá v kapitole nazvané „Dole králičích děr“, měly by se vaše závazky dodržujte stejná pravidla.

Labyrint složitých a nepopisných závazků, se kterými se nikdo nechce zabývat.

Co by měl dobrý závazek obsahovat

Jedinou nejdůležitější věcí na odhodlání je to, co obsahují. Tak jednoduché, jak se to může zdát, je často těžké pro vývojáře sledovat.

Opravujete nějakou gramatiku na FAQ, když pracujete na vašem reakčním komponentu navbar? Vložte to do vlastního závazku. Předchozí článek vysvětluje, jak uložit jeden soubor do potvrzení s VSCode.

Každé odevzdání má téma, musíte si uvědomit, že odevzdání hodně zvykne. Chcete-li usnadnit práci svým i všem ostatním, musíte je zmenšit pouze pomocí „jedné“ změny. Například změna typu React.PropTypes (reakce <15,5) na prop-typy (reakce ≥15,5) pro 5 různých souborů může být pouze jedním potvrzením, ale pokud chcete změnit akci Redux, která je dalším potvrzením, nemíchejte různé věci .

S touto metodou budete mít mnohem více závazků a všichni budou mít smysl, můžete se pochlubit svým git příspěvkem a zároveň být chválen jako dobrý dev, není to úžasné?

Potvrďte název

$ git commit -m "Oprava citlivosti malých a velkých písmen pro vstup e-mailů"

Kapitalizujte první dopis, který není moc vysvětlit, gramatika 101.

Do 72 znaků a kolem 50 průměrů nechcete, aby vaše zpráva o odevzdání byla rozdělena na dvě části (slavné tři tečky). To je způsob, jak se dobře odevzdávají.

Nedělejte to!

Zachovejte to stručně a jasně to znamená, že váš text odevzdání by měl být stručným vysvětlením toho, co dělá, výše uvedený odevzdaný závazek není jasný ani krátký, obsahuje opravu pro trasu s /: uživatelské jméno je vyhodnoceno před / odhlášení, to znamená, že vždy se považovalo za odhlášení jako uživatelské jméno a pokusilo se načíst profil z databáze nazvaný odhlášení. Jednoduchý problém priority tras. Jaké by bylo lepší jméno pro tento závazek?

$ git commit -m "Opravit prioritu tras"

Krátce a rovně k věci, pokud chcete více informací o tom, co odhodlání dělá, můžete otevřít odhodlání a zkontrolovat změny v kódu, je to dobrý zvyk mít, jak rostete jako vývojář.

Ale chci být ve svém odevzdání konkrétnější než to, jak to mohu udělat za 50 znaků?

Potvrdit tělo

O tom není moc co říci, tělo odevzdání může být tak popisné, jak chcete, ale pamatujte, že by měl popisovat kód, nesmí být jeho náhradou.

Naštěstí existuje snadný a rychlý způsob, jak psát zprávy těla z konzoly, aniž by používal vim, který každý miluje.

$ git commit -m "Moje jméno odevzdání" -m "Moje zpráva odevzdání zprávy"

Potvrďte pomocí VSCode

Toto je většinou převzato z předchozího článku, pokud vás zajímá, jak to funguje detailně, přečtěte si prosím.

Jakmile provedete změny na kartě ovládání zdroje na postranním panelu, jednoduše přidejte název a uložte potvrzení.

Stačí kliknout na V a jste hotovi.

Je užitečné, abyste se při práci na velké míře soustředili na editor, protože můžete svůj kód neustále upravovat, zatímco postupujete.

Jak tlačit své úžasné závazky bez zničení všeho

Tato část používá a vyžaduje, abyste dodržovali etiketu uvedenou v předchozím článku, abyste plně porozuměli jejímu obsahu.

Nyní máme dokonalé odhodlání v našich dokonalých větvích, jak zatlačit tuto úžasnost?

Pojďme si nastavit nějaké návyky.

Poté, co jste dokončili práci na kódu, byste měli vždy aktualizovat svou větev ze základní větev, na které byla založena. Moje rutina je obvykle následující:

// začneme od větve fix / my-branch
$ git checkout vývoj
$ git pull
$ git checkout fix / my-branch
$ git sloučit vývoj

Podrobně vysvětlíme, co se tady děje.

Nejprve ze všech git pull dělá to samé jako git fetch + git slučování a to přichází s menší kontrolou a více vedlejšími účinky, nebudeme jít do detailů zde, raději použiji obě metody a tady je moje odůvodnění.

Účelem vývojového oboru je sloužit jako základna pro všechny ostatní pobočky, které vytváříme, abychom psali nový kód, je to čisté, protože před sloučením pracovních oborů vás a váš tým důkladně otestujete.

Protože na vývojovém oboru nepracujete, je vždy čistý. Můžeme použít git pull bez obav z vedlejších účinků. Pravidelná aktualizace této větve pomůže snížit počet sloučení konfliktů v nových větvích, které vytvoříte.

Po aktualizaci můžeme přejít na naši pracovní větev, sloučení odtud by mělo být téměř vždy bezpečné, pokud budeme dodržovat etiketu git.

Pokud sloučení jde bez problémů

Jednoduše zatlačte svou pracovní větev a vyžádejte si tah proti vývoji, počkejte na revizi (a to je, když vaše etiketa odevzdání bude zářit, protože vaši vývojáři budou moci zkontrolovat vaše změny lépe, rychleji a bezbolestně).

Po sloučení vaší žádosti a následování standardní etikety odtud jste hotovi, udělejte si pat po zádech!

Pokud sloučení narazí na konflikty

Vím, vím, že se to děje pořád.

Není těžké to vyřešit. Věř mi! Začněme od začátku a udělejme to ručně, abychom se ujistili, že vše funguje tak, jak bylo zamýšleno. Protože na těchto oborech nebudujeme výrobu a každé odvětví se zaměřuje na konkrétní oblast, naše konflikty budou vždy malé a snadno vyřešitelné.

Sakra, proč?

Jak vidíte, konzole nám již pomáhá tím, že nám dá název souboru, ve kterém došlo ke konfliktům.

Visual Studio je užitečné jako vždy.

To je to, co vidíme v aplikaci Visual Studio otevírající „poškozený“ soubor, umožňuje začít z levého postranního panelu.

(C) ← in purple nám říká, které soubory mají konflikty (vidíme to také na konzole, ale zde je snazší vizualizovat).

V samotném souboru je konflikt, v tomto příkladu je to jednoduchá změna textu, která jasně identifikuje, odkud tyto změny pocházejí. Horní část je aktuální pracovní větev, zatímco spodní část se vyvíjí.

Můžete si vybrat, který z nich chcete přijmout, pomocí praktické nabídky nad samotným konfliktem nebo ručně odstranit starý kód a ponechat nový.

Jakmile vyřešíte všechny konflikty, potvrdí výsledek. Pokud to chcete znovu vyzkoušet, stačí spustit výše uvedené příkazy, abyste znovu vytáhli a sloučili se z vývojové větve a jakmile jste si jisti, že již neexistují žádné konflikty, stačí zatlačit na větvi a vyžádat si požadavek proti vývojové větvi.

Závěr nebo TLDR

Udělejte dobré odevzdání, pochlubte se historií odevzdání, buďte vývojářem, kterého každý miluje ke kontrole, nenechte se obětí konfliktů, pijte alespoň 6 sklenic vody každý den a chodte na procházku každou chvíli.

Najdete část 3 této série zde, a pokud jste si přečetli tu první, můžete si ji přečíst zde.