
Ask HN: Rebase or merge Git strategy? - ko3us
I&#x27;ve been discussing with several people about how I should structure internal project. We currently employed the standard merge approach for git (setup gitflow) and it&#x27;s ok. But we have several issues with release. 
Everytime people are writing on features and doing a MR into the develop or master branches or release takes for ever because we are spending time fixing merge conflicts.<p>A friend of mine suggested we change to a rebase strategy. Where instead of the conflicts happening at the time of release (develop or master) the conflicts are undertaken by the developer doing the feature before and after they do their work, essentially ensuring that release is always working.<p>What are your thoughts? Rebase or merge strategy and why?
======
hummingn3rd
Hi, using git flow I would be more in favor for the rebase strategy, I think
conflict resolving should be the responsibility of the developer adding the
feature. It's part of the cost of developing it. However, it is essential to
rebase all the time and do non breaking and microcommits, I suggest doing a
rebase many times a day to handle conflicts a little at a time. Moreover, a
feature branch should merge with the dev branch and not last more than three
days at most to mutualize code and sharing value. This should prevent never
ending conflicts

------
weliketocode
Is your team quite inexperienced with git, or is there anything inherently
unusual about the project?

If the team is spending a lot of time dealing with merge conflicts, merging vs
rebasing isn't the problem.

More than likely, one or more of the following are issues:

\- Too many people are making changes in parallel to the same file

\- Everyone isn't consistently keeping their `dev` branch up-to-date

\- Developers aren't taking the time to first merge dev into their feature
branch and fix any merge conflicts before submitting a pull request

\- Pull requests aren't being properly reviewed (no approvals until merge
conflict addressed)

