Four rules for effective collaboration – Guidelines for better commits

Re:Four rules for effective collaboration – Guidelines for b... by ozim on Wednesday March 07, 2018 @04:28PM (#16540068)

From 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.

[ Parent | on HN ]

Re:Four rules for effective collaboration – Guidelines for b... by deiwin on Thursday March 08, 2018 @12:26AM (#16542499)

Also, 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.

[ Parent | on HN ]

Re:Four rules for effective collaboration – Guidelines for b... by deiwin on Wednesday March 07, 2018 @04:49PM (#16540244)

What 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.

[ Parent | on HN ]

Re:Four rules for effective collaboration – Guidelines for b... by ozim on Thursday March 08, 2018 @02:34AM (#16542943)

Focused and complete are opposite. You can have focused commits or complete commits.

[ Parent | on HN ]