What is the safest way to rebase a public branch - i.e. to cause the least amount of pain for everyone using it? Or is there a better alternative?
My team are new to using git & I've been asked to help tidy up their repository. They have a master branch which is very out of date & all work is being done on a branch called dev, (with branches off of dev for each new feature).
We've just released FEATURE_X and work has just continued on the dev branch on work for FEATURE_Y. I plan to merge all commits on dev up to FEATURE_X into master. The FEATUREs are big software releases - there are thousands of commits in both dev & master.
My problem is what to do about the dev branch:
- Firstly I plan to merge dev up to the FEATURE_X commit into master, so the HEAD of master is at FEATURE_X.
- Then I would like to rebase dev onto master, so effectively dev's commit history will start at the commit after FEATURE_X was released. I think this will tidy up the history of dev, making it less unwieldy to work with & make for less of a headache when FEATURE_Y is completed and dev needs to be merged into master again. From what I can gather, it's also not ideal to carry on working on a branch after it has been merged?
However all the advice I can find says not to rebase a public branch. We've got multiple developers already actively working with the dev branch to implement features for RELEASE_Y.
This article http://git-scm.com/book/en/v2/Git-Branching-Rebasing suggests if you have to rebase a public branch, to let everyone know & to get them to use git pull --rebase Does anyone have experience using this or is trying to tidy up dev more hassle than it's worth?