Rebase and Merge

[jamesaorson]

Why are we using merge commits instead of rebase and merge? I have found that rebase and merge makes a much cleaner commit history and makes merge conflicts much easier to fix.

[micahswitzer]

The general strategy I was working off of was: once your PR is approved, you rebase on the target branch to ensure you have incorporated the most recent changes and resolved any conflicts that might exist. You then would be able to cleanly merge the changes in.

I'm not sure if this is what you were suggesting or not, but I like to keep the single merge to show where changes were brought in to the main branch.

[Kfeavel]

I agree with this. I like the distinction that an actual merge provides, but all branches should be rebased on top of dev or whatever branch is appropriate before it is merged in.

[jamesaorson]

Gotcha. What I do to maintain distinction is making every commit be prefixed with the issue number, like so 123: Some changes, so you can grep for all commits related to an issue.

[Kfeavel]

That's not a bad idea, but I already struggle with making my messages fit within the 50 character limit, lol.

[micahswitzer]

That's why commits can span multiple lines. The issue number could really appear anywhere in the message.

[Kfeavel]

Fair enough -- I have no problem with doing that from here on out. I do think rebasing and then merging is still the way to go though.