0

I know this answer might have been answered a million times before but each situation is different and I want to know what I'm doing wrong in my case. I'm very new to git so would appreciate an explanation.

I have a commit history like this: (Using SourceTree)

Screenshot of Source Tree

Currently all changes are being done locally. The blue line is develop branch, a release branch was previously created (Yellow) and later merged into master (pink) and that was all fine.

Then develop branch advanced with more commits. Now today I created another branch from develop called release-ecomm which was on second to last commit. Then I added another commit to release-ecomm. Now I'm trying to merge this release branch into master. I checked out master and hit merge and selected the latest commit, but it failed.

Merge Conflicts

The files listed here include both edited and non edited files. Style.css and Script.js were edited but other files were not touched at all since the last commit to master. Then the tree structure changes like so with conflicting files:

Modified Tree Graph

What I would like is the master version to incorporate the changes made to the few files that are modified in release-ecomm. What am I doing wrong?

Whip
  • 1,891
  • 22
  • 43
  • How about [git partial merge, not whole branch](http://stackoverflow.com/questions/4315948/git-partial-merge-not-whole-branch) – antak May 27 '16 at 08:53

1 Answers1

3

You branched release-ecomm from develop, so all changes from develop until that point are also included in the merge.

If you only want the changes from a single commit to master, use git cherry-pick:

git checkout master
git cherry-pick <commit hash>
1615903
  • 32,635
  • 12
  • 70
  • 99
  • I tried that but it didn't really merged the branches. it added the modified files to staging area of master and then I made a new commit to save them in the history. – Whip May 27 '16 at 10:01
  • In your question you said _"What I would like is the master version to incorporate the changes made to the few files that are modified in release-ecomm"_, that means you cannot merge, since release-ecomm is based on develop, not master. You could do a rebase first if you insist on doing a merge, though I can see no advantages in that strategy. – 1615903 May 27 '16 at 10:03
  • I was just trying to follow the [GitFlow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) as explained here. The first release merged fine but second conflicted. I can see why but how do I merge subsequent release branches that only modifies parts of a project? – Whip May 27 '16 at 10:10
  • I'm not following - you specifically said that you ONLY want the changes made in `release-ecomm` branch - git flow assumes that when you start a release branch you want everything that is done in develop so far to be in the next release. – 1615903 May 27 '16 at 10:12
  • Also, if you are following git flow, no merge conflicts should occur when merging to master since you never make any commits directly to master, you only merge release branches to it. – 1615903 May 27 '16 at 10:15
  • I would assume it would think 'everything done after the previous release'. You see you launch a product and have that server ready version of the product in your master branch. So the code in develop and master is essentially the same except, say the code in master is minified. Now you have to add a feature to the product, you do that in the develop version, how do you merge that new feature ONLY in the master branch. Should I delete unmodified files in this second release branch? – Whip May 27 '16 at 10:17
  • As you can see in the screenshots, there have been no commits in master, only one release merge – Whip May 27 '16 at 10:18
  • Ok, my last 2 cents: regarding git flow, when you do a release branch, if you make any changes there they should also be merged to develop. That's what's causing you conflicts now. And what you are currently doing is not what git flow suggests - if you only want to add single feature to production, you need to create a hotfix - see git flow documentation for how it's done. – 1615903 May 27 '16 at 10:21
  • Also, minifying should probably be part of the build process, not something you commit to version control. – 1615903 May 27 '16 at 10:23
  • Well the gitflow doesn't match up 100% to what I want and that's okay. Git is flexible enough too. Thanks @1615903 – Whip May 27 '16 at 10:30