background
Git is the most popular version management system. Most companies use Git for version control, and github, the largest gay dating website, is also built on 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 libraries
The basic concept
First, check out git’s official website.
Git is a free and open source distributed version control system.
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.
- When we tell the remote repository that I have a new commit for you to synchronize, it will reject you.
- 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.
Set user name globally
git config --global user.name "your name"
Set the mailbox globally
git config --global user.email "[email protected]"
Copy the codeInitialize 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.
- Create a local repository and connect to a remote repository
mkdir hub && cd hub
git init Initialize git repository
git remote add origin [email protected]:github/hub.git Name the remote version library origin
git pull origin master Get the commit information for the remote repository named Origin to the local repository
Copy the code- Get the remote version library locally
git clone [email protected]:github/hub.git # This command is equivalent to an abbreviation of the three steps above
Copy the codeModify 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.
Add a modified file to the staging area
git add readme.md
# gitadd other uses
Add all modified, deleted, or newly created files to the staging area
git add .
Add all files ending in JS to the staging area
git add *.js
Add all modified, deleted, or newly created files to the staging area
# except for files that start with a., such as.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
Git add
git add -A
Copy the codeCommit 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 reedited some files and added them to the staging area, you want to merge those changes into the 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 codeSynchronize 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 branch of the local repository
git pull origin master
The # git pull command is shorthand for the following two commands
git fetch origin master
git merge origin/master
Copy the codeSynchronize 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.
Sync local commits to remote repositories
git push origin master
Bind the default committed remote repository
git push -u origin master
Next time you commit, just use git push
git push
Copy the codeGit 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 branch
git branch The newly initialized repository is on the master branch by default
Create a new branch
git branch branch Create a branch named branch
Copy 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 branches
git checkout branch Switch to the branch
# Create branch and switch branch can be abbreviated as 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 checkout master Switch to the master branch
vim yyy.txt
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 commit 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 master
git checkout master
git checkout -b Fix-Bug
#3. Once the bug is fixed, submit the code to the fix-bug branch
git add .
git commit -m 'fixed bug'
Merge the bug-fixed code into the master branch
git checkout master Switch back to the master branch
git pull origin master # Update the code submitted by colleagues locally first
git merge Fix-Bug
git push origin master # Merge merge code online to fix the bug
git branch -d Fix-Bug # Remove the fix-bug branch after bug fixes
Copy 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 codeSpecial 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:
- The master trunk, used to hold the most stable code
- Hotfix, a branch for emergency bug fixes
- Release, the branch that publishes live
- Every new feature should have a feature branch
- After a feature is developed, merge the feature branch into the Develop branch
reference
There are many more advanced git commands to discover, such as rebase, reset, and Stash.
Finally, I recommend some good git tutorials for you.
- pro git
- Git command summary
- Git push and pull default behavior