(sorry more ramblings) If you don't rebase your working/feature branch, you don't care about communication (or your development is much more organized then mine).
If you stand up long standing branches, you must have large contribution teams with frequent support for your various releases, otherwise you're solving for a problem you don't have.
In the article it states that git flow doesn't use rebase, if you do no buddy will know. This thought that you can force someone to not do rebase is rediculous, but you can clearly enforce needing to rebase.
I was once on the camp that it didn't matter, rebase or merge, git will figure it out and combine changes. But I ended up in quality assurance and being able to clearly define what is change and why for each line of code is critical to a good review and understanding.
I take shortcuts, but if quality really is important, better orginizing or even eliminating the last 25 commits is worth it.
(sorry more ramblings) If you don't rebase your working/feature branch, you don't care about communication (or your development is much more organized then mine).
If you stand up long standing branches, you must have large contribution teams with frequent support for your various releases, otherwise you're solving for a problem you don't have.
In the article it states that git flow doesn't use rebase, if you do no buddy will know. This thought that you can force someone to not do rebase is rediculous, but you can clearly enforce needing to rebase.
I was once on the camp that it didn't matter, rebase or merge, git will figure it out and combine changes. But I ended up in quality assurance and being able to clearly define what is change and why for each line of code is critical to a good review and understanding.
I take shortcuts, but if quality really is important, better orginizing or even eliminating the last 25 commits is worth it.
quoteinvestigator.com/2012/04/28/s...