abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 17:00 | Zajímavý článek

Asociace pokročilých výpočetních systémů USENIX publikovala na svém YouTube kanálu videozáznamy online přednášek ze svých posledních konferencí. Doporučit lze například videozáznamy z USENIX Security '20 (29th USENIX Security Symposium) nebo videozáznamy z WOOT '20 (14th USENIX Workshop on Offensive Technologies). Ocenění nejlepší článek (Best Paper) na WOOT '20 získal článek BLESA: Spoofing Attacks against Reconnections in Bluetooth Low Energy.

Ladislav Hagara | Komentářů: 0
19.9. 15:55 | Bezpečnostní upozornění

Samba, svobodná implementace síťového protokolu SMB/CIFS, byla vydána ve verzích 4.12.7, 4.11.13 a 4.10.18. Řešena je bezpečnostní chyba CVE-2020-1472 v protokolu Netlogon (Zerologon). Microsoft ji ve svých produktech opravil 11. srpna. Jedná se o chybu s CVSS 9.8. Neautentizovaný útočník se může stát správcem domény.

Ladislav Hagara | Komentářů: 0
18.9. 16:22 | Nová verze

Byla vydána eRouška 2.0 pro Android a iOS. Nově využívá systém oznámení o možném kontaktu vyvinutý společnostmi Google a Apple. Zdrojové kódy eRoušky jsou k dispozici na GitHubu (Android, iOS).

Ladislav Hagara | Komentářů: 49
18.9. 15:33 | Humor

Máte na klávesnici málo kláves? Pomoci vám může 433% Keyboard [reddit, Wayback Machine].

Ladislav Hagara | Komentářů: 18
18.9. 13:33 | Komunita

Otevřená certifikační autorita Let’s Encrypt (Wikipedie) včera na svém blogu oznámila vydání 6 svých nových certifikátů: 1 kořenový, 4 mezilehlé a 1 křížově podepsaný. Kořenový certifikát ISRG Root X2 a mezilehlé E1 a E2 jsou již ECDSA místo RSA. Certifikační autorita Let’s Encrypt byla představena v listopadu 2014. První certifikát vydala přesně před pěti lety, v září 2015. Dnes jich denně vydává milion a půl.

Ladislav Hagara | Komentářů: 0
17.9. 23:11 | Komunita

Mozilla Corporation na svém blogu informuje, že ukončila služby Firefox Send a Firefox Notes. Mozilla Foundation na druhé straně představila rozšíření RegretsReporter. Jedná se o rozšíření pro Firefox a Chrome umožňující Mozillu informovat o doporučených videích na YouTube, jejíchž zhlédnutí uživatel lituje.

Ladislav Hagara | Komentářů: 34
17.9. 15:44 | Zajímavý článek

Společnost Nethemba informuje o již opravené kritické zranitelnosti v aplikaci Moje eZdravie na Slovensku. Kdokoli si mohl stáhnout informace o všech osobách testovaných na COVID-19 (jméno, příjmení, rodné číslo, telefonní číslo, místo pobytu, datum a výsledek odběru).

Ladislav Hagara | Komentářů: 43
17.9. 13:55 | Zajímavý software

GitHub CLI dospěl do verze 1.0.0. GitHub CLI umožňuje pracovat s GitHubem z příkazové řádky (gh issue list; gh pr status; gh release create; gh repo view; …).

Ladislav Hagara | Komentářů: 3
17.9. 09:00 | Nová verze

LabPlot (Wikipedie) je svobodná multiplatformní KDE aplikace pro interaktivní vytváření grafů a analýzu vědeckých dat. Téměř po roce vývoje byla vydána nová verze 2.8.

Ladislav Hagara | Komentářů: 0
17.9. 07:00 | Nová verze

Bylo vydáno Eclipse IDE 2020-09 aneb Eclipse 4.17. Představení novinek tohoto vývojového prostředí také na YouTube.

Ladislav Hagara | Komentářů: 0
Používáte aplikaci eRouška?
 (16%)
 (4%)
 (2%)
 (12%)
 (52%)
 (8%)
 (7%)
Celkem 356 hlasů
 Komentářů: 35, poslední včera 21:50
Rozcestník

Dotaz: Ako správne používať stable branch v git-e?

6.9. 13:29 rastos | skóre: 62 | blog: rastos
Ako správne používať stable branch v git-e?
Přečteno: 190×

Zistil som, že vlastne neviem používať git tak, ako by som potreboval :-( Chcem vyrobiť branch a do toho branch-u pridávať len bugfixy zatiaľ čo do master vetvy pôjdu aj bugfixy aj nové feature.

Graficky by to vyzeralo nejako takto:
       B1<-B2<-B3                      B3<-B4
      /                               /
...<-R1<-F1<-F2<-B1<-F3<-B2<-F4<-F5<-R2<-F6<-B3<-B4<-F7...
S tým, že:
- R1, R2 sú momenty, kedy bol urobený release nejakej verzie. Túto verziu dostane zákazník, a ďalej bude dostávať len bugfixy až kým nedostane novší release
- B1, B2, ... B4 sú bugfixy, ktoré majú v branch-i/branch-och aj v master
- F1, F2, ... F7 sú nové feature, ktoré sú commitnuté len v master branchi.

Nie je správne urobiť merge, pretože tým by sa mi do branch-u dostali aj feature, ktoré som commitol do master. To isté rebase.
Robiť cherrypick, mi nepríde vhodné, pretože jeden bugfix môže pozostávať z viacerých commitov, ktoré možno ani nemusia ísť po sebe.

Tak ako to vlastne robiť správne?

Odpovědi

6.9. 14:48 Bherzet | skóre: 17 | blog: Bherzetův blog
Rozbalit Rozbalit vše Re: Ako správne používať stable branch v git-e?
Bugfix stejného problému může v různých verzích vypadat jinak, takže to žádné hezké řešení nemá. Prostě mít větev pro master a pak pro každou verzi. Bugfixy se dělají v masteru a cherry-pickují do jednotlivých verzí (samozřejmě to musíš pokaždé znovu otestovat a případně upravit). Na větší bugfixy bych si radši dělal samostatnou větev a pak z ní udělal buď jeden commit, nebo jí mergnul.
xkucf03 avatar 6.9. 17:00 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Verzovací systémy a větve

On asi neexistuje jediný „správný“ systém. Když budeš hledat „git workflow“, tak najdeš řadu různých způsobů – každý to dělá trochu jinak.

Já tedy používám primárně Mercurial a následující systém:

  • Neexistuje žádná větev master/default/stable/devel ani nic podobného.
  • Používá se sémantické verzování.
  • Větve jsou pojmenované podle major verze tzn. třeba v_1, v_2 atd.
  • Vydané verze jsou označeny štítkem (tag) opět dle sémantického verzování, např. v2.0.0, v2.1.0 (tzn. štítky a větve se poznají i podle názvu – větve mají v názvu podtržítko, štítky ne).
  • Když se dělá oprava (hotfix, patch nebo jak tomu kdo říká), tak se z příslušného štítku (např. v2.1.0) odkloní nová větev (např. v_2.1) a v ní se vyvíjí a vydané opravy se označují štítkem typu v2.1.1, v2.1.2 atd.
  • Opravy se propagují vždy jedním směrem – nahoru – tzn. dělá se merge z větve v_2.1 do v_2, případně pak do v_2.2, v_3, v_3.1 atd. (pokud existují).
  • Pokud se má dostat nějaká nová funkcionalita do starších větví (backport), tak to jde přes cherry-pick. Běžné verzovací systémy to bohužel líp neumí, ale naštěstí to není moc časté.
  • Historie je posvátná a nesmí se nikdy měnit. Vždy bychom měli být schopní reprodukovat stav ke kterémukoli bodu v minulosti (proto mám taky radši Mercurial než Git). Tohle pravidlo samozřejmě neplatí pro privátní větve jednotlivých vývojářů – tam se běžně dělá rebase, amend nebo libovolné jiné úpravy historie.
  • Zda vyvíjet každou funkcionalitu v samostatné větvi (feature branch) je ortogonální otázka a nesouvisí se systémem popsaným výše – tahle větev se prostě odkloní z jiné větve, do které pak změna přijde, případně se chvíli udržuje bokem, dá se přesadit jinam… Obecně považuji za nejlepší vyvíjet každý požadavek (označen číslem z Bugzilly nebo podobného systému) v samostatné větvi. Pak už je ze samotných větví vidět, na základě jakého požadavku byla daná změna provedena. Nicméně někdy je to zbytečně byrokratické, takže je na zvážení, zda to tak dělat vždy nebo jen u větších zásahů do kódu.
  • Problém nastává asi jen v případě, kdy je vývoj veden trochu chaoticky a nejdřív se zadá nějaká práce a pak se na poslední chvíli rozhodne, že se to odloží a dá až do příští verze. Tenhle problém ale není specifický pro systém popsaný výše. Úpravy se pak musí buď revertovat a aplikovat znova v jiné větvi. Nebo se tomu dá přecházet tím, že sadu změn udržujeme v samostatné větvi (viz předchozí bod).
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.