I really really disagree. If the branch has one logical commit then no merge commit is needed. Otherwise the merge commit shows what happened and more importantly that these N commits came into the mainline as a single change.
And I'm not cherry-picking... I usually see much, much worse git logs than this from merge-commit users. In fact, if I scroll down, this is what it looks like:
Edit: For a point of comparison, here's one of my projects using atomic commits and rebases:
My projects also have a linear progression. They look like...
* -- Bugfix
* -- Feature B
| \
| * -- Implement some other logical part of feature B
| * -- Implement first logical part feature B
| /
* -- Feature Agit log --first-parent
With that switch and writing correct merge-commit messages you get the best of both approaches.
That doesn't mean using merge-commits is wrong, that means people write bad commit messages, which you already complained about.
I fear you may be terribly misunderstanding the point of atomic commits and readable commit messages. Everything within a merge commit will still come up during a bisect, for example. If the commits are non-atomic and/or they are badly written, that is still an issue.
--first-parent hides the problem, and adds a new one. I'm not sure what your thinking is. Once again, what's more readable to you of all the screenshots I linked?
#!/bin/bash
bad=$(git rev-parse "$1")
good=$(git rev-parse "${@:2}")
git bisect start "$bad" $good
filter=$(echo "$good" | sed 's/^/^/' | cat <(echo "$bad") - | xargs)
comm -13 \
<(git rev-list --first-parent $filter | sort) \
<(git rev-list $filter | sort) \
| xargs git bisect skip
For anyone unfamiliar with git extension scripts: You should be able to put it in an executable (`chmod +x`) file (say `git-bisect-branch`) in your $PATH to make it usable (`git bisect-branch $bad $good...`).
I suspect that if merge-commits hadnt been the default on github since forever, it wouldnt have so many proponents.
Do you have buy in from other team members for this?
Also what do you do if master needs to be merged back into develop? Do you really rebase develop and make everyone fiddle with all their feature branches?
You can see this in action here:
Feature branch is prefixed with issue number. eg. PROJ-1234-update-ui-to-do-something. That ensures that every commit is logged against an issue.
If you list --first-parent and show the list of merge commits, you see a list of features which were implemented into the dev branch.
If you need to drill down into lower level changes of a feature, you can look at the individual commits that were made in that branch.
That way merge commits are atomic commits of features, and commits in a branch are logical commits/steps for an individual feature.
And in answer to the original post - I try to make all commits have a message of what was the type of change, what the change was, and where it was. eg. "Added a clear button to reset all form elements on the update address page". The general rule is, you should be able to read the commit message and know exactly what was changed and where. Compared to "Added clear button".
Support from tooling also helps a lot, e.g. "checkout branch of issue XYZ".
1) Create a post-commit hook script that only allows commits into feature branches.
This prevents accidentally committing into the dev/master branches (it still allows merges).
2) Create a script file that all developers use to start / end features which handles all the branch creation, pushing and pulling. That way the process is standardised and you cant make a mistake.
eg.
* script startfeature abc123-this-is-new-feature
* script endfeature (this automatically picks up local open features)
The only time there is ever an issue is when the end-feature causes a conflict. This is solved by rebasing your local branch, fixing up any issues in your commmits and then ending it again.
You want both that goal and the individual tasks which achieved it to be visible.
I guess we have fundamental differences on how a tree should be structured. It's more of a DAG in your case, but I prefer to keep a tree a tree.
The only point I'm making essentially is that "the commit" is too granular to capture all the information you need about your work and its history. You need some kind of grouping mechanism as well. It doesn't have to be merge commits, necessarily. But as I understood it, your original argument was that "there is no need for anything higher level than a commit." But there clearly is imo.
> It doesn't have to be merge commits, necessarily.
I was thinking of a tagging strategy.