it-swarm-eu.dev

Nový vývojář nemůže držet krok s fúzem poboček

Jsem nový vývojář - toto je moje první programovací pozice.

Můj problém je tento: Používáme git - odřízl jsem větev z naší develop větve, pak začnu pracovat na menším úkolu, který mi byl přidělen. Je to velmi pomalé, protože jsem nezkušený. V době, kdy jsem připraven sloučit svoji pobočku zpět do develop, ostatní provedli tolik změn, že řešení konfliktů je ohromující (ve skutečnosti se zdá jednodušší zrušit mou práci a začít znovu od úkolu, který z kurz není udržitelným řešením).

Jak to mohu překonat? Existuje taktika, kterou mohu použít jinak než „být lepší v kódování“? Chci to vychovávat příští týden se svým nadřízeným.

225
daisy

Konflikty sloučení získáte, pokud se změny, které jste provedli ve své větvi, blíží změnám, které mezitím provedli vaši kolegové v větvi develop, to znamená, že pokud jste vy a vaši kolegové změnili stejné řádky kódu nebo sousední řádky v stejný soubor.

Aby se snížila pravděpodobnost sloučení konfliktů, můžete se pokusit sloučit dříve, aby vaši kolegové mezitím změnili méně řádků, nebo se sami pokusíte změnit méně řádků.

Chcete-li změnit méně řádků sami, nezapomeňte provádět pouze změny související s vaším úkolem.

Pokud potřebujete experimentovat s různými způsoby, jak dosáhnout svého cíle, možná některé z vašich experimentů změnily řádky, které opravdu nemusí být změněny? Před sloučením tyto změny zrušte.

Existují také některé příkazy Git, které vám mohou pomoci změnit co nejméně řádků:

  • git diff a git diff --staged a uvidíte, které řádky jste změnili.
  • git add -p pro přidání pouze některých změn do souboru.
  • git commit --amend a git rebase -i to Tweak se zavazuje, že jste již vytvořili v místní větvi funkcí, než je odešlete do jiných úložišť Git.

(Změna co nejmenšího počtu řádků může také usnadnit kontrolu vaší práce nebo použití nástrojů, které pracují na rozdílech mezi odevzdáním, například git cherry-pick, git rebase, git bisect, a git blame.)

Ale i když snížíte pravděpodobnost sloučení konfliktů, budete stále narazit na sloučení konflikty někdy. Nebojte se jich, ale naučte se řešit konflikty.

7
Toxaris

Předpokládám, že používáte git. Pokud ano, použijte git rebase -i (-i Znamená interaktivní). Udělejte z každodenního úkolu (v případě potřeby i častěji) odvahu vaší větve proti rozvíjející se větvi. To přináší změny postupně každý den (alespoň), aby vaše větev funkce byla aktuální. Pokud během vaší každodenní rebase dojde ke konfliktu, musíte se svým týmem promluvit o tom, kdo na čem pracuje.

Pokud ji spouštíte denně, pravděpodobně nebudete potřebovat interaktivní část. Nechte to udělat svou věc.

Jsem docela zkušený vývojář a stále mi trvá dost času, než se pustím do práce na novém projektu. Ve vašem případě to zní, jako kdyby na stejném projektu pracovalo několik lidí současně, takže se jedná o velmi velký projekt nebo o nový projekt, který se rychle vyvíjí. V obou případech se nebojte, pokud vám to zabere několik měsíců, abyste se dostali do proudu. Pokud přepnu projekty na 2 nebo 3 týdny a pak přepnu zpět, může mi trvat několik hodin (nebo dokonce den nebo dva), než se úplně vrátím do projektu, který jsem sám napsal 100%!

Stručně řečeno, nebojte se, že právě teď budete pomalí. Způsob, jak se zlepšit, je jen pokračovat v procvičování. Nebojte se zeptat ostatních vývojářů na aspekty projektů, kterým nerozumíte.

UPRAVIT:

Nebo použijte merge. To je také možnost. Výše uvedené by tedy bylo: „využít git rebase -i (-i Znamená interaktivní) nebo git merge“. Pokud jde o to, které použít, promluvte si se zbytkem vašeho týmu. Mohou (nebo nemusí) mít silné preference v obou směrech. Je jasné, že někteří lidé mají silné preference.

286
Jacob Robbins

To by mohlo být známkou špatného softwarového inženýrství ze strany společnosti. Příliš mnoho vzájemných závislostí, různé problémy s překrývajícími se funkcemi, pokus o řešení problémů ve špatném pořadí atd. Mohou způsobit situaci, kterou popisujete. Během vývoje doporučuji sloučení develop do vaší pobočky

130

Přijaté odpovědi jsou podle mě spíše technické povahy „jak lépe používat Git“, myslím, že se jedná spíše o týmový problém než o problém inženýrství nebo nástrojů.

Pokud se setkáváte s mnoha spojovacími konflikty, znamená to, že vy a někdo jiný v týmu šlápnete na ostatní prsty.
Vy nebo oni byste se měli zaměřit na rozvoj osobního prostoru při kódování a vyhnout se práci v oblastech, které jsou již zaneprázdněny.

V mém týmu máme sklon k vysoké míře vlastnictví úkolů.
Obvykle vezmu plné a úplné vlastnictví dvou nebo tří souborů najednou a budu na nich pracovat v pobočce nejvýše jeden nebo dva dny.
Typicky, pokud se někoho dotkne těchto souborů, je to pouze v případě, že je to naprosto nezbytné pro jejich vlastní úkoly, obvykle na stejném bloku úkolů vůbec nepracujeme!

Pokud zjistíte, že se musíte hodně spojit, pak je kód všech vašich týmů na jednom místě (čemu se samo o sobě musí vyhnout) nebo všechny vaše úkoly jsou.

To vše říká, že jako nový dev pravděpodobně nebudete schopni vynutit si, požádat nebo dokonce navrhnout jakoukoli restrukturalizaci.
Očekával bych, že vaše úkoly budou přiděleny jako věci „naučte se lana“, které by měly být přiměřeně přístupné na vaší úrovni dovedností, aby vás usnadnily vstupu do týmu. Pravděpodobně byli utraceni z úkolů spolupracovníka, který stále pracuje ve stejné oblasti, a proto se vaše sloučení střetává.
Řešením je pak to zapojit, vyřešit problémy, řešit střety sloučení, jak nejlépe umíte, a nebojte se příliš, pokud děláte, co je v našich silách, váš manažer se starat o svůj pokrok.
Získáte rychleji a sebevědomě, zatímco vy jdete, a vaši spolupracovníci vám dají větší samostatnost a v důsledku toho se jim dostanete méně.

97
Rowan

Nejdůležitější věcí při slučování je, že čím déle budete čekat, tím bolestivější bude. A problém roste více než lineárně. Třikrát tolik konfliktů je devětkrát tolik práce. Existují některé strategie:

Spojte se s vývojovým odvětvím, kdykoli se změní, takže jste vždy blízko a nikdy nemáte obrovské množství konfliktů.

Pokud budete mít dlouhou dobu, může to být proto, že trávíte většinu času přemýšlením o tom, jaké jsou změny, a poté malým množstvím času provedením změn. V takovém případě před začátkem skutečných změn kódu sloučte s vývojovou větev.

Promluvte si se svými kolegy o strategiích, jak zabránit konfliktům. Pokud dva lidé upraví stejný kód, dojde ke konfliktům. Nejen stejný soubor, ale stejný kód. Potřebuji tedy novou funkční funkciA a vy potřebujete novou funkční funkciB a oba ji přidáme na konec stejného souboru, máme konflikt. Pokud ji přidáme na různých místech, žádný konflikt. Pokud jej oba přidáme na místo v souboru, kam logicky patří, je pravděpodobné, že nemáme konflikt.

Pokud máte konflikty, získejte dobrý rozdílový nástroj, takže můžete porovnat vývojovou větev před sloučením, kód před sloučením, původní kód a sloučený kód a sloučit ručně.

Nejhorší případ: Svou práci nevyhazujete, ale pomocí dobrého rozdílového nástroje zjistíte přesně, jaké změny jste provedli, odbočte znovu z vývoje a všechny změny, které jste provedli, použijete ručně místo jejich opakování.

29
gnasher729

V době, kdy jsem připraven sloučit moje větev zpět do vývoje (důraz důl)

Řešení konfliktů v git merge je často jednodušší než v git rebase. V Git merge můžete vidět celý seznam souborů, které byly změněny najednou. Bez ohledu na to, kolik závazků bylo provedeno jinými spolupracovníky, budete muset sloučit jedno. Díky pracovnímu postupu rebase můžete skončit opakováním stejných konfliktů a musíte je zkontrolovat ručně. Můžete nakonec opravit 13. odevzdání a cítit se jako , že nevidíte světlo z tunelu .

Podle mé zkušenosti, když jsem se pokoušel naivně řešit opakované rebase konflikty, nakonec jsem ztratil něčí úpravy nebo s aplikací, která se nezkompilovala. Já a spolupracovníci jsme často odvedli spoustu práce, ale byli tak ohromeni složitostí opakujících se konfliktů, že jsme museli zrušit a ztratit naši předchozí práci poté, co se hrstka rebase zavázala.

Navrhuji vám několik technik, ale mohou pomoci sloučení snadněji, než automatizovat úkol.

  • Zdrojové/jazykové soubory. Pokud máte aditivní změny zdrojového souboru, ujistěte se, že je vždy přesunete na konec souboru, abyste si mohli snadno vyvolat změny proti ostatní 'změny. Je možné, že budete moci zkopírovat a vložit své změny na konec, nebo jen odstranit značky konfliktů
  • Do. Ne. ABSOLUTNĚ. RE-formát. Ani vy, ani vaši kolegové vývojáři nebudete provádět každodenní „masivní reformát kódu“. Přeformátování kódu přidává nadměrný počet falešných pozitiv při řešení konfliktů. Lze přeformátovat kód
    • Postupně, např. každý vývojář při každém odevzdání, jakmile použijí automatizovaný nástroj (např. Eclipse má možnost přeformátovat při uložení, Vanilla Visual Studio nemá žádné). Absolutně každý vývojář musí používat stejné standardy formátování kódu, kódované do formátu, který je sněden vaším IDE. Pro představu, jestli to jsou 4 mezery nebo 2 karty, na tom nezáleží, ale opravdu záleží na tom, jestli všichni používají stejné.
    • Těsně před propuštěním vedoucím týmu. Pokud dojde k odhodlání „přeformátování kódu“, když lidé na větvích nepracují, tj. Před větvením, bude to snazší
  • Recenze dělení práce mezi spolupracovníky. Toto je část, kde přichází většina inženýrství. Jak ukazují další odpovědi, je to vůně designu, pokud se více vývojářů, kteří dělají různé úkoly, musí dotknout stejných zdrojů. Možná budete muset s vedoucím týmu diskutovat o tom, která část má být upravena každým souběžným vývojářem.

V mých týmech jsem také viděl některé špatné návyky v pracovních postupech Gitu. Lidé často přebírají své pobočky. Osobně jsem byl svědkem vývojáře, který přidal 10 až 20 revizí označených jako „opravit“, z nichž každá spáchala jeden nebo dva řádky. Naše politika je, že závazky jsou označeny lístky JIRA, aby vám poskytly představu.

@JacobRobbins navrhuje vytvořit git rebase denní úkol. Chtěl bych posunout jeho přístup vpřed.

Nejprve použijte rebase jednou, abyste snížili počet odevzdaných hrstek. A rebase pouze na vývojovou větev original, což je závazek, ze kterého jste se rozvětvili. Když řeknu hrst, mohl bych znamenat 3 nebo 4 (např. Všechny front-endy, all back-endy, všechny databázové záplaty) nebo jakékoli lidsky rozumné obrázky. Poté, co je sloučíte, použijte fetch a proveďte rebase přes větve proti proudu. To vás nezachrání před konflikty, pokud váš tým neposoudí svůj vlastní přístup, ale váš život bude méně bolestivý.

Pokud máte další dotazy týkající se konkrétních úkolů, neváhejte a zeptejte se na Stackoverflow.

[Upravit] o pravidlu bez reformátu a skautského pravidla. Mírně jsem přeformuloval RE-format, abych zdůraznil, že tím, co mám na mysli, je formátovat od začátku celý zdrojový soubor, včetně kódu, kterého jste se nedotkli. Na rozdíl od toho, abyste vždy formátovali svůj vlastní kód, který je dokonale chlapec, je řada vývojářů, včetně mě, použita k přeformátování celého souboru pomocí schopností IDE. Když se souboru dotknou ostatní, i když se dotčené řádky nezmění v obsahu a sémantice, Git jej uvidí jako konflikt. Pouze velmi výkonný editor, který si je vědom jazyka, může navrhnout, že konflikt souvisí pouze s formátováním a automaticky sloučí nejlépe formátovaný fragment. Ale nemám důkaz o takovém nástroji.

Koneckonců, pravidlo skautů vás neopravňuje k čištění nepořádku ostatních lidí. Jen tvoje.

Nejprve nemyslete na vyřazení vašich změn. Ztratíte příležitosti naučit se proces sloučení.

Za druhé, najděte osobu, která pracovala na souborech způsobujících konflikty. Můžete vidět historii. Promluvte si s osobou a vyřešte konflikty v těchto souborech. Totéž udělejte pro další konflikty.

Pokud je příliš mnoho konfliktů, může být váš úkol menší, ale opakující se. Pokuste se najít vzorec. Pomohlo by to při řešení konfliktů klientskými nástroji Git UI. Používám TortoiseGit. Pomáhá při slučování.

A pro budoucí vyhýbání se

  • Je velmi dobrým zvykem pravidelně spojovat vývojovou větev s vaší větev funkcí.

  • Pokud máte povoleno CI, zkontrolujte, zda nástroj CI poskytuje sestavení větví. To by mělo stavět na každé kontrole, kterou provedete ve větvi funkcí, ale po sloučení se vyvíjí větev.

6
PKV

Existuje zde několik základních problémů. Vaše sloučení problémů pravděpodobně není vaše chyba a častěji jsou příznakem špatných praktik.

1) Ideálně by se vaše pobočka spojila do rozvoje každý den. Zkuste mít pracovní kód alespoň jednou denně, který projde všemi testy, abyste se mohli sloučit do vývoje.

2) Pokud nemáte pracovní kód v žádném okamžiku během obvyklého pracovního dne, pravděpodobně máte příliš velké kusy kódu, na které byste mohli pracovat. Musíte rozdělit svůj úkol na menší úkoly, které lze dokončit (ideálně nezávisle na sobě) rychleji, abyste se mohli sloučit.

3) Vaše soubory projektů jsou pravděpodobně příliš velké. Pokud pro soubor existuje mnoho konfliktů slučování, na jednom souboru pracuje příliš mnoho lidí. V ideálním případě by něco, na čem jedna osoba pracuje, mělo být oddělené od toho, na čem pracují všichni ostatní.

4) Váš tým může být příliš velký. Pokud je pro vás snazší zahodit celou funkci a začít znovu, je pravděpodobné, že do stejného úložiště odevzdává příliš mnoho lidí.

5) Možná nemáte jednotné standardy formátování kódu. Pokud všechny konzistentně nepoužíváte stejné formátování kódu, dostanete za stejný kód mnoho různých konfliktů. V závislosti na tom, jak je váš git nastaven, mohou dokonce dojít ke konfliktům v mezerách (konce řádků, odsazení, karty vs. mezery).

6) Lidé by mohli tlačit své změny přímo do rozvíjejícího se odvětví.

Zde je to, co může vy umět: 1) Pokud se nemůžete sloučit do rozvoje každý den, slučování/rebase se vyvíjí do vaší pobočky každý den (nebo častěji).
2) Zkuste, aby byl váš kód oddělen od kódu všech ostatních.
3) Promluvte si se zbytkem týmu o menších funkcích, konzistentních standardech kódování a lepší organizaci kódu (menší soubory, menší funkce).

2
xyious

Ve skutečnosti se zdá snazší zrušit mou práci a začít znovu od úkolu, což samozřejmě není udržitelné řešení)

Většinou to je to, co dělám, když poprvé opravím chybu nebo provedu změnu systému, učím se, jak to udělat. Až příště opravím stejnou chybu, zabere to jen 1% času, protože nyní chápu problém.

Zjistil jsem také, že když opakuji trochu práce, píšu lepší kód .....

Proto není nic špatného s vytvořením nové větve od mistra, přepracováním vaší práce v něm, zatímco pomocí vaší „soukromé větve“ vám připomene, co musíte udělat.

Je také možné, že jste objevili způsob, jak rozdělit svou změnu na logické a správné části, z nichž každá bude po dokončení sloučena do hlavní větve. Například je možné provádět testy jednotek a změny backendového kódu a sloučit je. Poté v samostatné operaci můžete provádět změny uživatelského rozhraní, které je využívá, takže je menší riziko, že někdo jiný upraví stejný soubor uživatelského rozhraní.

1
Ian

Pokud nechcete sloučit vývojovou větev do vaší větve příliš často, můžete získat pracovní postup, který je více podobný svn, pomocí git pull --rebase. Tím se stáhnou nové závazky a znovu se s nimi spojíte. To znamená, že když se vaše větev sloučí do vývoje, bude to rychlé sloučení (jako kdybyste přidali všechny své minulé závazky ve stejnou dobu jeden po druhém) a neměli byste žádné konflikty slučování, protože jste je vyřešili všechny během git pull --rebase.

Ale čím více se zavazujete, než začnete sloučit svou větev do vývoje nebo vývoje do své větve, tím složitější bude příští rebase získat a poněkud převrátí smysl větví funkcí, protože vaše větev existuje pouze tak dlouho, dokud není sloučena. .

1
allo

Samozřejmě první věcí je zabránit tomu, aby na stejných souborech nejprve pracovalo více lidí, alespoň způsobem, který vede k obtížným konfliktům. Přidávání věcí do výčtů není žádný problém, pokud je použit dobrý formát kódu. Změna řídicího toku různými způsoby a pohybující se kód je mnohem složitější. Nicméně někdy je to nevyhnutelné. Budete muset klást otázky při řešení konfliktů, které jsou skutečně složité.

To znamená, že vidím mnoho odpovědí, které doporučují pravidelně se slučovat/rebase. Byl bych mnohem méně nadšený z takové rady. Vaším cílem v tomto bodě je učinit proces řešení konfliktů co nejjednodušší a nejbezpečnější. Jednou z věcí, která s tímto procesem nesmírně pomůže, je mít okamžitě k dispozici tolik regresních testů, včetně těch nových, které jsou součástí vaší nové funkce. Pokud synchronizujete svou větev velmi pravidelně s vývojem, vždy budete muset nakonec vyřešit konflikty, zatímco jste ve skutečnosti polovinu implementace své funkce. A to znamená, že bude mnohem obtížnější pokusit se zjistit, co má kód dělat, protože jste s tím neučinili. Před pokusem o sloučení se ujistěte, že vaše větev je koherentní jednotkou změny. Ještě lepší je sloučit do jediného odevzdání před sloučením.

Snažil jsem se jít do podstaty rebase přes sloučení, což je pravděpodobně pro jinou otázku. V této souvislosti na nástrojích opravdu nezáleží.

1
Kafein

V době, kdy jsem připraven sloučit svou pobočku zpět do rozvoje, ostatní provedli tolik změn, že řešení konfliktů je ohromující

Zní to jako ideální scénář pro párové programování !

Více informací o výhodách a základních přístupech:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

Postupem času budete pracovat sami, samozřejmě se zrychlíte, ale může to být skličující, dokud nenastane ten čas, a někdy je to také dlouhá cesta. I když se lidé mohou rychle naučit, že jsou ve stresujícím prostředí, vždy pod tlakem, aby je dohonili, ostatním, kteří se neučí dobře pod stálým tlakem, bude bráněno.

Místo toho, abyste pracovali na větvi sami a pokusili se držet krok s ostatními devy, kteří jsou zjevně mnohem rychlejší než vy, místo toho byste pracovali přímo (stejné PC) s jiným dev. Tímto způsobem získáte okamžitou radu a pravděpodobně vyberete tipy, jak urychlit atd.

Měli byste zjistit nejlepší přístup pro konkrétní kód ve vašem projektu, protože párové programování ne vždy dává smysl pro některé projekty - i když to pravděpodobně vždy dává smysl pro učení, i když jen tak sedíte a sledujete někoho zkušenějšího než jste vy (pokud jsou dobrým vývojářem, zkušenost nutně neznamená, že používají správné postupy).

Posezení s rychlejším a zkušenějším dev má potenciál pomoci:

  • Pravděpodobně sníží konflikty sloučení, protože práce s někým zkušenějším prodlouží čas dokončení na rozdíl od samotné práce
  • Protože vás budou učit, je pravděpodobné, že budou pomalejší, než by pracovali sami, takže stále mohou existovat nějaké sloučení konfliktů, a tak mohou skrze ně pracovat s někým ostříleným, a tak možná vyzvednout několik tipů, jak ušetřit čas atd.
  • Pomozte vidět potenciální triky a způsoby, jak být rychlejší (i když pomalý je někdy jen nedostatek zkušeností, spíše než nedostatek dobrých postupů)
  • Může něco pokládat okamžitě, když něco nedává smysl nebo není 100% jasné
  • Práce 1: 1 je cenná pro učení, protože osoba, od které byste požádali o pomoc, již chápe přesný kód a scénář, protože na něm pracují, aniž byste museli programovat párování, musíte vysvětlit kód a scénář, který často končí problémem a takže ztrácíte čas/pozornost při získávání tolik potřebných rad
  • Seznamte se s myšlenkovým procesem někoho zkušenějšího a zkušenějšího a s dobrou komunikací se určitě naučíte nové věci

Existuje taktika, kterou mohu použít jinak než „být lepší v kódování“? Chci to vychovávat příští týden se svým nadřízeným.

Moje rada je prodiskutovat párové programování s ostatními devs a pak se obrátit na svého nadřízeného. Pokud jsou slušní, ocení vaši iniciativu, která má větší šanci, abyste přednesli výhody párového programování (pokud to potřebují, většina lidí o tom ví a je běžné, proč to pomáhá).

1
James

Když pracujete na běžných souborech, musíte vy nebo vaši spoluhráči vyřešit všechny konflikty před dokončením sloučení, proto nejprve nezůstaňte naštvaní . Stále pracujete na projektech a jste na svou práci hrdí. Nyní, pokud chcete chytřejší tah, můžete sledovat níže uvedené návrhy.

  1. Rozdělte úkoly samostatně:

    Před zahájením práce naplánujte a rozdělte celé úkoly tak, aby přiřazený úkol pro každého člena týmu byl co nejvíce nezávislý a modulární (abyste se vyhnuli možným konfliktům při vývoji). Můžete se obrátit na svého vedoucího scrumu a přiřadit vám nějaké nezávislé úkoly, když jste nováček.
  2. Sloučit granulární časté závazky:

    Nečekejte, až bude dokončen celý úkol před závěrečným pochodem. Samozřejmě jakékoli větší úkoly lze rozdělit do více dílčích úkolů. Lepším přístupem je tedy sloučit menší závazky pro menší dílčí úkoly současně, aby se zabránilo objemnému řešení konfliktů.
  3. Časté opakování pobočky:

    Proveďte praxi časté rebase vaší místní pobočky pomocí vzdálené pobočky. Pomocí příkazu níže můžete často znovu lokalizovat svoji pobočku pomocí vzdálené,

    git pull --rebase #or
    git pull --rebase Origin dev #when dev is remote branch
    

    To je zatím pro mě nejužitečnější git příkaz v mém vývojovém životě.

  4. Úzce spolupracujte se spoluhráči:

    Pokud opravdu potřebujete pracovat společně se svým spoluhráčem na společném úkolu, prosím, spolupracujte. Může se na vás někdy dočkat, až se vyhne složitému řešení konfliktů, protože jste nováček a je odbornicí.

  5. Být zvyklý na možnosti git:

    Využijte sílu nástrojů pro sloučení git. Při slučování existuje mnoho pohodlných způsobů řešení konfliktů. Sloučení strategií někdy může hodně pomoci. Být zvyklý a nebojácný s příkazy git.

1

Měli byste pravidelně (denně) spouštět příkaz 'git fetch' (ne git pull) z vývojové větve. To způsobí, že ostatní lidé provedou změny a přivedou je do vaší větve funkcí, aniž by se pokusili integrovat změny do vaší větve.

To je něco, o čem byste měli mluvit s hlavním vývojářem (ne nutně se svým manažerem), protože vaše společnost může mít své vlastní standardy nebo doporučené způsoby řešení tohoto problému; je to velmi běžné. Nečekejte do příštího týdne - zjistěte tento proces nyní a zeptejte se, zda můžete provést nějakou triviální práci (například formátování kódu nebo přidání komentářů), abyste mohli tento proces otestovat.

1
PeteCon