Recommended! teach you to use Git

A: What is git?

Git is currently the most advanced Distributed version control system in the world.

Two: What is the main difference between SVN and git?

SVN is a centralized version control system, the repository is centrally placed in the central server, and work, with their own computers, so the first to get from the central server where the latest version, and then work, after the completion of the job, you need to put the work done to the central server. Centralized version control system must be networked to work, if the LAN can also, the bandwidth is large enough, fast enough, if under the Internet, if the speed is slow, I wonder.

Git is a distributed version control system, then it does not have a central server, everyone's computer is a full version of the library, so that the work of the time will not need to network, because the version is on their own computer. Since everyone's computer has a full repository, how do people collaborate? For example, they changed the file a on the computer, the other people also on the computer changed the file a, at this time, you two only need to put their changes to each other, you can see each other's changes.

Three: How to install git on Windows?

Msysgit is the Windows version of Git, as follows:

You need to download one from the Web and then install it by default. After the installation is complete, find "git–> Git Bash" in the Start menu, as follows:

A similar command window will pop up something that indicates that the GIT installation was successful. As follows:

After the installation is complete, the final step is required and the command line is entered as follows:

Because Git is a distributed version control system, you need to fill in the user name and mailbox as an identity.

Note:the git config–global parameter, with this parameter, means that all of your git repositories on this machine will use this configuration, and of course you can specify a different user name and mailbox for a warehouse.

Four: How to operate?

One: Create a repository.

What is a repository? Repository also known as the Warehouse, English name repository, you can easily understand a directory, all the files in this directory can be managed by git, each file modification, deletion, git can track, so that any time can track history, or at some point in the future can also "restore" the file.

So the creation of a repository is also very simple, as follows I am the D disk –> www under the directory of a new Testgit repository.

The PWD command is used to display the current directory.

1. Use the command git init to turn this directory into a repository that git can manage, as follows:

At this time your current Testgit directory will be more than a. Git directory, this directory is git to track the management version of, nothing to manually change the files in this directory, otherwise, the GIT repository will be destroyed. As follows:

2. Add the file to the repository.

First to be clear, all version control system, can only track changes in text files, such as txt files, Web pages, all the code of the program, Git is not listed outside, the version control system can tell you each time the changes, but pictures, videos of these binaries, although can also be managed by the version control system, But can not track the file changes, only the binary files each time the change string up, that is to know the picture from 1kb to 2KB, but what changed, version control also do not know.

Let's take a look at the demo below:

I create a new Notepad file under the repository Testgit directory Readme.txt content as follows: 11111111

Step one: Use the command git add Readme.txt to staging area inside. As follows:

If the same as above, without any hint, the description has been added successfully.

Step two: Use the command git commit to tell git to submit the file to the repository.

Now that we have submitted a Readme.txt file, we can see if there are any files that have not yet been submitted under the command git status below:

Note that no files were not submitted, but I will now continue to change the Readme.txt content, such as I add a line below 2222222222, continue to use GIT status to see the results, as follows:

The above command tells us that the Readme.txt file has been modified but has not been committed.

Next I want to see what the Readme.txt file changed, how to view it? You can use the following command:

Git diff readme.txt is as follows:

As you can see, the contents of the Readme.txt file are changed from one line of 11111111 to two lines by adding a row of 22222222 content.

When we know what changes have been made to the Readme.txt file, we can safely submit it to the warehouse, and commit the changes and submit the file is the same as 2 steps (the first step is git add second step is: Git commit).

As follows:

Two: Version fallback:

As above, we have learned to modify the file, and now I continue to modify the Readme.txt file, and then add a line

The content is 33333333333333. Continue to execute the command as follows:

Now that I have made three changes to the Readme.txt file, I now want to check the history, how to check it? We can now use the command git log demo as shown below:

The git log command displays logs from the most recent to the farthest, and we can see the last three commits, the most recent being an increase of 333333. The last time you added content 222222, the first time by default is 111111. If too much information is displayed, we can use the command git The Log–pretty=oneline demo is as follows:

Now I want to use the version fallback operation, I want to fallback the current version to the previous version, what command to use? You can use the following 2 kinds of commands, the first is: Git reset–hard head^ Then if you want to fall back to the first version just change head^ to head^^ and so on. If you want to fall back to the first 100 versions, using the above method is certainly inconvenient, we can use the following simple command operation: Git Reset–hard head~100. The Readme.txt content before fallback is as follows:

If you want to fallback to the previous version of the command, do the following:

Check out the following Readme.txt content: View by command cat Readme.txt

As you can see, the content has been rolled back to the previous version. We can continue to use git log to view the following history information, as follows:

We saw an increase of 333333 content that we didn't see, but now I want to back to the latest version, such as: How to recover 333333 of the content? We can go back with the version number and use the command method as follows:

Git reset–hard version number, but now if I've turned off the command line or the version number of the 333 content, I don't know. How do you know the version number that adds 3333 content? The version number can be obtained from the following command: The Git reflog demo is as follows:

As we can see from the above display, the version number of the added content 3333 is 6fcfc89. We can order now.

Git reset–hard 6fcfc89 to recover. The demo is as follows:

You can see that the latest version is now available.

Three: Understand the difference between work area and staging area?

Workspace: The directory you see on your computer, such as the files in Testgit (except the. git hidden directory repository). or later, you need to create a new directory file, and so on is the workspace category.

Repository (Repository): The workspace has a hidden directory. Git, this does not belong to the workspace, this is the repository. The repository contains a lot of things, the most important of which is the stage (staging area), and Git automatically created the first branch master for us, and a pointer to master head.

As we said earlier, using Git to submit a file to the repository has two steps:

The first step is to add the file using git add, which is actually adding the file to the staging area.

The second step: Commit the change using git commit, which is actually committing all the contents of staging area to the current branch.

We continue to use demo to demonstrate the following:

We add a line in Readme.txt to 4444444, and then create a new file in the directory for the Test.txt content as test, we first use the command git status to see the next state, as follows:

Now let's use the git add command to add 2 files to staging area, and then use GIT status to see the next state, as follows:

Then we can use git commit to commit to the branch one at a time, as follows:

Four: Git undo Modify and delete file operations.

One: Undo changes:

For example, I now add a line to the Readme.txt file is 555555555555, we first through the command to see the following:

Before I did, I found that adding 5555555555555 was wrong, so I had to get back to the previous version right away, and now I can do the following in several ways:

First: If I know what to delete, just manually change the files that need to be removed, then add to staging area, and finally commit.

Second: I can revert to the previous version directly in the previous way. Using Git reset–hard head^

But now I do not want to use the 2 methods above, I would like to directly use the Undo command how to do? First, before we undo, we can look at the current state with Git status. As shown below:

As you can see, Git will tell you that git checkout-file can discard changes to the workspace, such as the following command:

Git checkout–readme.txt, as shown below:

The command git checkout–readme.txt means to undo all changes made to the Readme.txt file in the workspace, here are 2 cases, as follows:

1. Readme.txt automatically modified, has not been placed in the staging area, using undo changes back to the same state as the repository.
2. Another is that the Readme.txt has been put into the staging area, and then modified to undo the changes back to the state after the addition of staging area.

For the second case, I think we continue to do the demo to see, if now I add a line to Readme.txt 6666666666666, my git add to staging area, and then add the content 7777777, I want to undo the command to return to the state after staging area. As shown below:

Note: command git checkout-readme.txt-very important, if not-then the command becomes a branch of creation.

Two: Delete files.

If I now add a file B.txt to the Repository testgit directory, then commit. As follows:

As above: In general, you can delete the file directly in the file directory, or use the RM command as above: RM B.txt, if I want to completely delete this file from the repository, you can execute the commit command, and now the directory is like this,

As long as there is no commit, what if I want to recover this file in the repository?

You can use the following command for Git Checkout-b.txt, as follows:

Take a look at our Testgit catalog and add 3 files. As shown below:

V: Remote Repository.

Before you know it, sign up for a GitHub account, because the transfer between your local git repository and the GitHub repository is encrypted via SSH, so you need a bit of setup:

First step: Create an SSH Key. In the user home directory, see if there is no. ssh directory, if there is, then look at this directory there are no Id_rsa and id_rsa.pub these two files, if any, skip the following command directly, if not, open the command line, enter the following command:

Ssh-keygen-t rsa–c "[email protected]" because I have previously run it locally, so there are, as follows:

Id_rsa is the private key, can not be leaked out, Id_rsa.pub is the public key, may be assured to tell anyone.

Second step: Login to GitHub, open the SSH keys page in "Settings", then click "Add ssh Key", fill in any title, paste the contents of the Id_rsa.pub file in the Key text box.

Click on Add key and you should be able to see the key already added.

1. How do I add a remote library?

Now, after we've created a git repository locally, we want to create a git repository on GitHub, and we want the two warehouses to be synchronized remotely so that GitHub's warehouses can be backed up and others can collaborate through the warehouse.

First, log on to GitHub, and then find "create a new repo" in the upper-right corner of the repository. As follows:

In the repository name fill in testgit , the other remains the default settings, click the "Create Repository" button, the successful creation of a new Git repository:

At the moment, this warehouse on GitHub testgit is still empty, and GitHub tells us that we can clone a new repository from this repository, or associate an existing local repository with it, and then push the contents of the local repository to the GitHub repository.

Now, let's run the command under the local repository, based on GitHub's tips testgit :

Git remote add Origin https://github.com/tugenhua0707/testgit.git

All of the following:

Pushing the contents of the local library to the remote, using the git push command, is actually pushing the current branch master to the remote.

Since the remote library is empty, and when we first push the master branch, with the –u parameter, GIT will not only push the local master branch content to the remote new Master branch, but also associate the local master branch with the remote Master branch. You can simplify the command at a later push or pull. After the push succeeds, you can immediately see the remote Library's contents on the GitHub page as if it were local, and the user name and password to enter GitHub are as follows:

From now on, as long as the local commits, you can use the following command:

Git push Origin Master

The latest changes to the local master branch are pushed to GitHub, and now you have a real distributed repository.

2. How do I clone from a remote library?

We learned how to associate a remote library with a local library and then a remote library.

Now we think, if the remote library has new content, I want to clone to the local how to clone it?

First, log on to GitHub and create a new repository named Testgit2. BELOW:

As below, we see:

Now that the remote library is ready, the next step is to clone a local library using the command git clone. As shown below:

The Testgit2 directory is then generated in my local directory, as follows:

VI: Create and Merge branches.

In the release backfill, you already know that every time you commit, git strings them into a timeline, which is a branch of the line. As of now, there is only one time line, in Git, this branch is called the main branch, the Master branch. The head is strictly not pointing to the commit, but pointing to Master,master is pointing to the commit, so the head is pointing to the current branch.

First, let's create the dev branch and switch to the Dev branch. Do the following:

The git checkout command plus the –B parameter means create and switch, equivalent to the following 2 commands

Git branch Dev

git checkout Dev

Git branch The branch, lists all the branches, and adds an asterisk before the current branch. Then we'll continue with the demo on the Dev branch, like we're adding another line to the Readme.txt 7777777777777.

First we look at the next Readme.txt content, then add the content 77777777, as follows:

Now that the Dev branch is done, now we switch to the Master Branch Master and continue to view the Readme.txt content as follows:

Now that we can merge the contents of the dev branch onto the branch master, you can use the following command on the Master branch, git merge dev looks like this:

The git merge command merges the specified branch onto the current branch, merges, and then looks at the Readme.txt content, and you can see that the latest commit with the Dev branch is exactly the same.

Taking note of the fast-forward information above, Git tells us that this merger is a "fast-forward mode", which is to direct master to the current commit of Dev, so the merging is very fast.

Once the merge is complete, we can then delete the dev branch as follows:

Summarize the Create and merge Branches command as follows:

View branches: Git branch

Create a branch: Git branch name

Switch branches: git checkout name

Create + Switch branch: git checkout–b name

Merge a branch to the current branch: git merge name

Delete branch: git branch–d name

1. How to resolve conflicts?

Next, we will take a step-by-step, first create a new branch, such as the name Fenzhi1, add a line of content in Readme.txt 8888888, and then commit as follows:

Again, we now switch to the Master branch and add the content to the last line, with the content 99999999, as follows:

Now we need to merge Fenzhi1 on the Master branch, as follows:

Git uses <<<<<<<,=======,>>>&gt;>>> to mark different branches of content, where <<< Head refers to the content modified by the main branch, >>>>>FENZHI1 refers to the modified content on FENZHI1, we can modify the following after saving:

If I want to see the case of branch merging, I need to use the command git log. The command line demonstrates the following:

3. Branch management policies.

Usually when merging branches, Git uses "Fast forward" mode, in which the branch information is discarded after the branch is removed, and now we use the parameter –no-ff to disable "Fast forward" mode. First, let's Do the demo demo:

1. Create a dev branch.
2. Modify the Readme.txt content.
3. Add to Staging area.
4. Switch back to the main branch (master).
5. Merge Dev branch, use command git merge–no-ff-m "comment" Dev
6. View historical records

As follows:

branching strategy: first Master Main branch should be very stable, that is, to release the new version, generally do not allow work on the above, work in general in the new Dev branch work, after the completion, such as to publish, Or, if the dev branch code is stable, it can be merged into Master Branch master.

Seven: Bug branches:

In the development, will often encounter bug problems, then there is a bug need to fix, in Git, the branch is very powerful, each bug can be repaired by a temporary branch, after the completion of the repair, merge branches, and then delete the temporary branch.

For example, when I get a 404 bug in development, we can create a 404 branch to fix it, but the work on the current dev branch is not yet committed. such as the following:

It's not that I don't want to commit, but the work is done halfway through, and we're not able to commit it, such as my branch Bug, which takes 2 days to complete, but I issue-404 the bug in 5 hours. What do we do? Fortunately, Git also provides a stash feature that can "hide" the current work site, and then continue to work after resuming the site later. As follows:

So now I can fix the bug by creating a issue-404 branch.

First we want to make sure that the bug is fixed on that branch, for example, I'm now fixing it on the master Branch master, and now I'm going to create a temporary branch on the Master branch, which demonstrates the following:

After the repair is complete, switch to the master branch, complete the merge, and finally delete the issue-404 branch. The demo is as follows:

Now, we're back to work on the Dev branch.

The work area is clean, so where do we go on the job site? We can use the command git stash list to view the next. As follows:

Work site is still, git put stash content somewhere, but need to restore, can use the following 2 methods:

1. Git stash apply recovery, after recovery, stash content is not deleted, you need to use the command git stash drop to delete.
2. Another way is to use git stash pop, restore the stash content also deleted.

The demo is as follows

Eight: Multi-person collaboration.

When you clone from a remote repository, actually git automatically corresponds to the local master branch and the remote Master Branch, and the default name of the remote Library is origin.

1. To view information about a remote library using git remote
2. To view the details of a remote library using git remote–v

The following shows:

One: Push branch:

The push branch is to commit all local commits on the branch to the remote library, and when pushed, the local branch is specified so that git pushes the branch to the remote branch of the remote library:

Use the command GIT push Origin master

For example, my current Readme.txt code on GitHub is as follows:

The local Readme.txt code is as follows:

Now I want to push the locally updated Readme.txt code to the remote library using the following command:

We can see as above, push success, we can go on to GitHub on the Readme.txt content as follows:

You can see that the push is successful, and if we're going to push it to another branch, like the Dev branch, we're still the command GIT push Origin dev

So in general, what are those branches going to push?

1. The Master branch is the main branch, so synchronize with the remote at all times.
2. Some repair bug branches do not need to be pushed to remote, can be merged into the main branch, and then the main branch master to push to remote.

Two: Crawl branches:

When working with multiple people, everyone pushes their changes to the Master branch. Now we can simulate another colleague that can be on another computer (note to add SSH key to GitHub) or another directory clone on the same computer, create a new directory named Testgit2

But first I have to push the dev branch to the remote, as follows

Then go to the Testgit2 directory and clone the remote library to local, as follows:

Now the catalog is generated as follows:

Now that our little partner is developing on the dev branch, we have to branch the remote Origin's dev to local, so we can use the command to create the local dev branch: git checkout–b dev Origin/dev

Now the small partners can do development on the dev branch and push the dev branch to the remote library when the development is complete.

As follows:

The small partners have pushed the submission to the Origin/dev branch, and I have modified the same file in the same place under my directory file, as well as trying to push it to the remote library as follows:

From the above: Push failed, because my little partner recently submitted and I tried to push the conflict, the solution is also very simple, the above has prompted us to use Git pull the latest submissions from Origin/dev, and then merge locally, resolve conflicts, and then push.

git pull also failed because you did not specify a link to the local dev branch and the remote Origin/dev branch, and, as prompted, set up the links for Dev and origin/dev as follows:

This time git pull succeeds, but the merge conflicts, it needs to be solved manually, the solution is exactly the same as the conflict resolution in branch management. After resolving, submit, and then push:

We can take a look at Readme.txt content first.

Now that the manual has been solved, I need to submit it again and push it to the remote library. As shown below:

Therefore: the multi-person collaborative work mode is generally the case:

1. First, you can try to push your own changes with GIT push Origin branch-name.
2. If the push fails, because the remote branch is older than your local update, you need to first try to merge with Git pull.
3. If there is a conflict in the merge, the conflict needs to be resolved and committed locally. Then push origin branch-name with Git push.

The basic common commands for Git are:

MKDIR:XX (Create an empty directory XX refers to the directory name)

PWD: Displays the path to the current directory.

Git init turns the current directory into a manageable git repository, creating a hidden. git file.

git add xx adds xx files to the staging area.

Git commit–m "XX" commits a file –m followed by a comment.

Git Status View warehouse status

git diff xx View xx file modified those content

git log View history

git reset–hard head^ or git reset–hard head~ fallback to previous version

(If you want to fallback to 100 versions, use Git Reset–hard head~100)

Cat xx View XX file contents

Git reflog View history's version number ID

Git checkout-xx all the changes to the XX file in the workspace.

git rm xx Delete xx file

Git remote add Origin https://github.com/tugenhua0707/testgit associated with a distant library

Git push–u (not required for the first time with-U) Origin master pushes the current master branch to the remote library

git clone https://github.com/tugenhua0707/testgit cloning from a remote repository

git checkout–b dev Create dev branch and switch to Dev branch

Git branch view all current branches

Git checkout master switches back to the master branch

git merge dev branches on the current branch

git branch–d dev Delete Dev branch

GIT branch name to create a branch

Git stash to hide the current job and resume work after resuming the site.

Git stash list view all hidden file lists

Git stash apply to recover hidden files, but the content is not deleted

git Stash Drop Delete file

Git stash pop recovers files while also deleting files

Git Remote to view information

Git remote–v View details of remote libraries

Git push origin master git pushes the master branch to the remote branch corresponding to the remote library

Recommended! teach you to use Git