Git merge and keep separate?

Is there a way to update a side branch with information from another (master or other), and then have the two continue? Like a rebase, but keeping the old data there?

Original:

A---B---C---G---H  master
     \           
      D---E---F  branchA

Result:

A---B---C---G---H---L  master
     \           \
      D---E---F---J---K  branchA

Such that branchA gets the information from commits C, G, and H, (Commit J is that merge) such that commit K is still a side branch (and future commit L is still on master), but has the updated information from master?

I don't want to do a rebase, because that would end up with:

A---B---C---G---H---L  master
                 \
                  D'---E'---F'---K  branchA

Creating "new versions" of D, E, and F as if they happened on top of H instead of B, and the issue is that commits C and E is the renaming of a key folder in the repo, and I want to collapse them together, without merging the other feature updates from branchA just yet. Rebasing means H uses the new 开发者_StackOverflowfolder name, D' creates the old folder name, and E' removes it again, which isn't the most clean.

The point is I want to get that folder rename (C and E) in the past and stop bringing it forward. Does that makes sense? Am I looking at this backward? Or should I just deal with the messy rebase "name, rename" trick until the branch gets merged?

If your history goes up to H or L on master and F on branchA (that is, J and K do not yet exist), then yes, simply check out branch A and merge:

git checkout branchA
git merge H   # Use H's commit identifier if it's not the tip of master

This will merge the changes into branchA and will not disturb the master branch at all.

If you have already created commit K and you want to insert a merge between it and F, then there's a bit more work to do:

git checkout -b temp F   # Create a new branch at commit F
git merge H              # Merge from commit H into the new branch
git cherry-pick K        # Apply the K commit to the merged commit

# And the rest simply replaces the temp branch with branchA
git checkout branchA
git reset --hard temp
git branch -d temp

In both cases, if you later merge in either direction, commit H will be the nearest common ancestor of both history branches, and so future merges will not look past this commit (or past J to F either) when deciding how to merge.

A simple git merge master on branchA should do (or git merge H where H is H's commit-ref if H is not the latest on master).

There will be conflicts if both C and E rename the same folder which you will have to resolve, but other than that, you should be fine.