it-swarm-eu.dev

Kdy je kontrola verzí příliš velká?

Slyšel jsem na několika místech „Nedělají velké závazky“, ale nikdy jsem vlastně nechápal, co je „velké“ potvrzení. Je to velké, pokud pracujete na spoustě souborů, i když s tím souvisí? Na jakých částech projektu byste měli pracovat současně?

Pro mě mám potíže s pokusem o „malé odevzdání“, protože zapomínám nebo vytvářím něco, co vytváří něco jiného, ​​co vytváří něco jiného. Pak skončíte s takovými věcmi:

 Vlastní odchozí fronta 
 
 Bot 
 - Nové pole msgQueue, které není ničím jiným než SingleThreadExecutor 
 - posílám bloky Msg, dokud není odeslána zpráva, a přidává čekání mezi odesláním zpráv 
 
 - aktualizace adminExistních hovorů (viz řadič) 
 - Odebráná čísla pro odesláníMessage 
 
 Kontrolér 
 -Nové pole msgWait označuje čas čekání mezi zprávami. 
 - Spuštění servisních pluginů přesunuto do reloadPlugins 
 - adminExists přesunutý ze serveru kvůli globálním administrátorům. Kontroly na kanále, 
 Serveru a globální úrovni 
 
 Admin 
 - Nové metody getServer a getChannel, které získají vhodný objekt Admin 
 Patří do 
 
 BotEvent 
 - toString () také zobrazuje další a extra1 
 
 Kanál 
 - pole kanálu přejmenované na jméno 
 - Opraveno překlepy v kanálu (int) 
 
 Server 
 - Přesunuto adminExistuje do Controlleru 
 
 PluginExecutor 
 - Menší testování přidáno, bude odstraněno později 
 
 JS Pluginy 
 - Aktualizováno na změny rámce 
 - Nahrazeno InstanceTracker.getController () s Controller.instance 
 - VLC nyní mluví ve vlastním souboru 
 
 Různé NB aktualizace projektu a změny 
 
 --- 
 
 Dotčené soubory 
 Upravit /trunk/Quackbot-Core/dist/Quackbot-Core.jar
Modify /trunk/Quackbot-Core/dist/README.TXT
Modify /trunk/Quackbot-Core/nbproject/private/private.properties
Modify/trunk/Quackbot-Core/nbproject/p rivate/private.xml 
 Upravit /trunk/Quackbot-Core/src/Quackbot/Bot.Java
Modify /trunk/Quackbot-Core/src/Quackbot/Controller.Java
 Upravit /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.Java
Modify /trunk/Quackbot-Core/src/Quackbot/info/Admin.Java
Modify/trunk/Quackbot-Core/src/Quackbot/info/BotEvent.Java 
 Upravit /trunk/Quackbot-Core/src/Quackbot/info/Channel.Java
Modify/kufr/Quackbot-Core/src/Quackbot/info/Server.Java 
 Upravit /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar
Modify /trunk/Quackbot-GUI/dist/README.TXT
Modify/trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar 
 Upravit /trunk/Quackbot-GUI/nbproject/private/private.properties
Modify/trunk/Quackbot-GUI/nbproject/private/private.xml 
 Upravit /trunk/Quackbot-GUI/src/Quackbot/GUI.Java
Modify /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.Java
 Odstranit /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.Java
Modify/t runk/Quackbot-Impl/dist/Quackbot-Impl.jar 
 Upravit /trunk/Quackbot-Impl/dist/README.TXT
Modify/trunk/Quackbot-Impl/dist/lib/Quackbot- Core.jar 
 Upravit /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar
Modify /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
 Upravit /trunk/Quackbot-Impl/lib/javarebel.stats
Add /trunk/Quackbot-Impl/lib/jrebel.info
Modify/trunk/Quackbot-Impl/nbproject/private/private.properties 
 Změnit /trunk/Quackbot-Impl/nbproject/private/private.xml
Modify /trunk/Quackbot-Impl/nbproject/project.properties.____.]Modify/trunk/Quackbot-Impl/pluginy/CMD/Admin/reload.js 
 Přidat /trunk/Quackbot-Impl/plugins/CMDs/Operator/hostBan
Modify/trunk/Quackbot-Impl/plugins/CMDs/Operátor/mute.js 
 Upravit /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js
Modify /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js 
 Upravit /trunk/Quackbot-Impl/plugins/listeners/onJoin.js[._ ___.] Upravit /trunk/Quackbot-Impl/plugins/listeners/onQuit.js
Modify /trunk/Quackbot-Impl/plugins/testCase.js
Add/trunk/Quackbot-Impl/plugins /utils/whatsPlaying.js
Modify /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.Java
Add /trunk/Quackbot-Impl/vlc_http
Add/trunk /Quackbot-Impl/vlc_http/current.html
Modify /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar
Modify /trunk/Quackbot-Plugins/dist/README.TXT 
 Upravit /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar
Modify /trunk/Quackbot-Plugins/nbproject/private/private.properties
Modify/trunk/Quackbot -Plugins/nbproject/private/private.xml 
 Upravit /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.Java
Add /trunk/Quackbot-Plugins/vlc_http
 Přidat /trunk/global-lib/jrebel.jar

Ano....

Takže pro otázky:

  • K čemu jsou některé faktory, kdy je závazek příliš velký (neviditelné věci)?
  • Jak můžete zabránit takovým závazkům? Uveďte prosím specifika
  • A co když jste v poločasných stádiích vývoje, když se věci rychle pohybují? Jsou obrovské závazky stále v pořádku?
67
TheLQ

Pro mě mám potíže s pokusem o „malé odevzdání“, protože zapomínám nebo vytvářím něco, co vytváří něco jiného, ​​co vytváří něco jiného.

To je problém. Vypadá to, že musíte čit se, abyste rozdělili svou práci na menší, lépe zvládnutelné kousky.

Problém s velkým odevzdáním je:

  • V projektu s více osobami větší šance, že vaše závazky způsobí konflikty, které ostatní vývojáři vyřeší.
  • Je těžší přesně popsat, co bylo provedeno ve zprávách protokolu.
  • Je obtížnější sledovat pořadí, ve kterém byly provedeny změny, a proto pochopit příčinu problémů.
  • Zvyšuje to pravděpodobnost ztráty hodně práce bez závazků.

Někdy jsou velké závazky nevyhnutelné; např. pokud musíte změnit hlavní API. Normálně tomu tak ale není. A pokud se v této situaci ocitnete, je asi dobrý nápad vytvořit pobočku a tam pracovat ... se spoustou malých odevzdání ... a po dokončení se znovu integrovat.

(Jiný případ je, když provedete počáteční import, ale to NENÍ problematické z pohledu výše uvedených problémů.)

68
Stephen C

Zásada jednotné odpovědnosti

Každé potvrzení kontroly zdroje by mělo sloužit pouze jednomu účelu. Pokud musíte do svého shrnutí vložit slovo „a“ nebo „také“, musíte je rozdělit.

Je velmi běžné skončit se spoustou samostatných nesouvisejících nebo částečně souvisejících změn ve vaší pracovní kopii. Tomu se říká „zamotaný problém s pracovní kopií“ a ve skutečnosti je velmi těžké se vyhnout i pro disciplinované vývojáře. Git a Mercurial vám však poskytují nástroje k jeho vyřešení - git add -p nebo výběr kusů a Mercurial Queues v TortoiseHg .

40
jammycakes

Představte si, že klient požádal o provedení konkrétní změny - například přidat pravidlo, že něco nebo jiné nemůže být provedeno do dvou dnů od „jakéhokoli“ data. Poté, co provedete změnu, změní názor. Budete chtít zrušit váš závazek. Pokud je to všechno spojené s některými věcmi o změně pořadí řazení nesouvisejících zpráv, váš život je bída.

Jedna pracovní položka, jedna sada změn. Jeden požadavek od klienta, jeden changeset. Jedna věc, o které byste mohli změnit názor, jedna changeset. Někdy to znamená, že se jedná o jeden řádek kódu. Někdy se jedná o deset různých souborů včetně schématu databáze. To je v pořádku.

26
Kate Gregory

Velké provize jsou, když máte spoustu změn, které ve skutečnosti nejsou všechny ve stejném kbelíku. Pokud změním logiku řadiče, pak model připojení k databázi, pak nějaké různé. skripty, neměl bych to všechno spojovat pod jedno potvrzení.

Prevence se zavazuje podle toho, co dokončujete. Ve výše uvedeném příkladu bych se zavázal po logice řadiče, po práci s databází a po skriptech. Neodkládejte páchání jednoduše proto, že vy víte, co se změnilo. Ostatní lidé se budou dívat zpět na vaši "Změněné věci" odevzdat zprávu protokolu a přemýšlet, co jste kouřili.

Počáteční dovozy jsou pravděpodobně největší závazky, jaké byste měli mít. Nastavení systému od nuly? Jistě mají několik velkých závazků. Poté, co jste to vyrovnal, i když je čas, aby věci uspořádány.

10
Josh K

Pokud víte, že budete předem pracovat na velkém kusu kódu, navrhl bych vytvořit větev pro vaši konkrétní funkci a zároveň pravidelně stahovat kód dolů z hlavní řady, abyste zajistili, že váš kód zůstane synchronizovaný. Po dokončení práce na větvi sloučte všechny své změny zpět do hlavní řady. Tímto způsobem ostatní členové týmu nebudou překvapeni a/nebo otráveni, když uvidí obrovský závazek. Existuje také mnohem menší šance na rozbití věcí. Pokračujte v rozdělování věcí na menší závazky. Časem se stane druhou přirozeností.

7
ysolik

Tento příklad ukazuje příliš velké potvrzení.

Obecně popište změnu v jedné větě nebo jednom řádku textu. (Na základě tohoto pravidla by mělo být potvrzení rozděleno na 10-15 menších.) Pokud nemůžete adekvátně komentovat odevzdání v jednom řádku, je to už příliš velké.

Chcete-li praktikovat menší odevzdání, zapište si do poznámkového bloku (nebo do Poznámkového bloku) to, co jste již změnili nebo přidali. Potvrďte před tím, než se stane dlouhým seznamem nebo před provedením změny kódu, která nesouvisí s tím, co již máte v poznámkovém bloku.

7
azheglov

V mém oboru (fyzikální modelování) objevuji dnes chybu ve výstupu, která nebyla v úložišti před 6 měsíci. Když k tomu dojde, provedu binární vyhledávání revizí:

  1. Spusťte model před 3 měsíci
  2. Pokud je chyba stále na výstupu, spusťte model před 4,5 měsíci
  3. ... opakujte, dokud nenajdu potvrzení, které přináší špatný výstup

Když byla chyba představena v obludném odevzdání, musím sedět s hřebenem s jemnými zuby, abych našel zdroj problému. Pokud se revize dotkla malého počtu souborů, je méně bolestivé sledovat řádky kódu, které problém zavedly.

Doporučil bych rozdělit váš problém do řady menších úkolů (ideálně vložte každý úkol do sledovače chyb). Po dokončení každého úkolu se zavázejte (a zavřete tuto chybu/funkci v nástroji pro sledování chyb).

6
Pete

Není to velikost závazku, na čem záleží, je to rozsah změny, která by měla určovat, jak jsou vaše závazky organizovány.

Můžete například změnit každou instanci __macro1 to __macro2 ve velké kódové základně, která mění 200 souborů. V tomto případě by 200 závazků nebylo rozumných.

To, co chcete skončit, je možnost vytáhnout repozitář při jakékoli jediné revizi a mít sestavení práce. Změnili jste z libfoo na libbar? Doufám, že změna zahrnuje aktualizaci vašich build skriptů a Makefiles (nebo cokoli, co je relevantní).

Někdy budete možná muset provést řadu experimentálních změn, které provedou jednu věc. V takovém případě musíte určit, jaký rozsah je pro vás důležitější, pokud se potřebujete vrátit později. Závisí jeden na druhém? Zavázat je všechny najednou v jediné revizi. V opačném případě bych navrhl jeden závazek na změnu. Měli byste dělat něco podobného v jiné větvi nebo v jiném repo.

I když ano, máte pravomoc vrátit jeden soubor na předchozí revizi (a tak zálohovat jeden soubor z většího závazku), čímž se skutečně opraví nástroje, jako je bisekce, později na silnici a znečišťuje historii.

Pokud se zastavíte a pomyslíte si: „Dobře, testy projdou, myslím, že to funguje .. ale pokud se to pokazí, můžu to snadno zálohovat?“ .. budete nakonec dělat rozumné závazky.

5
Tim Post

Věc, kterou zde musíme pochopit, je, že „velký“ v tomto kontextu je o počtu odlišných změn, nikoli o fyzické velikosti odevzdání (i když obecně dva půjdou ruku v ruce).

Není to tak otázka „nedělejte velké páchání“, jako do udělejte malé páchání - ideální bytost k páchání malých samostatných změn.

Z changelogu je zřejmé, že máte řadu věcí, které by mohly být spáchány samostatně (a bezpečně), a proto je docela zřejmé, že je příliš velký.

Důvodem, proč to může být problém, je to, že váš poslední závazek je vaším referenčním bodem pro změny, které aktuálně provádíte, a pokud například dostanete první bit správně a pak dostanete další bit špatně, nemáte snadný způsob vrátit svou práci zpět do bodu, kdy jste začali dělat chyby (BTDTGTTS).

Samozřejmě, že někdy jsou změny jen velké - rozsáhlé refactorování - a jak to navrhují jiní, je třeba se tam rozvětvit, takže i když váš jednotlivec se zavazuje, teoreticky by mohl zlomit věci, které jsou oddělené od hlavního vývojového kmene, takže to není problém a budete pokračovat v závazku brzy a často.

Ještě jedna věc - pokud se uprostřed práce objeví něco, co vyžaduje více okamžité pozornosti, musíte ji změnit samostatně (ideálně ve zcela odlišné sadě složek) a odevzdat ji samostatně.

Skutečnou výzvou v tom všem není mechanika, která má na mysli - že revize není jen záložní kopie, kterou děláte tu a tam, ale že každá revize je po centimetrovém oblázku a že s partií není nic špatného malých odevzdání a že munging různých věcí společně v davu spáchat je stejně špatné munging vágně související kousky funkčnosti společně v kus kódu.

4
Murph

Přinejmenším se trénujte, abyste se zavázali, kdykoli si budete myslet sami sebe: „Líbí se mi můj dosavadní pokrok a nechci ho ztratit, pokud změny, které se chystám provést, jsou katastrofou.“ Pak máte možnost využít VCS k odstranění všech slepých uliček, které jste vyzkoušeli, nebo speciálního ladicího kódu, který jste přidali ke zjištění problému. (např. s git reset --hard nebo rm -rf *; svn update)

4
Ken Bloom

Neexistuje žádné tvrdé a rychlé pravidlo, žádná dělicí čára, kolem které by byl váš závazek příliš velký.

Tam is je však vodítko, že menší odevzdání je lepší, v rozumném smyslu (tj. Odevzdání každé řádky je probaby nadměrné).

Mám na paměti tyto druhy pokynů:

  • Jediné potvrzení by mělo zahrnovat změny pouze pro jednu opravu chyby
  • Jeden závazek by neměl zahrnovat práci delší než půl dne
  • Jediné potvrzení by nemělo stavět

Samozřejmě - to jsou to, na co mám na paměti - YMMV. Různí vývojáři upřednostňují různé úrovně granularity.

2
Bevan

Čím menší je odevzdání, tím snazší bude najít přesně to, odkud potenciální regrese pochází.

V ideálním případě by potvrzení mělo být atomové, ve smyslu nejmenší koherentní změny v kódové základně (související s chybou, funkcí atd.).

Pokud jde o konkrétní tipy, jak udržet velikost potvrzení malé, záleží do značné míry na vašem VCS a na tom, jak je nastaveno: musíte být schopni lokálně odevzdat nebo pracovat ve své vlastní větvi na serveru.

Klíčem je zavázat se k vaší „soukromé“ pobočce pokaždé, když provedete atomovou změnu, a pak můžete pravidelně spojovat svoji pobočku, například každý týden.

Pomocí dvcs by váš pracovní postup mohl vypadat takto:

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git Push         // Push your previous commits to the team server

Pomocí centralizovaného vcs:

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch
1
Xavier T.

V mém případě se pokouším odevzdat soubory serveru do úložiště (SVN). Toto je počáteční potvrzení a nechcete ho stahovat, protože se jedná o opravdu velký projekt (několik GB) a já chci provést počáteční potvrzení ze serveru klientů.

Problém je, že klient je na sdíleném serveru, klient svn je zabit (nebo jakýkoli jiný software), pokud běží déle než minutu.

Jednou alternativou by bylo stažení projektu do mého počítače a provedení původního odevzdání, ale zajímalo by mě, jestli v SVN existuje možnost rozdělit velké potvrzení na více, něco podobného transakčním metodám.

Vývojář přede mnou nikdy nepoužíval systém pro správu verzí.

0
CGeorges

Odpovědi na vaše otázky:

1) Pro mě je standardní odevzdání považováno za velké, pokud dělá více než jednu věc. Myslím tím opravu chyby nebo přidání funkce.

2) Předcházejte takovýmto závazkům tím, že se stane zvykem a pravidlem zavázat se vždy, když něco dokončíte.

3) V poločasných stadiích vývoje dovoluji, aby se zavázala zahrnout první vytvoření souborů, které budou použity později.

Chtěl bych poznamenat, že na konci mám na mysli, že všechny chyby, které můžete identifikovat, byly opraveny a stavbu nezrušíte tím, že se dopustíte.

Ano, to generuje velké množství potvrzení, ale umožňuje vám vrátit se zpět přesně k tomu, co rozbilo věci, místo toho, abyste museli vrátit zpět velkou řadu změn, ke kterým došlo současně, kde problém způsobuje pouze jedna ze změn.

Chtěl bych také zdůraznit, že pravidla se pro systémy s distribuovanou verzí (DVCS), jako je Mercurial a Git, trochu mění. V případě, že některý z nich používáte, zavazujete se, kdykoli jste provedli změnu, ale ještě jste to netestovali, a když to funguje, zatlačte do centrálního úložiště. To je vhodnější, protože vám umožní revizi dalších změn kódu bez obav z přerušení sestavení.

0
indyK1ng

Pravděpodobně jste slyšeli přísloví, že dokonalost je, když už nic víc nemůžete vzít. To by také mělo popisovat váš standard pro velikost odevzdání.

Záleží na vašem projektu, kde je ta „dokonalá“ velikost. Pokud dodáváte externím zákazníkům, může být dobrá velikost nejmenší přírůstek, který by vám vyhovoval, pokud byste nedokončili další včas. Pokud stavíte interní, často nasazené aplikace, nejlepší velikost může být nejmenší přírůstek, který nic nezlomí (a dostane vás blíže k místu, kde chcete být).

Moderní systémy pro správu verzí vám pomohou vytvářet dobré transakce pomocí snadného větvení, interaktivního rebasingu, pracovní oblasti atd.

0
Peter Eisentraut

Potvrzující zprávy by měly být pouze na jednom řádku (a pro git max. 60 znaků). Množství potvrzeného kódu musí být dostatečně malé, aby udržovalo popisnou zprávu v tomto limitu.

Mám sklon se dopouštět pokaždé (ještě více, takže nyní jsme přešli na git) Mám hotový kus, protože to umožňuje zachytit „proč“ se věci dělaly tímto způsobem.

0
user1249

Někdy jste celý den pracovali na několika různých logicky odlišných šagnech a zapomněli jste mezi nimi zadat svůj kód. Použitím git citool může být velmi nápomocný při rozdělování práce na kousky pěkného kousnutí na konci dne, i když jste během dne nebyli tak opatrní, když jste pracovali.

git citool vám umožní vybrat, které konkrétní skupiny souborů (nebo které konkrétní řádky) mají být odevzdány v konkrétním odevzdání, takže můžete rozdělit (nepřekrývající se) změny provedené ve stejném souboru na několik potvrzení.

(Zdá se, že používáte Subversion. Nevím o nástroji, který to dělá pro Subversion, ale mohli byste se podívat do použití git-svn, adaptér Subversion pro git, který změní váš život.)

0
Ken Bloom

Čím větší je odevzdání, tím je pravděpodobnější, že rozbijete sestavení a zbytek týmu vám vyplatí. Snažím se provádět změny dvakrát denně. Těsně před obědem a předtím, než odjedu domů. Takže @ 12:00 a 16:30 se snažím, aby všechno fungovalo a bylo připraveno se zavázat. Zjistil jsem, že tato praxe funguje pro mě.

0
Nickz