Re:When hiring developers, have the candidate read existing ...
by bornfreddy on Sunday April 17, 2022 @04:24AM
(#31059419)
I think this is the crucial thing. Commits help with code reviews and they give hints about why some code change happened.
Re:When hiring developers, have the candidate read existing ...
by ithkuil on Sunday April 17, 2022 @05:08AM
(#31059561)
Do you enforce the presence of merge commits, i.e. no-ff?
Re:When hiring developers, have the candidate read existing ...
by NateEag on Monday April 18, 2022 @10:29AM
(#31071121)
If I'm enforcing any of this, then I enforce that, yes.
All of these constraints can be enforced programmatically, and if you're going to adopt them at all I think automating them is the way to do it.
Personally, whether I enforce this branching strategy varies from team to team and project to project.
Many projects I've been on had much, much bigger issues to deal with, so something second-order like this never gets to the top of the stack.
That said, it's an approach I like, and I think it yields benefits if you have a team that's bought into it.
• All commits SHOULD pass all CI tests
• Merge commits MUST pass all CI tests
The reason I don't require every commit to pass all tests is to maximize reviewability and logical consistency of commits.
For example, if a file needs to move, and then be modified slightly to function in its new location, I prefer to break that into two commits:
1. A verbatim move operation. This commit will fail CI but can be effortlessly reviewed.
2. Small modifications. This commit will pass CI, and its reviewability is proportional to its size.
In contrast, if you smush those two commits together, it can be hard to see where the meaningful changes occur in one giant diff. (Some tools may be smarter about showing a minimal diff for a move-and-modify commit under limited circumstances, but that doesn't always work.)