Summary: What are the best practices for handling long running tracking of upstream repositories where you want to maintain a set of local changes?
I want to keep a fork
You are incorrect in your assumption. You said in your text example that you would be running the git merge
command. If you really meant this, and not git cherry-pick
(and for the record, git-merge is the best practice in the situation) then you do NOT get F` in your branch, you get F. Perhaps a picture:
After the fetch but before the merge, your repos look like this:
Upstream:
A-B-C-D-E-F [master]
Fork: /-F [upstream/master]
A-B-C-D-E ----- P ------T [master]
\-L-M-/ \-Q-R-/ [Other branches]
After you merge, your repo will look like this:
Fork: /-F-------------\ [upstream/master]
A-B-C-D-E ----- P ------T-U [master]
\-L-M-/ \-Q-R-/ [Other branches]
New commit "U" in your repo will be a merge commit, just like commits "P" and "T".
git cherry-pick
would create "F'" as you indicated in your example. Don't do that. git rebase
can sometimes support rebasing branches git rebase -p
but it doesn't always work. Also, that is rewriting public history, which is a bad idea.
I have a document on git best practices: Commit Often, Perfect Later, Publish Once You might specifically want to investigate the workflow section for further inspiration.