"to keep the repository clean"
Seems like not a worthy objective. Has anyone here ever had a project saved by a tidy commit history?
Seems like not a worthy objective. Has anyone here ever had a project saved by a tidy commit history?
Commit d
Parent a b
Merge branch origin/mainline into mainline
Commit c
Parent a
Something they did
Commit b
Parent a
Something I did
Commit aI have introduced git and hg to many people, but I've always tried to tie it into what people do already. Without source control, practically everybody did the same thing: They'd work a little bit, they'd save, they'd work a little bit, they'd save... etc. Using branching for organizing work and a nice cheat-sheet of a few git commands, most non-technical people will be off-and-running.
It all works until the programmers make it complicated with the rebasing. The price of the tidy commit history is the loss of confidence of the rest of the team. I'd rather have the people.
Case in point: https://vimeo.com/60788996
When it's ok: You are working on your own line and the commits you've made are not in a central repo.
Why: Git commits are a hash tree and when you change one commit it changes all the SHAs that come after it. This makes git see your commits pushed remote as different then the ones that are local. The commits have the same changes so it puts duplicate conflict markers everywhere.
Most people love it once they realize how it works.
A lot of people use version control also as a backup in case their hard drive fails. Because of this they are scared of staying on a topic branch for very long, so they push then rebase often leading to conflicts which are scary.
Frankly if I "git log -p" and your diffs aren't clean and to the point, that's a code smell (maybe a developer smell?). If you are sloppy and inattentive in your commits, that probably carries over to your code as well. There's more to the code than just the latest version--history is important.
I have worked on two UI-heavy iOS apps, and code reviews are very effective in comparison to the automated testing we have. github & bitbucket make it easy see a linear stream of commits and discuss individual lines.
This all falls apart when a programmer takes a day to implement a feature, and then pushes it along with a merge commit that can only be reviewed by manual diffing on the command line (and I have found regressions that way).