Changes on feature branch after merge to 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

Bogy

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.

Good

Not sure what do you mean by push. From the context I would guess its a fast forward merge? – Bogy

After doing the rebase, you would git push the feature into master. This isn't really a normal merge, because a merge leaves you with a single commit, and fast forwarding master could leave you with many commits from the feature branch. – Good

Anyway, the only two options I really see are for you to rebase the feature on master and fast-forward master, or to simply merge the new commits from feature into master. – Good

I can't seem to follow your terminology. If you feel like it, please provide the answer using the given example repo for visualization, that way it would be more clear what you mean. – Bogy

I find my answer more clear than the original question. I'm not sure how the feature ended up getting polluted by master. If you want to move to a chat, I'm keen to do that. – Good

Would like to move to chat but have never done so, it seems to only pop up when we pollute (:p) the comment section – Bogy