Simple rebase/merge workflow and how to deal with possible merge conflicts.
So you're building a feature on a feature branch called
some-feature-branch, it takes you, say, 3 days to finish it. While you were busy building your feature, your co worker merged his/hers feature to
master, so there's new stuff in master that you need to somehow get to your branch. Handy way of doing that is to
rebase the changes to
some-feature-branch before merging
Here's how that workflow goes.
$ git checkout master # Pull in the new stuff $ git pull origin master # Checkout your feature and rebase master to it $ git checkout some-feature-branch $ git rebase master
Next, Git will try to move the new commits in
master to the tip of your
some-feature-branch. Here's what might happen:
$ git add <file-name>or in one clump
$ git add -A.
$ git rebase --continue.
dist/ directory (or build, or whatever you named it) that are generated automatically by a build task, like Sass or r.js. You can exclude the whole
dist dir from the repo, but if you're like me, and use Git to deploy the project also, that's not doable.
I haven't really found a good solution to this, other than just ignoring them by blindly adding all files in
dist and continue with the rebase. Then, of course, run the build script after the
rebase is done.
$ git add dist/
$ git rebase --continue
Now there's tons of merge conflicts in your
dist/*.js files and that's why you need to run your build task again.
We're done with the rebasing, great! Lets look at merging the feature branch to master.
This should be a cakewalk now, since we just resolved all the merge conflicts, all you need to do is:
$ git checkout master $ git rebase some-feature-branch ## Conclusions If you're interested I have a more [detailed article about rebasing and merging](/git-dealing-with-branches-merging-and-rebasing).
Comments would go here, but the commenting system isn’t ready yet, sorry. Tweet me @hiljaa if you want to make a correction etc.