8 ms·
I use almost exactly this workflow with rclone. This bit resonated particularly: begin quote Never merge with GitHub! There’s a button GitHub that says “reb
by nickcw 6y ago
I use almost exactly this workflow with rclone.
This bit resonated particularly:
begin quote
Never merge with GitHub!
There’s a button GitHub that says “rebase and merge” that could theoretically be used for merging pull requests. I never use that (and if I could, I’d disable/hide it). The reasons are simply:
I don’t feel that I have the proper control of the commit message(s)
I can’t select to squash a subset of the commits, only all or nothing
I often want to cleanup the author parts too before push, which the UI doesn’t allow
end quote
Not being able to selectively squash and edit the multiple commit messages is a big missing feature in my workflow.
- secondcoming 6y agoPersonally, I always merge with Github. Never had an issue, and never had concerns about non-linear commit history. So much is made about commit history that I think there are flaws elsewhere in other people's processes, or people are just getting off on their git-fu. But this comment will just descend into a dull, tedious flame war. I don't care. git merge is totally fine.
- scrollaway 6y agoI use the rebase and merge button when the author has clean commits. Otherwise yeah.
- azangru 6y agoWe do squash-and-merge for PRs. Works great so far. A minimal unit of change is thus not a single commit in a PR, but the whole diff introduced with a PR.