合并为master后功能分支的更改

Question

I'm looking for a way to introduce changes into feature branches once they have been merged to master. The goal is to keep the feature branch keep only containing commits that are related to it.

It often happens that a feature needs some additional polishing after it has already been pushed to master. The changes that have been done to master during that time aren't in conflict with the feature, meaning that a rebase to actual master is possible when implementing the additional work on the feature branch.

The image below shows the situation:

Approach i used so far: Rebase to master and merge feature back to master

Against -> The feature branch is now poluted with parts from master.

Question: What are the approaches you take in practice to solve this issue?

Example code

To help describe the approaches below is the code to create the repo structure from the examples.

# mkdir test
git init 
touch master-change-file
git add master-change-file
git commit -m "initial commit"
echo 1 > master-change-file
git commit -a -m "master commit 1" 
echo 2 > master-change-file
git commit -a -m "master commit 2" 
git checkout -b feature
echo 3 > feature-change-file
git add feature-change-file
git commit -a -m "feature commit 1"
echo 4 > feature-change-file
git commit -a -m "feature commit 2"
echo 5 > feature-change-file
git commit -a -m "feature commit 3"
git checkout master 
git merge --no-ff feature -m "Merge branch 'feature'"
git checkout feature 
echo 6 > feature-change-file
git commit -a -m "feature commit 4"
echo 7 > feature-change-file
git commit -a -m "feature commit 5"
git checkout master 
echo 8 > master-change-file
git commit -a -m "master commit 3"
echo 9 > master-change-file
git commit -a -m "master commit 3"
# gitk --all

Answer 1

Approach i used so far: Rebase to master and merge feature back to master

I think you might be slightly confused about the purpose of rebasing. If you have made new commits to a feature branch after merging it to master , and you want to bring those new changes into master as well, then rebasing is one option. Consider the following diagram:

master:  A <- B <- C <- D
feature: A <- B <- C <- E <- F

If you were to do:

git checkout feature
git rebase master

then you would be left with:

master:  A <- B <- C <- D
feature: A <- B <- C <- D <- E' <- F'

At this point, you would simply push the feature branch into master , you would not merge it. Merging feature into master after doing a rebase is pointless, and defeats the purpose of rebasing which is to maintain linearity.

Finally, here is the answer to your question. You basically have two choices to handle these feature branches which have new changes. You can either merge, or you can rebase. It is up to you whether or not you wish to preserve the original commits which took place in the feature branches.