git
add
commit
push
pull
clone
git

Use the git branch

Git branch <branch> // Create a branch named <branch>, but do not switch to git branch-d<branch> // Delete the specified branch. This is a "safe" operation and Git prevents you from deleting branches that contain unmerged changes. Git branch -d <branch> // Forcibly delete branch git branch -m <branch> // rename current branchCopy the code

In daily development, whether fixing a bug or adding a feature, we should create a branch to encapsulate our changes. This ensures that our unstable code will never be committed to the main code branch.

The following is a detailed look at the branch operations, branch changes:

Create a branch

It’s important to understand that a branch is just a pointer to a commit. When you create a new branch, you’re actually just creating a new pointer. The warehouse itself is not affected.

git branch new-feature
Copy the code

git chekcout new-feature
new-feature
git add
git commit

Delete the branch

If you have finished developing the new-feature and commit the code, you are free to delete the branch.

git branch -d new-feature
Copy the code

If the branch has not yet joined the master, the following error will be reported:

error: The branch 'new feature' is not fully merged.
If you are sure you want to delete it, run 'git branch -D crazy-experiment'.
Copy the code

At this point you can merge branches (how to merge branches is explained below). If you really want to delete branches, you can use -d to force the deletion:

git branch -D new-feature
Copy the code

Git checkout

The git checkout command allows you to switch to a branch created with Git Branch. Switching branches updates files in the current working directory, and you can use git log to view the history of the current branch. usage

Git checkout <existing-branch> // Git checkout -b <new-branch> // git checkout <existing-branch Checkout -b <new-branch> <existing-branch> // Create a branch on top of an existing branch. The original branch is the base for the new branchCopy the code

Git Branch and Git Chekout are gay friends. You can use Git Checkout to switch between different functional branches or bug branches without interacting with each other.

The detached HEAD (detached HEAD) will remind you that you are in the detached HEAD. For example, if you want to go back to the detached version and checkout some files, you will have to git the hash code or tag of the checkout commit.

git checkout 2

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 2
Copy the code

If you develop in this state, and then add,commit, there’s no branch that can get you back to where you were before. When you inevitably have to checkout to another branch, it’s impossible to come back because the X state, like the one in the picture, is not on the branch at all, and you can no longer refer to the code you added earlier.

Important: Always develop on development branches, not separate heads. This ensures that you can refer to your new commits if onlycheckoutIf you really need to add code to a previous version, remember the warning abovegit checkout -b new_branch_nameIs oneself in an exact branch.

Moving away from the detached HEAD, let’s look at what a Git branch process actually looks like:

git branch new-feature
git checkout new-feature
Copy the code

Next we make some code changes and commit:

git add <some file>
git commit -m "A new feature"
## You change the code, and you commit it many times
Copy the code

When you checkout the master branch, you will find that the commit of the new feature branch is not present. This will not affect the master branch. At this point, you can consider merging the new-feature or starting something else on the Master branch.

Merge (git merge)

Merge is Git’s way of putting the history of forks back together. The git merge command allows you to merge branches created by Git branch into one. usage

Git merge --no-ff <branch> // Merge the specified branch into the current branch, but always generate a merge commit (even if it is a fast forward merge). This can be used to record all merges that occur in the repository.Copy the code

Once development is complete on the new branch, we need to merge the commit from the new branch into the main branch. Git will select different algorithms to do the merge based on the current structure information between branches:

  • Fast forward merge
  • Three-way merge

When there is a linear relationship between the new-feature branch and the original master branch, perform the fast-forward merge, git will move the current HEAD pointer to the top of the target branch quickly, and the master branch will have the history of the new-feature branch, as shown in the figure:

Let’s look at an example of a fast forward merge:

# Start a new feature
git checkout -b new-feature master

# Edit file
git add <file>
git commit -m "Start new feature"

# Edit file
git add <file>
git commit -m "Complete function"

# merge new-feature branches
git checkout master
git merge new-feature
git branch -d new-feature

Copy the code

This is a major workflow for projects with few co-developers. If there are many co-developers, the master branch will often have new submissions. If your new-feature takes a long time, several versions of the master branch may have passed by the time you submit it, and at this time, the following three paths need to be merged.

Git can only perform a three-way merge if the master branch has a new commit after the new-feature split. The three-way merge uses a dedicated commit to merge the history of the two branches.

If both branches make changes to the same part of the same file, Git will not be able to determine which one to use, and the merge merge will stop, requiring you to resolve the conflicts manually. You can use git status to see where there is a conflict. Most of the time I run grep -rn HEAD in the directory to see where there is a conflict.

When all the conflicts have been modified, git add all the conflicting files and run git Commit to generate a merge commit, just as you would commit a normal snapshot. Commit conflicts only exist in a three-way merge, and it is not possible to make different changes to the same part of the same file in a fast-forward merge.

Here is an example of how a three-way merge can occur:

# Start a new feature
git checkout -b new-feature master

# Edit file
git add <file>
git commit -m "Start new feature"

# Edit file
git add <file>
git commit -m "Complete function"

# Build on the master branch
git checkout master

# Edit file
git add <file>
git commit -m "Added some extremely stable features to the Master."

# merge new-feature branches
git merge new-feature
git branch -d new-feature
Copy the code

At this point, the merge stops because the master cannot be moved directly to the new-feature. So you need to manually merge conflicts and then commit.

Git merge causes merge commits. Some people choose to use Git rebase to merge to ensure a clean commit history. I’ll write another introduction to the difference between the two.