Shulou(Shulou.com)06/03 Report--

Almost all version control systems support branching in some form. Using branches means that you can separate your work from the development mainline so as not to affect the development mainline. In many version control systems, this is a slightly inefficient process-- it is often necessary to create a complete copy of the source code directory. For large projects, this process can take a lot of time.

Some people call the branch model of Git as its' must-kill feature', which makes Git stand out from many version control systems. Why is the branching model of Git so outstanding? The way Git handles branches is incredibly lightweight, creating new branches can be done almost instantly, and switching between branches is just as easy. Unlike many other version control systems, Git encourages frequent use of branching and merging in workflows, even many times a day.

Branch introduction

Every time a user submits, Git will string them into a timeline, which is a branch. By default, Git has a timeline, which is called master.

The master branch of Git is not a special branch, it is completely indistinguishable from other branches, and almost every warehouse has a master branch because the git init command is created by default.

A branch of Git is essentially just a variable pointer to a commit object. The default branch name of Git is master, which automatically moves forward with each commit operation.

Git branch testing # creates a testing branch that creates a pointer on the current submission object

Git log-- oneline-- decorate # to see which branch you are currently on

4555188 (HEAD-> master, testing) version-1 # HEAD pointer to the master branch

Git has a special pointer called HEAD, which points to the local branch where it is currently located, and the HEAD pointer Git can tell which branch it is currently on.

Git checkout testing Switched to branch 'testing'git log-- oneline-- decorate 4555188 (HEAD-> testing, test1 Master) version-1 # HEAD points to the role of the testing branch: echo "test1" > a.py # modify a.py file content git commit-a-m 'version-2' # submit cat a.py # View file contents testgit checkout master # switch branches Restore the working directory to the snapshot content pointed to by the master branch cat a.py # View the file contents (nothing)

In other words, if you make changes now, the project will start with an older version. In essence, this is to ignore the changes made by the testing branch in order to develop in the other direction.

Branch switching will change the files in your working directory. When switching branches, be aware that the files in your working directory will be changed. If you switch to an older branch, your work directory will revert to what it looked like the last time that branch was submitted.

Echo "test2" > a.py # modify the contents of the a.py file

Git commit-a-m 'version-2' # submit cat a.py # View the contents of the file

The above two changes are for different branches: you can constantly switch and work back and forth between different branches and merge them when the time is right

Git log-- oneline-- decorate-- graph-- all shows the submission history, the direction of each branch and the branch bifurcation of the project

Because a branch of Git is essentially a file containing the checksum of the object it refers to, its creation and destruction are extremely efficient. Creating a new branch is equivalent to writing 41 bytes (40 characters and 1 newline character) to a file

In Git, projects of any size can create new branches in an instant. At the same time, since each submission records the parent object, it is equally simple and efficient to find an appropriate merge basis (that is, a common ancestor).

Details: https://git-scm.com/book/zh/v2/Git- Branch-Branch introduction

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.