Git Pro-(2) Branch

Git doesn't save file differences or changes, it's just a series of file snapshots.

When committed in Git, a commit object is saved, which contains a pointer to a snapshot of the staging content, an author and associated collateral information, and a number (or possibly none) pointer to the immediate ancestor of the commit object. When you use Git commit to create a new commit object, Git calculates the checksum for each subdirectory (in this case, the project root) and then saves those directories as tree objects in the Git repository. After that, Git creates a commit object that contains pointers to the tree object (the project root), in addition to the relevant commit information, so that it can reproduce the snapshot's contents in the future. The Git object data that was submitted multiple times might look like this:

A branch in Git is essentially a mutable pointer to a commit object. Git uses master as the default name for the branch. After several commits, you actually have a master branch that points to the last commit object, which automatically moves forward at each commit:

Branching basic operations Creating branches

Git branch Testing

This creates a new branch pointer on the current commit object:

So, how does Git know which branch you're currently working on? In fact, the answer is simple, it holds a special pointer called HEAD, pointing to the current branch:

Switch branches

git checkout Testing

Running the git branch command simply creates a new branch, but does not automatically switch to that branch. To switch to another branch, you can execute the git checkout command:

Git checkout-b Branch can create a branch and switch to that branch.

Merging branches

git merge [branch]

The following command switches to the master branch and then merges the hotfix branch into the master branch:

$ git Checkout Master

$ git Merge Hotfix

The "Fast forward" prompt appears when merging. Since the commit of the current master branch is the direct upstream of the hotfix branch to be merged, Git simply shifts the pointer right. In other words, if you go down one branch and you reach another, Git merges both, simply moving the pointer forward, because there is no disagreement to solve, so this process is called fast-forward. (Fast forward).

Delete Branch

git brach-d [branch]

Now the hotfix branch is useless and can be deleted with Git brach-d hotfix.

Three-party merger

As shown when merging iss53 into Master, a three-party merge was made:

This merger was realized and was different from the previous hotfix incorporation method. This time, your development history starts with branching out from earlier places. Because the commit (C4) that the current master branch points to is not the direct ancestor that you want to incorporate into the branch (ISS53), Git has to do some processing. In this case, Git uses the end of the two branches (C4 and C5) and their common ancestor (C2) to perform a simple three-party merge calculation. Instead of simply moving the branch pointer right, Git makes a new snapshot of the results of the three-way merge and automatically creates a commit that points to it.

If you modify the same part of the same file in the two branches to be merged, Git cannot cleanly combine the two, requiring manual intervention.

View Branches

Git branch

List all Branches

Branching workflow long-term branch

Since Git uses a simple three-party merge, it is not difficult to merge a branch to another branch over a long period of time. That is, you can have multiple open branches at the same time, each of which is used to accomplish a specific task, and as the development progresses, you can move the results of a feature branch to other branches at any time. For example, just keep the fully stable code in the Master branch, which is the code that has been published or is about to be published. At the same time, they have a parallel branch called develop or next, dedicated to subsequent development, or only for stability testing-not necessarily absolutely stable, but once in a stable state, you can merge it into master. The goal is to have different levels of stability: when these branches enter a more stable level, merge them into higher-level branches.

Feature Branch

An attribute branch refers to a short-term branch that is used to implement a single feature or its associated work. This technology allows you to quickly and completely switch context-because your work is scattered across the pipeline, and the changes in each branch are related to its target characteristics, and things like browsing the code become easier. You can keep the changes you make in the feature branch for a few minutes, a few days or even months, and then merge them when they mature, without caring about the order or the progress they set up.

Now let's look at a practical example. Take a look at Figure 3-20, at first we work in master to C1, and then start a new branch iss91 try to repair 91st defects, submitted to the C6, and a new idea to solve the problem, so from the place before C4 branch iss91v2, dry to C8, and Back to the trunk of the C9 and C10, and then back to Iss91v2 to continue to work, submit C11, then, and then a less certain idea, from the master's latest submission C10 opened a new branch Dumbidea do some experiments.

Now, let's assume two things: we finally decided to use the second solution, the one in Iss91v2, and we showed the Dumbidea branch to our colleagues and found it to be a genius. So next, we discard the original ISS91 branch (that is, discard C5 and C6) and merge the other two branches directly into the trunk. The final commit history will turn into figure 3-21:

Git Pro-(2) Branch