Do y'all prefer rebase or merging workflows? I still don't understand the difference.

I prefer standard merging to see more granular detail of the history of individual commits. I also work on a small team though, so there's that.

Here's a good explanation of the differences between the two: https://quora.com/What-is-the-diffe...

@duckWit *a small team that makes sensible commit messages

@jeeper indeed. It's a rule for us that every commit links to an issue ticket.

If you don't understand the difference, then merge only.

Rebase dangerously re-writes history, and if you don't know when it's safe or unsafe to do so it's gonna bite you on the ass

@jsMonkey I know how to use rebase for a few things, but not for merging branches together

Rebase to catch up with master and deal with conflicts before merging.

Merging to merge after rebase.

merge after rebase to not clutter the history with "merge commit"s.

Actually this is what you must do if you are working on a project with more than 2 developers and base the work flow on pull requests. Otherwise your history will got FUBAR.

@Yamakuzure I knew there was something wrong with the way I'm using git, it just didn't feel right!

@Krokoklemme There are many possible git work flows. The only challange is to choose the right one and then stick to it.

Maybe of some interest:

https://git-scm.com/book/en/...