[VCS] Hoe reden van wijziging zien?

[Daos]

Wij werken met git en het ticket-systeem jira. Voor elke bug/feature maken wij een aparte branch die dan los getest kan worden. Wij geven die branches de naam: {developer}/{ticket-nummer}. Na testen wordt alles weer gemerged in de master-branch. Dit gaat allemaal goed.

Nu wil je soms de reden weten van een stukje code. Als eenmaal de code in de master-branch zit, dan lukt het (mij) niet om snel de oorspronkelijke branch en daarmee het ticket-nummer te vinden.

Een collega heeft daarom als gewoonte om in de code steeds als commentaar het ticket-nummer te zetten. Ik vind dit lelijk.

Zelf ben ik voorstander van het ticket-nummer in de commit te zetten. Als je dan blame doet, dan zie je naast de persoon direct het ticket-nummer waar je dan meer informatie kan vinden.

Enig alternatief dat ik kan bedenken is de reden zelf als commentaar in de code te zetten. Maar soms zijn er hele discussies in het ticket en om dat allemaal in de code te zetten lijkt mij ook niet handig.

Hoe denken jullie hierover?

Poll: Waar reden wijziging
• Ticket als commentaar in de code
• Ticket in commit
• Beschrijving in code
• Anders...
<sup>Tussenstand:

Ook een poll maken? Klik hier</sup>

[Radiant]

Ticketnummer in de commit-message is redelijk gebruikelijk volgens mij, dat doen wij ook. Voordeel hiervan is ook dat als je version control integration gebruikt in Jira dat je wijzigingen te zien zijn bij de ticket.

In de code zou een zooi worden..

[ Voor 7% gewijzigd door Radiant op 27-01-2017 12:27 ]

[Daos]

Radiant schreef op vrijdag 27 januari 2017 @ 12:27:
version control integration gebruikt in Jira

Dat klinkt best handig. Heb ik van het weekend iets om te onderzoeken.

[Tsunami]

Precies dat, discussies horen in het ticket thuis, en wat er daadwerkelijk gedaan is in de commit message. Met het ticket nummer in de commit message en goede integratie in JIRA link je ze aan elkaar, zodat je altijd de redenering achter een stuk code kan teruglezen. Met een goede IDE kan je zelfs op het ticket nummer in de commit message klikken om het ticket te openen in JIRA.

[ Voor 16% gewijzigd door Tsunami op 27-01-2017 12:49 ]

[jbdeiman]

Wij zetten hier het ticketnummer met een (korte) beschrijving (eigenlijk titel) in de commit message.

Bijv:
RW-301 - ItemType X toegevoegd aan Y.

Dit zegt niet altijd precies wat je probeert te bekijken, maar geeft je wel een idee wat het doel van de gehele aanpassing is geweest. Waarom specifiek een stukje code is aangepast haal je er dan niet direct uit, maar de keren dat dat nodig is zijn er maar weinig.

En inderdaad: Integratie met Jira is heerlijk, je ziet in je commit welke melding het was, maar ook in je melding welke commit het was. Je kan (weet niet zeker of dat met of zonder uitbreidig is) ook vrij eenvoudig een commit terugvinden.

[LinuX-TUX]

Shit, ik wilde 'ticket in commit' klikken, heb per ongeluk de poll gesaboteerd, excuses.

Voordeel van de ticket in de commit message is dat jira middels een git plugin ook bij kan en zelfs de changesets kan weergeven per ticket.

Andersom kunnen de meeste IDE's wel annotations laten zien (git blame) en dan kan je middels de commit ID filteren van welke branch deze af kwam. Dit geld alleen als je alle branches lokaal hebt EN deze niet weggegooid zijn.
Voorbeeldje:

Bash:

tux@laptop ~/work/verybigrepo $ git log
commit 684ec6e4850b8bcdea187cea123e8b0c944115ff
........
tux@laptop ~/work/verybigrepo $ git branch --contains 684ec6e
* developer
tux@laptop ~/work/verybigrepo $ 

Als ik het me goed herinner kan deze soms weleens wat missen (bij een geresolvede merge conflict commit dacht ik dat je hem dan niet zou zien, weet ik niet zeker).

[ Voor 5% gewijzigd door LinuX-TUX op 27-01-2017 12:59 ]

[NMe]

Veel diensten à la Github en Gitlab kunnen ook commit messages uitlezen en op basis daarvan tickets sluiten. Wij werken op kantoor met Gitlab, en als ik daar een commitbericht tik zoals het volgende, dan wordt het bijbehorende ticket 123 meteen gesloten:

Add new feature X

Hier een langere omschrijving van wat het inhoudt.

Fixes #123

Jira doet hetzelfde volgens mij, en in al deze tools kun je ook terugzien welke commits er bij een ticket zijn komen kijken.

[ Voor 15% gewijzigd door NMe op 27-01-2017 13:07 ]

[Hephaestos]

Eens met hierboven, ticket in de commits, jira (fisheye/crucible) de branches laten monitoren.

Zodra je dan op een ticket commit (en pushed), pakt crucible deze op, geeft Jira een duw, en zie je in de Jira ticket de commit verschijnen. Van daar kan je dan direct een code review aanmaken.

Tegen argumenten voor de rest:
Ticket ID in de code gaat over een jaar na wat refactoren, nieuwe features etc niet meer bijgehouden worden (of wel, maar dat kost weer maintenance tijd die je liever niet aan zo iets wilt spenderen voor jaren op rij)

Beschrijving in code kan altijd maar zou sowieso los staan van Jira/ticket, dus gewoon code documentatie. Geen discussies of andere onzin, daar is Jira voor.

[ Voor 41% gewijzigd door Hephaestos op 27-01-2017 14:30 ]

[Spinal]

Wij doen ook ticketnummer in commit. In onze testsuite zetten we soms wél het ticketnummer in de code, bijvoorbeeld

code:

frisby.create('Filter by "referentie" (Bug #2585)')

[RobIII]

Lang leve VS codelens + TFS (volgens mij werkt 't ook met GitLab).



Best of all worlds. De workitems & commits gewoon "bij je code" zonder dat ze in je code staan.

[ Voor 10% gewijzigd door RobIII op 27-01-2017 15:23 ]

[Creepy]

Ticket id + wat je hebt gewijzigd in commit inderdaad. En zoals al gezegd wordt pakt o.a. Jira dat ook direct op zodat je git commits ook direct bij je tickets zichtbaar zijn. En in je ticket het waarom etc.

[ Voor 15% gewijzigd door Creepy op 27-01-2017 15:35 ]

[Swedish Clown]

Ticket in de commit. Dit in combinatie met git-hooks die automatisch de ticket uit je branch halen en prefixen in the commit. De conventie bij voor de branches is: ticket-team-description, dit maakt het extreem gemakkelijk voor de git hooks om hier op in te haken

[Hydra]

Daos schreef op vrijdag 27 januari 2017 @ 12:19:
Een collega heeft daarom als gewoonte om in de code steeds als commentaar het ticket-nummer te zetten. Ik vind dit lelijk.

Medunkt. Code commentaar moet over de code gaan, niet over een ticketing systeem.

Zelf ben ik voorstander van het ticket-nummer in de commit te zetten. Als je dan blame doet, dan zie je naast de persoon direct het ticket-nummer waar je dan meer informatie kan vinden.

Dat is hoe wij het doen en ik zie ditzelfde in veel projecten op die manier gedaan worden. Zo kan je altijd terugvinden bij welk issue een commit hoorde.

Ik heb een git hook gemaakt die zelf de branch naam toevoegt aan een commit dus dan hoef je er zelf nieteens aan te denken.

[Tarkin]

Wij kunnen enkel iets inchecken in Git als we een (correct) ticketnr hebben.

We kunnen bv enkel op project a inchecken met A-xxxx en niet met de key van project b (B-xxxx)

[Daos]

Bedankt voor de reacties mensen. Ik heb weer een hoop nieuwe ideeën opgedaan. En ik hoop natuurlijk ook dat ik hiermee mijn collega kan overtuigen om het ticket-nummer niet meer in de code te zetten.

LinuX-TUX schreef op vrijdag 27 januari 2017 @ 12:56:
Shit, ik wilde 'ticket in commit' klikken, heb per ongeluk de poll gesaboteerd, excuses.

[jip_86]

Hier nog een die mistikte. Zat er net naast op de mobiel.

Had dus ook ticket in de commit willen kiezen. Met TFS kun je de annotate dan gebruiken om te kijken waar het voor was.

[Kwistnix]

Yep, ticket nummer in de commit. Sowieso hebben wij redelijk stricte guidelines voor Git commit messages die gepushed worden. Die worden volgens mij redelijk veel toegepast. Onderwerpregel max. 50 karakters lang (begint bij ons met het ticket nummer), dan een lege regel, dan een uitvoerige(re) beschrijving van wat er gedaan is en zo nodig waarom, waarbij line wrapping op 72 karakters plaatsvindt. We gebruiken daarbij veel interactive rebasing van lokale commits, om "oops, vergeten" commits / messages weg te halen met een re-order en squash of fixup. Het vereist even wat discipline, maar je houdt er wel een nuttige log aan over die bij het reviewen al direct waardevol is.

[ShitHappens]

Hier ook commit message voorzien van het ticketnummer. Gaat dan om een samenwerking van JIRA en BitBucket. Daarnaast ook het ticketnummer in de naam van een branch.
Daar haal je inderdaad de voordelen uit dat JIRA laat zien bij het ticket hoeveel commits er zijn geweest en welke. Omdat voor 1 ticket vaak meerdere commits kunnen gebeuren, is de commitmessage dan ook de plek om kort aan te geven wat er gebeurd is.
Maar ook:
- Zodra een branch wordt aangemaakt met een ticketnummer in de naam, gaat deze in JIRA automatisch naar "In progress"
- Zodra een code review wordt aangevraagd, in JIRA naar "Code review"
- Zodra deze goedgekeurd is, in JIRA naar "Done"

[LinuX-TUX]

Daos schreef op vrijdag 27 januari 2017 @ 18:43:
Bedankt voor de reacties mensen. Ik heb weer een hoop nieuwe ideeën opgedaan. En ik hoop natuurlijk ook dat ik hiermee mijn collega kan overtuigen om het ticket-nummer niet meer in de code te zetten.


[...]

Sorry ... ik was niet de enige ...

jip_86 schreef op zaterdag 28 januari 2017 @ 10:55:
Hier nog een die mistikte. Zat er net naast op de mobiel.

Had dus ook ticket in de commit willen kiezen. Met TFS kun je de annotate dan gebruiken om te kijken waar het voor was.

Maar bericht is toch duidelijk zo, ticket in commit message it is ?

Kan je zelfs op de regel code middels git blame / annotations in IDE's terug traceren waar het vandaan kwam ... HEER-LIJK

[ Voor 8% gewijzigd door LinuX-TUX op 29-01-2017 00:51 ]

[mcDavid]

Los van dat het handig om beschrijvende commitmessages evt met ticket nummer te hebben, als een stuk code uitleg behoeft over wat het doet of waarom, dan hoort dat wat mij betreft óók gewoon in een commentaar bij die code zelf.

Het liefst heb je dat soort code natuurlijk helemaal niet, maargoed we wonen nu eenmaal niet in Utopia.

[MSalters]

Wij hebben naast Jira ook Fisheye & Crucible draaien, en die integreren met Jira. Fisheye scant alle Git commits, en zoekt daarin naar ticket ID's. Niet alleen kun je de commit linken aan het issue, je kunt met een hashtag ook meteen een issue transition doen. (Typisch naar #test, maar als je testresultaten ook in Git bewaart dan kun je die met #resolve committen)

https://confluence.atlass...rt-commits-298976812.html

[Mercatres]

mcDavid schreef op zondag 29 januari 2017 @ 01:13:
Los van dat het handig om beschrijvende commitmessages evt met ticket nummer te hebben, als een stuk code uitleg behoeft over wat het doet of waarom, dan hoort dat wat mij betreft óók gewoon in een commentaar bij die code zelf.

Het liefst heb je dat soort code natuurlijk helemaal niet, maargoed we wonen nu eenmaal niet in Utopia.

Dit.
Soms dekt je code een heel functioneel iets af, en kan je niet meteen verwijzen naar een spec, dus schrijf je het in commentaar.
Verder ook: TicketId + Beschrijving van commit in commit message. Ook automagische transitions in JIRA, van de backlog tot aan de Done.