Strategies of merging master
So if I’m working in a branch, let’s call it
feature-foo, that was initially based of
master. And I’m continuously adding many commits to it.
At that same time, my colleague is working on a
feature-baz, decides to merge it his branch into master.
- Git: Putting local directory under revision control
- GitHub to Heroku Commit Error
- Is there some kind of 'git rebase --dry-run', which would notify me of conflicts in advance?
- git-svn stops with no error message when trying to clone
- When subproject is a subtree merge, how do I revert a commit that came from the subtree remote?
- Visual Studio 2013 slows down + crashes when using Source Control features
Then we find out that
feature-foodepends on certain changes that now currently in master. I would merge master into my
feature-foobranch and continue building
At some point I’m ready to merge it back to master, but then my colleagues already merged some other changes to master and now I have conflicts, and can’t easily merge my
It seems it’s easier to resolve conflicts if instead of merging master into
feature-fooI would start a new branch off of master and then merge
feature-foointo that branch. So, I would create
feature-foo-2(basing it off of current master) and then merge
feature-foo-2, and fix conflicts on the way.
And now, my
feature-2branch is conflicts free and ready to be merged to master.
So my question is: maybe I’m doing something wrong? Is there an easier way to handle that all?
What is the best way of dealing with changing master?
Should I always try to rebase and squash commits before merging any other branches into mine? Because apparently it’s not recommended to squash commits after you merge things from other branches.
We’re not using git-flow. As I understand it – I can’t use it for my own benefit, entire group has to agree to use it, right?
What are your thoughts?
upd: Of course I forgot to mention that I can’t push into orgin/master (that’s how our github repo configured). Any merges to master should go through pull requests.
So you see, that even if I make something small in my local branch, in order to have a PR accepted, I would have to merge/rebase master onto it. But master by that time could already have way more and in reality it makes it simpler to rebase/merge my branch into master (rather than other way around). But since I can’t push master to origin, I have to create a temporary branch (based off of master) and then merge/rebase my changes onto that, and create a PR based on that temporary branch.
One Solution collect form web for “Strategies of merging master”
If the features are small enough, I’d opt to rebase and merge with the “no fast-forward” (–no-ff) option when its time to check in. It is a matter of preference – I prefer to keep master clean by ensuring that there are no overlapping branches.
FYI, to visualize your tree and all your branches:
git log --oneline --graph --all --decorate=short