Best practice to commit a bug fix into both master and branch

If a fix needs to be committed into both master and another branch (on an remote shared repo), what is the best practice?
Since we cannot use git merge here because not all the commits in master or branch should go into another, is cherry-pick the best choice?

  • What is the best way to use “git add -p” in emacs on Windows?
  • Include last commit index in project
  • Software versioning with GIT
  • How do I tell git-svn about a remote branch created after I fetched the repo?
  • Use of apostrophe (single-quote) in a git commit message via command line?
  • On local branch, don't want to commit changes, but need to switch to another branch
  • Example:

    commit FIX to master

    checkout branch

    cherry-pick FIX from master and push

    Does cherry-pick have the same issue as rebase (never rebase if the commit is going to be shared) ?

  • error: unable to unlink old 'gulpfile.js' (Permission denied) while using Docker Compose for development environment
  • Git: How to maintain two branches of a project and merge only shared data?
  • git and “Server aborted the SSL handshake” errors
  • ORIG_HEAD, FETCH_HEAD, MERGE_HEAD etc
  • Font Awesome fonts displaying as boxes after Git clone/pull?
  • Git pull - deleted files
  • 4 Solutions collect form web for “Best practice to commit a bug fix into both master and branch”

    cherry-pick is a good choice in your case!

    Does cherry-pick have the same issue as rebase (never rebase if the
    commit is going to be shared) ?

    Cherry-pick has no any issues, like rebase, because it works in way: read difference for the commit you are cherry-picking and apply the patch to the branch. This does not destroy history (like rebase). After the operation these commits will not be coupled in any way!

    The preferred practice should be to make the fix on a branch that is the common base of all the branches where the fix should be merged to, and merge that commit into all the target branches. This allows you to have a correspondence between “is commit A in branch B” and “is the fix for bug A in branch B”.

    If you don’t have such a branch naturally, you can make a temporary one from a suitable point in history, e.g. found using git merge-base.

    Circumstances where this may prove problematic is where the branches have diverged so much that essentially you need to make a difference fix to solve the same problem in each branch.

    E.g.

    git checkout -b quickfix $(git merge-base master branch)
    # Note, you may want to check 'git merge-base -a' and choose the best one
    # code, code code
    git add <modified files>
    git commit -m "Fix for pressing issue"
    
    git checkout master
    git merge quickfix
    # Review merge and test result, fixup merge if necessary
    
    git checkout branch
    git merge quickfix
    # Review merge and test result, fixup merge if necessary
    
    # Optionally, push all branches to 'origin'
    git push origin branch master
    

    Cherry pick is the right choice.

    Commit to master, and cherry pick the commit onto your branch as well.

    I don’t understand your comparison with rebase, but note that cherry pick creates a completely new commit ( of course, because the parent and other meta data are going to be different )

    If you ruled out merge indeed cherry-pick is left as the only option. First push the master, then pick to branch using the form that adds hash of original to the commit message.

    The problem with picks is that they create a new commit and that makes it damn hard to know what is contained where really. So try to preserve as much relation info as you can.

    Git Baby is a git and github fan, let's start git clone.