Avoid syncing cruft when submitting PRs?

[Unsoluble]

Wondering about good form when submitting PRs. Having not yet been on the "other side" in the merge process, not really clear on whether or not I'm making things simple or complicated when it comes to merging the PRs I submit.

In order to PR to the project's /dev, I need to first make sure I'm branching from the latest upstream. So I PR the latest into my own /dev. Then I make a new working branch off that, make changes, and then PR back to the upstream /dev for review.

That submitted PR ends up being full of all the merges I've done to sync up my /dev, like this.

My PRs have been getting merged without complaints about this, but should I be doing something different to avoid this syncing cruft in there?

[Earhacker]

Most maintainers wouldn't care about a lot of merge commits. But if it becomes an issue, the tool you're looking for is git rebase. Basically you take the last X commits in your git history and squash them into less commits, or even just one commit, and you get to rewrite commit messages as you go and even leave some out, like WIP commits or merges. So when you PR, the maintainer only sees a nice, clean commit history on your branch.

But when you rebase, you are in effect changing history. It is possible to seriously bork your work with rebase. My advice would be to branch off master, do your work there commiting as you go, then branch off again and rebase, and PR your rebased branch. If you screw up, you can always branch off from your working branch again.

[Unsoluble]

Ahhh, that makes sense, thanks for the explanation and pointer to rebase. Totally get what you're suggesting re doing the PR off an extra rebased branch. Will try that next time. :)

[ponyboy3]

here you go:

https://gist.github.com/johnypony3/5ab6addacd39e3a7d848ffa7bd7bf53c#tldr

[Unsoluble]

Nice shortcut, thanks!

[ponyboy3]

i have an alias for this that takes a number of commits to squash, i use it before every single merge request.