0

I have an issue with branching and merging in git. We have the following branches (which are our product, and are maintained in parallell as they all are installed and supported at customers)

2015Edition1
2015Edition2
2016Edition1
2016Edition2
master

We can think of these branches as release branches. The problem is as follows. 2015Edition1 is branched and a fix is commited into branch fix1.

2015Edition1
        fix1\-- bugfix

The fix is merged back into 2015Edition1 and released.

2015Edition1--------------merge
        fix1\-- bugfix --/

However, the Branches 2015Edition2, 2016Edition1, 2016Edition2differs quite heavily, due to binary help files, a lot of product dependent images and so on, and changes in sourcecode that is never merged back to master.

Is there any way to merge the fix1 branch and only get the commits in fix1

The result I want is as follows:

2015Edition1--------------merge--
        fix1\-- bugfix --/
                         \
                ----------merge--
2016Edition2fix/
   2016Edition2 --

I know i can cherry pick the commits into the other branches. but this is a very simplified example. and i think i lose the ability to track in wich branches the commits are present.

Any comments and suggestions

Teodor Andersson
  • 33
  • 3
  • Short answer: no. You could do a merge with `--no-commit`, clear out all the merge results, replace them with the effect of a cherry-pick (using `git cherry-pick -n`), and commit that; but this is a bad strategy that will ultimately result in tears. – torek Apr 27 '16 at 08:56
  • yes, thats why i want to avoid that situation. i think maybe git merge-base 2015Edition1 2016Edition2Edition could give the point from where the branches begun to differ. But i am not shure the source code existed in that point. (and therefore hard to fix bugs in :) – Teodor Andersson Apr 27 '16 at 11:33

4 Answers4

1

I think the problem here is that you're trying to maintain multiple long-running branches, and that's not the way Git was designed to work.

Say you have three branches, release1, release2, release3: 

* 3d3 (release3)
* 28d
* e38
* b51
| * 27a (release2)
| * df1
| | * 948 (release1)
| | * ce3
| |/
|/|
| |
|/
* 166 (master)
* 6f0
* 1e8

If you add a new commit to release1 and you want to bring that into release2, you'll end up bringing ce3 and 948 along with it.

This becomes messy quite quickly, and you'll eventually lose track of what has been merged into what. As the code differs heavily, maybe you should consider moving the branches into their own separate repositories, and extracting the common areas of the code into a distributable library/package (which should probably go into its own repository as well).

alextercete
  • 4,871
  • 3
  • 22
  • 36
1

You can use following script to squash you feature branch commit before merge to master branch.

# brief: This script should be run from within your git repo. You need to have your feature branch
# checked out. This will squash all the commits on your feature branch (assuming you 
# branched from master). Then you can just use the github PR UI to merge the PR in. You need to have 
# feature branch checked out when you run this script (git checkout feature branch).

# usage: git-helper-squash-all-commits <final commit messsage ex: "reorganizing directory structure"
# example: git-helper-squash-all-commits "reorganizing directory structure"

#!/bin/sh
set -ex 
FINAL_COMMIT_MESSAGE=$1
BRANCH_YOU_BRANCHED_FROM=master
CURRENT_BRANCH=`git rev-parse --abbrev-ref HEAD`
COMMIT_HASH=`git merge-base HEAD $BRANCH_YOU_BRANCHED_FROM`
git reset --soft $COMMIT_HASH
git commit -am "$FINAL_COMMIT_MESSAGE"
git push origin $CURRENT_BRANCH --force
Ravi Prajapati
  • 2,536
  • 1
  • 11
  • 9
0

You can follow these steps:

  • git status
  • git add (if you can modify or add any files)
  • git commit -m "<message>"
  • git push origin <your branch>
  • git checkout <main branch>
  • git pull origin <main branch>
  • git merge <your branch>
  • git push origin <main branch>

This is the right way to commit and merge in Git. And please do not use git add ., instead you can use git add <file path>

alextercete
  • 4,871
  • 3
  • 22
  • 36
Er Amit Anand
  • 50
  • 1
  • 7
0

Ok, i solved this by rearrangeing the bugfix. I did it wrong from start. The soulution that worked for me was to find the merge-base commit between the branches,create a branch in the merge-base. Then cherry-pick the bugfix commits into that branch.(i think i could have done a rebase on the new branch instead), and then merge the new branch into the other branches that shall contain the bug-fix:

$git merge-base 2015Edition1 2016Edition2 (earliest vs latest release)
5a5def
$git checkout -b bugfix-branch 5a5def
$git cherry-pick -x bug-fix-commit
$git checkout 2016Edition1
$git merge bug-fix-branch
$git checkout 2015Edition2
$git merge bug-fix-branch
.... and so on.

This seems to be the way to solve the problem. My mistake was I did not branch from the right commit. Any comments on this? Is this the way to solve the issue in the "right" way?

Teodor Andersson
  • 33
  • 3