Understanding Branch Operations

Asked 1 years ago, Updated 1 years ago, 45 views

Suppose you were working on a Git (GitHub) remote branch, such as:

master   --develop
    --branchA
    --branchB
    --branchC

In normal operations, when each branch is developed, it is merged into development, then merged into master after staging, and then released into production. What would be the most efficient way to do if the following situations occur?

  • Only branchC must be released with priority
  • BranchA has already been merged into develop, but cannot be released in production because it has not been confirmed in staging
  • BranchB has been pushed remotely and is under review with PullRequest, so it has not been merged into development yet

In order to release branchC, I would like to release branchA and C at the same time, but I would like to release branchC only first.

Also, if there is only one merged branch as shown in the example, it is still fine, but there are actually multiple branches.

Could you tell me if there is a good way?
Thank you for your cooperation.

G If I can change the parent of branchC from develop to master without fully understanding how Git works, it would be ideal to treat it like a hotfix...(^-^;

git git-flow

2022-09-30 20:23

3 Answers

If you are bringing up the concept of develop/master/topic branch, I think you are expecting a workflow of git flow.

Why don't you treat branchC like HotFix and merge it into master?

If you treat it as HotFix in terms of git flow, I think the specific tasks will be as follows:

    <li>Rebase branchC in a form derived from master, not develop.
    (got rebase --onto etc.)
  • Master--branchC and then merge into master
  • Release new master as HotFix
  • Merging branchC into develop (because develop is left behind)


2022-09-30 20:23

The parent-child relationship of the branch is not managed in Git.Basically, two branches that branch somewhere can merge with each other, so you can merge branchC into master.However, in this case, all modifications from the time when master and branchC branch off to branchC will be applied to master, so

In such a case, branchA merged after cutting branchC is not involved, but branchX merged before cutting is already part of branchC's history and will be merged into master together.

To avoid this, you need to create a commit "Include only branchC changes to master".

For example, git rebase --onto allows you to recreate each commit from the point when develop and branchC diverged to the current branchC, starting with master.

As with the simple rebase, the current branchC will be lost, so you may want to tag the branchC at the time you start working on it, or back up the repository, so that it can be returned if something happens.


2022-09-30 20:23

How about reverting the merge commit of branchA and merging branchC?

If you don't forget to revert the commit that you did revert branchA after merging branchC, you will be able to achieve your goal.


2022-09-30 20:23

If you have any answers or tips


© 2024 OneMinuteCode. All rights reserved.