3 ms·
In my experience these assertions are untrue. Also the tickets are often the over arching context and will have nothing to do with the code. My product owner do
by sirsuki 9y ago
In my experience these assertions are untrue. Also the tickets are often the over arching context and will have nothing to do with the code. My product owner doesn't care if I had to try three different algorithms till I got it right; but my colleagues and my future self sure would love to see that and all the stack overflow links during a git bisect!
Not only that but the ticket is a full feature. Maybe it took 5 commits to get there: "Fix bad indenting", "Extract base logic to command object", "Update I18N entries", "Add missing tests for current behavior", "Add the feature asked for".
- ozim 9y agoFrom what I see you just agree with my comment. Those 5 commits you described as example are the way I would do it. The way it is described in article would make you do it in one commit and add information that would be in the ticket.
- deiwin 9y agoWhat makes you say that? The Focused rule from the article is also meant to persuade you to split the work into similarly concise and focused commits.
- ozim 9y agoFocused and complete are opposite. You can have focused commits or complete commits.
- deiwin 9y agoAlso, the ticket and the commits can provide answers to the same questions without being redundant. The answers are just at a different level of abstraction and for different readers. Tickets usually describe product-level decisions, while commits describe implementation-specific details. E.g. a ticket may discuss alternative user flows, while a related commit explains why a specific algorithm, module, or default configuration value was used.