I'm comfortable git fooing w/e is necessary, but ever since we adopted this, git related conversations went to almost zero. It's great.
The notable features are: - Move commits up and down, fixup, drop - Rename commits from the editor (without having to stop for a reword during the rebase run) - Visualize modified files along commits - 'Explode' a commit ,creating a commit for each modified file (a thing I found myself doing quite often)
Feedbacks (both on the tool and the code) and contributions welcome, hope it could fit other people needs too !
I'm comfortable git fooing w/e is necessary, but ever since we adopted this, git related conversations went to almost zero. It's great.
The PR is the unit of work, people get too hung up on the PR's individual commits.
Worst: rebase and merge - you end up with your coworker's broken WIP commits all over master, and have a terrible git revert story
OK: merge commit - you can revert, but there is a less intuitive `-m 1` flag (IIRC?) you have to pass into revert, and IMO you rarely need the intermediate history.
Best: squash & merge - you get one single commit representing the unit of work merging in, git revert is dead easy
Also setting the commit message in main to the `{title} (#{prNum})\n\n{prDescription}` format preserves all the good context from your PR and lets you get back to it if you need.
Commit history on a (larger?) PR tends to be most useful during the PR itself; I tend try and make my commits tell a story I can walk people through (on the CLI during a call) moreso than anything that will be useful in 6mo/year.
I've been convinced on Squash/Merge. If the PR needs more granular commits; maybe it should be 2 independent PRs.
We constantly use that on the OSS project I’m occasionally involved with. “Well why is it like that…” and the project has enforced a good history so this can often be answered.
And that’s the primary benefit of Git. With some discipline the history becomes legible.
On the other hand it doesn’t give you much out of the box for code review. Unless the code review you use is covered by the email tooling.
With Git you can work in, well, at least twelve different ways. But people discuss workflows with some built-in assumption that of course everyone else is using it like they are.
FWIW for individual repos I don't even use PRs so the whole issue of how to merge them is moot.
The point? You’re not making sense.
This is a discussion. This is not your team pow-wow where the boss makes a show of hearing everyone out and then going with what he decided with beforehand. Or whatever your process is.
This right here is a discussion. It makes no sense to pull the “we all wear leotards because that’s the team policy”. That’s not an argument that I can recognize.
You should, in a discussion, make where you come from clear. If three comments in on the topic of X you say “but of course we use Y, how dare you suggest something else than Y?” then you’re not having an argument any more.