preface

Git is the most popular version management tool. Many companies use Git for project version management. Github, the largest code hosting platform in the world, is also built on the basis of Git. Many people find Git difficult because some of its concepts are different from those of popular centralized version management systems, and it’s easy to get started once you’re familiar with the basic concepts of Git and the process of switching git branches.

This article will introduce you to some of the basic concepts of Git and some of the commands that git uses. Github provides a set of git tutorials for those interested in git.

Distributed version library

The basic concept

Let’s take a look at the official website to introduce Git.

Git is a free and open source distributed version control system.

Git is a free and open source distributed version management tool.

The key is git distribution. Just execute git init in the root directory of your project and you will have a git repository, which will create a.git folder that will record all your submissions, similar to the.svn folder. This folder will store all information about each file you submit, but it will be compressed. The details are not detailed here. If you’re interested in the inner workings of Git, check it out here.

Unlike centralized version management tools, git commit is then committed to the local repository, whereas SVN commit is directly committed to the server’s central repository. This means that we all have a local version library, how do we manage our version library when so many people are developing?

A remote repository does not record our code files. It is only a bare repository. In other words, the remote repository only stores the contents of the.git directory. Everyone can have a remote repository synchronize your local commit information, but it checks to see if your local repository matches the commit information from the remote repository and reminds you to update it from the remote repository first. Alas, a picture is not worth a thousand words.

  1. When we tell the remote repository that I have a new commit for you to synchronize, it will reject you.
  2. Because someone else synchronized their commit to the remote branch before you, you must update their commit to your local branch before you can continue to synchronize your commit.

Before committing git to the repository, there is another step, which is to add git to the staging area.

Early version management tools had sophisticated GUIs, such as SVN, that gave you the freedom to choose which file changes to commit for each commit.

On the command line, these operations can be troublesome, so we added a staging area to store the files we need to commit before the commit. Ok, let’s go back and look at what git does in terms of version management.

Git Commands

With these concepts in mind, let’s take a look at how to initialize a Git repository and synchronize commit to a remote repository after making code changes.

Initialize git configuration

This configuration is used to tell the repository who submitted the code.

#Global Settings user name
git config --global user.name "your name"

#Global Settings mailbox
git config --global user.email "[email protected]"
Copy the code

Initialize the Git repository

There are two ways to create a local version library and manually connect to the remote version library, or to obtain the remote version directly to the local.

  1. Create a local repository and connect to a remote repository
#Create a folder and enter it
mkdir hub && cd hub

#Initialize the Git repository
git init 

#Associate the remote version library and name it Origin
git remote add origin [email protected]:github/hub.git

#Gets the commit information for the remote repository named Origin to the local repository
git pull origin master
Copy the code

Modify the file and submit it to the staging area

We can create a new file (eg.reamde.md) and use the add command to add it to the staging area to indicate that it is the file we want to commit to the repository.

#Adds a modified file to the staging area
git add readme.md


#Gitadd other uses

#Adds all modified, deleted, or new files to the staging area
git add .

#Add all files ending in JS to the staging area
git add *.js

#Adds all modified, deleted, or new files to the staging area
#Except for files that start with a., like.gitignore
git add *

#Git add -- short for update
#If you modify a file in the staging area again, you can use this command to update it
git add -u

#It has the same effect as git add
git add -A
Copy the code

…

Commit code to the repository

Now that we have added the code to the staging area, we need to commit the staging area to the repository.

#Commit staging code to the repository
git commit -m 'commit message'

#If you reedit some files and add them to the staging area, you want to merge those changes into your last commit
#An edit box will then appear, allowing you to modify your last submission
git commit --amend

#If you do not want to modify the last submission information
git commit --amend --no-edit
Copy the code

Synchronize remote repository to local repository

It is a good idea to synchronize the remote repository locally every time you synchronize your commit information to the remote repository. The branch concept will be covered here, but let’s put it aside for a moment. By default, the local version library defaults to the master branch (ps. Also known as the backbone).

#Synchronize the master branch of the remote repository named Origin to the current local branch
git pull origin master

#The git pull command is a shorthand for the following two commands
git fetch origin master
git merge origin/master
Copy the code

Synchronize local repositories to remote repositories

Git uses the push command to synchronize the local repository to the remote repository, but each time you need to specify which branch of the repository to synchronize to, you can use the -u parameter to bind the local repository to the remote repository.

Git push -u origin master git push -u origin master git pushCopy the code

Git branch

Git branches are the focus of Git version management. Compared with SVN, Git branches are lightweight.

Attention, high energy ahead!!

In order to explain these concepts clearly have to draw some pictures, can not be too good art foundation, words and do not say, have to draw pictures to write tutorial

What is a branch

To understand git’s branching concept, you first need to understand how Git differentiates branches. In Git, a branch has a pointer that points to a commit. Each pull creates a new pointer to the current COMMIT, and the pointer to the branch moves forward each time to follow the commit.

#View the current branchGit branch # The repository you just initialized will default to the master branch#The new branchCreate a new branch named branchCopy the code

If you create a new branch and both branches point to the same COMMIT, how can you tell which branch is on the same commit? Here we introduce a new pointer, HEAD, that points to the current branch.

#Switch branchGit checkout branch
#Create and switch branches can be abbreviated to a command
gti checkout -b branch
Copy the code

Now a COMMIT is made on the branch branch, and the branch pointer is moved forward.

vim xxx.txt
git add.
git commit -m 'modify xxx.txt'
Copy the code

Then switch to the Master branch, commit once, and as you can see from the picture below, the branch will appear. The master branch means commit1, 2, 3, 5, and branch means commit1, 2, 3, and 4. It’s easy to understand why git branches are lightweight, because with Git a branch simply creates a new pointer to a commit, rather than copying all the code files to another directory.

Git add. Git commit -m 'modify yyy.txt'Copy the code

Merging branches

The world is divided into three parts, long divided, long divided. When there are branches, there will be merges. For example, a bug suddenly appears in the project, but the code at hand is not finished, so it cannot be directly committed. So you pull a fix-bug branch from the master branch and Fix it on the branch before committing. The last commit needs to be merged back to the master branch.

#1. Create the feature branch first and submit the code at hand to the feature branch
git checkout -b feature
git add .
git commit -m 'feature branch commit'

#2. Switch back to the master branch and pull a new branch from the master branch
git checkout master
git checkout -b Fix-Bug

#3. After modifying the bug, submit the code to the fix-bug branch
git add .
git commit -m 'fixed bug'

#4. Merge bug-fixed code into master branchGit pull origin master git pull origin master git pull origin master Git branch -d Fix- bug git branch -d Fix- bugCopy the code

The above is a simple demonstration, but the reality is more complicated than that.

Looking at the figure above, you can see that after the merge operation, a new COMMIT is automatically generated. If you do not want to make the commit, have other changes after the merge, or want to write the commit message yourself, you can also use the following command to disable the automatic commit.

git merge --no-commit branch
Copy the code

Special case of merge: conflicts

Sometimes when you merge a remote repository and a local repository, you and your colleagues may merge the same file in the same location, and this will cause conflicts. Conflict, of course, is to resolve the conflict. You can resolve conflicts manually, but you can also use tools like the one below that use vscode to resolve conflicts.

Git status allows you to see which files are in conflict, and you can commit once all conflicts are resolved using the editor.

The common git branch management mode is gitflow

This mainly involves the common branch naming conventions:

  1. The master trunk, used to hold the most stable code
  2. Hotfix, a branch for emergency bug fixes
  3. Release, the branch that publishes live
  4. Every new feature should have a feature branch
  5. After a feature is developed, merge the feature branch into the Develop branch

thanks

Originally reprinted to nuggets -Shenfq, thanks for sharing!

After the language

This article only introduces the basic collaborative flow needed in enterprise team development, but Git also provides many advanced commands to solve more complex scenarios, such as Rebase, reset, and Stash. I won’t go into more details here, so you can explore them on your own.

If you feel this article is helpful to you, please click like + follow, your support is my motivation to continue to output good content!