Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
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...
jeeper58994y@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.
jsMonkey5724yIf 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:
Do y'all prefer rebase or merging workflows? I still don't understand the difference.