4 ms·
After being initially skeptical I was convinced by a colleague that this is a good model. The merge commit acts as a kind of "pushlog"; it tells you what actua
by jgraham 10y ago
After being initially skeptical I was convinced by a colleague that this is a good model.
The merge commit acts as a kind of "pushlog"; it tells you what actually landed together as a single unit. It probably also tells you what passed CI; although many projects state that you shouldn't have individual commits that don't pass CI it's rare that this is enforced below the level of the PR. That should be good for bisection. Because the commits are always rebased onto master (and of course you never allow merge commits other than from code being integrated into master) your history is relatively clean, you don't get multiple overlapping branches, but something like
M1 ------- M2 -------- M3
\ B1 - B2 / \ C1 - C2 /
Because the merges are --ff-only you don't get the confusing situation where the merge commits themselves contain changes.
In principle this seems like the ideal way to use the tools git provides. However I understand there are some minor rough edges e.g. with magic needed to tell git bisect how to only try the merge commits.
- rdtsc 10y agoYeah, looking at the commit history tree visually convinced me. Then was convinced even more after having to revert a ff merge.
- lmm 10y ago> your history is relatively clean, you don't get multiple overlapping branches Right, but what's the benefit of that? You still need to understand a history with merges in, in which case it seems like you might as well get the safety advantages of not rebasing.
- wanderr 10y agowhat are the safety advantages?
- lmm 10y agoRebasing tends to induce more conflicts than merging, tends to lead to force-pushing which is often dangerous ( "--force-with-lease" is safer but a lot longer than "-f" ), and has to be done after PR review which bypasses one set of checks particularly in the case where conflicts have to be fixed.
- wanderr 10y agopresumably github will only let you rebase-merge if there are no conflicts. In my experience though rebase tends to have more conflicts requiring manual intervention vs merge, but that feels safer to me than merge occasionally automatically resolving the conflict incorrectly. Github also has protection to prevent branches from being forced, if you are only forcing a feature branch with no collaborators, or at the end of collaboration, it's not so bad, especially when git tells you the old hash you just overwrote and you have the reflog, but again github's rebase-then-merge should make that a non issue.
- optforfon 10y agoI really like this workflow, but my major grip is that the autogenerated merge commits are terribly ugly and uninformative. I'm sure you can override them, but no one seems to every do it. The workflow is awesome at visually segregating your logically separate pieces of work, but you never actually end up giving it a proper label like "Added feature" (which took a refactor and 10 commits)