Git remote add origin [email protected]:xxxxx.git checkout -b ZTQ origin/reviewIndex Git pull origin reviewIndex git pull origin reviewIndex git pull origin reviewIndex Git commit -m" here is the log that is committed "// commit to the local repository git push origin ZTQCopy the codeWhat is Git
Git is the most advanced distributed version control system in the world. Working Principle/process:
How Git works
- -Jenny: Well, I’m working in a Workspace.
- Index/Stage: temporary storage area
- A Repository is a Repository.
- Remote: Remote repository
What are the major differences between SVN and Git?
The SVN is a centralized version control system. The version library is stored on the central server in a centralized manner. Therefore, users need to obtain the latest version from the central server first and then work on their own computers. Centralized version control systems must be connected to the Internet to work, if it works on a LAN, bandwidth is big enough, speed is fast enough, if it works on the Internet, if the Internet speed is slow, you wonder.
Git is a distributed version control system, so there is no central server. Everyone’s computer is a complete version library, so there is no need to work online, because the versions are on their own computer. Since everyone’s computer has a complete version library, how can multiple people collaborate? For example, if you change file A on the computer, and someone else changes file A on the computer, you can just push your changes to each other, and then you can see each other’s changes.
Three, how to operate?
1. Create a version library
What is a version library? Git keeps track of all changes and deletions of files in a repository, so that they can be traced at any time in history or “restored” at any time in the future. Create a testGit repository on disk D — > WWW.
The PWD command is used to display the current directory. To make this directory a git repository, run git init as follows:
Git is a directory where you can track and manage your own versions of the testGit repository. As follows:
Let’s first look at the demo as follows:
Git add readme. TXT add git add readme. TXT add git add readme. TXT add git add readme. TXT As follows:
If, as above, there is no warning, the addition is successful.
Step 2: Use git commit to tell Git to commit the file to the repository.
Git status git status git status git status git status
There are no uncommitted files, but I will continue to change the readme. TXT content. For example, I will add a line 2222222222 below, and continue to use git status to check the result, as follows:
The command above tells us that the readme.txt file has been modified, but not committed. Add the file to the repository.
Must first clear, all of the version control system, can track the change of a text file, such as TXT file, page, all the procedures of code, etc., and such is Git, changes in the version control system can tell you every time, but the pictures and video of these binary file, although can also can be managed by a version control system, but not the change of the trace file, You can only string together every change to the binary file, that is, the image changes from 1KB to 2KB, but version control doesn’t know what the change is.
Next I want to see what has been changed in the readme.txt file. You can use the following command:
As you can see above, the readme. TXT file is changed from one line 11111111 to two lines, adding one line 22222222. Now that you know what changes have been made to the readme.txt file, you can commit it to the repository without any worry. The first step is git add and the second step is Git commit.
2. Roll back the version
Now that we’ve learned how to modify the file, I’ll go ahead and modify the readme.txt file by adding 33333333333333. To continue, run the following command:
Now that I have made three changes to the readme.txt file, I want to check the history. How do I check? We can now demonstrate this using the command git log as follows:
The git log command displays the display logs from the most recent to the most recent. We can see the last three commits, the most recent is 333333. Git log — pretty=oneline git log — pretty=oneline
Now I want to use the version rollback operation. I want to roll back the current version to the previous version. What command do I use? Git reset –hard HEAD^ to go back to the previous version, change HEAD^ to HEAD^ and so on. Git reset –hard HEAD~100 git reset –hard HEAD~100 The contents of readme. TXT before rollback are as follows:
To roll back to the previous version, run the following command:
Run the cat readme. TXT command to check the readme. TXT file.
As you can see, the content has fallen back to the previous version. We can continue to use git log to view the historical record information as follows:
We have seen the addition of 333333 content, which we have not seen, but now I want to go back to the latest version, such as: how to restore the content of 333333? We can roll back the version number using the following command
Git reset –hard version number, but now what if I have turned off the command line or 333 content once and I don’t know the version number? How do I know the version number to add 3333 content? Git reflog git reflog git reflog
From the above display, we can know that the version number of the added content 3333 is 6fCFc89. Git reset –hard 6fcfc89 The demo is as follows:
As you can see, this is the latest version.
3. Understand the difference between workspaces and staging areas?
Workspace: the directory you see on your computer, such as the files in the testGit directory (except for the.git hidden directory version library). Or the directory files that need to be created again later belong to the workspace category.
Git: Repository: a workspace has a hidden directory. Git does not belong to the workspace, it is a Repository. Git automatically creates the first branch, master, and a HEAD pointer to master.
The first step is to add the file to the repository with Git Add, which essentially adds the file to the staging area. Step 2: Commit the changes using git commit, which essentially commits the entire contents of the staging area to the current branch.
Git status git status git status git status git status git status git status git status git status git status git status git status
Git add command to add both files to the staging area, and then use git status to check the status.
Git commit > git commit > git commit > Git commit > Git commit
4. Git undoes modification and deletes files
For example, if I add a line to the readme. TXT file, the content is 5555555555.
Before I submitted it, I found that adding 55555555555 was wrong, so I had to restore the previous version immediately. Now I can make changes in the following ways:
- If I know what to delete, I just manually remove the files I need, add them to the staging area, and commit them.
- I can go back to the previous version the same way. Git reset –hard HEAD^
But now I don’t want to use the above two methods, I want to directly use the undo command how to operate? Git status check git status check git status check git status check git status As follows:
Git checkout –readme. TXT git checkout –readme. TXT git checkout –readme. TXT git checkout –readme. TXT git checkout –readme. TXT
- The readme. TXT file is not in the staging area, and the readme. TXT file is in the same state as the readme. TXT file.
- The other option is readme. TXT, which is already in the staging area and then modified, and then unmodified to return to the status after the staging area was added.
For the second case, I want to continue to do a demo, suppose now I add a line of readme. TXT 66666666666, I add git add to the staging area, then add 7777777, I want to undo the command to return it to the staging area after the state. As follows:
Note: the git checkout — readme.txt command is important, but without — the command becomes create branch.
Add a file to the testGit directory and commit it. As follows:
If I want to delete the file from the repository completely, I can run the commit command to delete the file.
What if I want to restore this file in the repository before committing? Git checkout — b.tabs git checkout — b.tabs
Looking at our testGit directory, we’ve added three files. As follows:
Remote warehouse
Create an SSH Key in the user’s home directory and check if there is a. SSH directory. If there is no SSH directory, go to step 2. If so, check whether the id_rsa.pub or id_dsa.pub file already exists. If so, you can skip Step 2 and go straight to Step 3.
$ cd ~./ssh
Copy the codeStep 2: Add SSH
$ ssh-keygen -t rsa -C "[email protected]"
Copy the code-t Specifies the key type. The default key is RSA and can be omitted. -c Sets comment text, such as email. -f Specifies the name of the key file.
The above code omits the -f argument, so running the above command will cause you to enter a filename to save the SSH key code you just generated, as in:
Generating public/private rsa key pair.
# Enter file in which to save the key (/c/Users/you/.ssh/id_rsa): [Press enter]
Copy the codeOf course, you can omit the file name and use the default file name (recommended), which will generate id_rsa and id_rsa.pub.
You will then be prompted for the password twice (the one you used to push the file, not the github administrator’s), or you can skip the password and press Enter. Then there is no need to input the password when pushing, and it can be directly submitted to Github, for example:
Enter passphrase (empty for no passphrase):
# Enter same passphrase again:
Copy the codeThe following code prompt is displayed, for example:
Your identification has been saved in /c/Users/you/.ssh/id_rsa.
# Your public key has been saved in /c/Users/you/.ssh/id_rsa.pub.
# The key fingerprint is:
# 01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db [email protected]
Copy the codeWhen you see the above code, it means that your SSH key has been created successfully. All you need to do is add it to github’s SSH key.
Step 3: Add your SSH key to Github
- Set up a Github account
2. Click the user name profile picture and select Settings to go to the next page to configure the public key, as shown below:
The content of the public key is the content of the id_rsa.pub file and cannot contain Spaces
4. Create the project repository, click the “+” icon next to the user’s profile picture, and select New Repository to complete the repository configuration:
Currently, the TestGit repository on GitHub is empty, and GitHub tells us that you can clone a new repository from the repository or associate an existing local repository with it.
Step 4: Push content from the local repository to the GitHub repository
Now let’s follow GitHub’s prompt and run the command in our local TestGit repository:
$ git remote add origin https://github.com/tugenhua0707/testgit.git
Copy the codeTo push the contents of a local repository to a remote location, use git push to push the current branch master to a remote location.
Git will not only push the contents of the local master branch to the new remote master branch, but also associate the local master branch with the remote master branch. The command can be simplified later when pushing or pulling. The github user name and password must be entered as follows:
From now on, whenever a local commit is made, the following command can be used:
$ git push origin master
Copy the codePush the latest changes from your local master branch to Github, and now you have a truly distributed repository.
1. How do I clone from a remote library?
Above we learned how to associate remote libraries with local libraries before remote libraries. Now let’s say I have something new in the remote library, and I want to clone it locally how do I clone it? First, log on to Github and create a new repository called Testgit2. As follows:
As follows, we see:
Now that the remote library is ready, the next step is to clone a local library using the command git clone. As follows:
The testgit2 directory is generated in my local directory as follows:
2. Create and merge branches
In version rollback, you already know that every commit, Git strings them into a timeline, and that timeline is a branch. So far, there is only one timeline. In Git, this branch is called the master branch. HEAD doesn’t technically point to the commit, it points to the master, and the master points to the commit, so HEAD points to the current branch. First, let’s create the dev branch, and then switch to the dev branch. The operations are as follows:
Git branch dev git checkout dev git branch Then we’ll continue with the demo on the dev branch, for example we’ll now add another line 77777777777 to readme.txt
Read the readme. TXT file and add 77777777 as follows:
Now that the dev branch is complete, let’s switch to the master branch and continue with readme.txt as follows:
Git merge dev git merge dev git merge dev git merge dev
Git merge the git merge command is used to merge the dev branch into the dev branch. Git is going to Fast forward this merge by pointing the master directly to dev’s current commit, so it’s going to be very Fast. Now that the merge is complete, we can remove the dev branch as follows:
Summary create and merge branch commands as follows:
Git checkout -- b name -- merge a branch with the current branch: git merge name -- merge a branch with the current branch Git branch - d nameCopy the code2. How to resolve conflicts?
Create a new branch, say fenzhi1, add a line 8888888 to readme.txt, and commit as follows:
Again, let’s switch to the master branch and add 99999999 on the last line as follows:
Now we need to merge fenzhi1 on the master branch as follows:
Git uses <<<<<<<, =======, >>>>>>> to mark the content of different branches, where <<>>>>fenzhi1 refers to the content changed on fenzhi1, we can modify the following and save:
If I want to check the branch merge, I need to use the git log command line to demonstrate the following:
3. Branch management policies
Git uses the “Fast Forward” mode to merge branches. In this mode, the branch information will be discarded when the branch is deleted. Let’s start with a demo: create a dev branch. Modify the readme.txt content. Add to staging area. Switch back to the master branch. Merge the dev branches and use git merge — no-ff -m to “comment” dev to view the history
Branch strategy: First of all, the master branch should be very stable, that is, used to release new versions. It should not be allowed to work on it. It should work on the new dev branch, after it is done, for example, the dev branch should be released, or the dev branch can be merged into the master branch once the code is stable.
4. The bug branch
In Git, branches are very powerful, and each bug can be fixed by a temporary branch. After the repair is complete, merge the branches, and then delete the temporary branch. For example, when I receive a 404 bug in development, we can create a 404 branch to fix it, but the current work on the dev branch has not yet been committed. For example:
It’s not that I don’t want to submit it, but we still can’t submit it halfway through the work. For example, I need 2 days to complete the branch bug, but I need 5 hours to complete the issue-404 bug. What to do? Fortunately, Git also provides a Stash feature that can “hide” the current work site and resume work later when the site is restored. As follows:
So now I can fix the bug by creating the issue-404 branch. First we need to determine which branch to fix the bug on. For example, I am fixing the bug on the master branch. Now I want to create a temporary branch on the Master branch.
Once the fix is complete, switch to the Master branch, complete the merge, and finally remove the issue-404 branch. The demo is as follows:
Now we’re back to working on the Dev branch.
The workspace is clean, so where do we go to work site? Check this out using the git stash list command. As follows:
The workspace is still there, Git has stash content in place, but you need to restore it using the following 2 methods:
- After the restore, the stash contents are not deleted. You need to use the git stash drop command to delete them.
- Another option is to use git Stash pop, which removes the stash content while restoring.
Demonstrate the following
5. Collaborate with multiple people
When you clone from a remote repository, Git actually automatically maps the local master branch to the remote master branch, and the default name of the remote repository is Origin.
- To view information about remote libraries use Git Remote
- To view details about remote libraries use git remote -v
The following presentation
1. Push branch: Push branch is to commit all local branches of the branch to the remote library. When push branch, specify the local branch, so that Git will push the branch to the corresponding remote branch of the remote library: Git push origin master git push origin master git push origin master git push origin master
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 the above, push successfully, we can continue to screenshot the readme. TXT content on Github as follows:
We can see that the push succeeded. If we now want to push to another branch, such as the dev branch, we will still use the same command
$ git push origin dev
Copy the codeSo in general, which branches are pushed? The master branch is the primary branch and therefore synchronizes with the remote at all times. Some bug-fixing branches do not need to be pushed remotely, but can be merged to the master branch and then pushed to the remote branch.
2. Fetching branches: When people collaborate, everyone pushes their changes to the Master branch. Now we can impersonate another colleague. We can clone another directory on another computer (note that SSH key is added to Github) or another directory on the same computer. We will create a new directory called testgit2, but I will first push the dev branch to the remote as follows
Then go to testgit2 and clone the remote library to the local directory as follows:
Now the generated directory looks like this:
Dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch = dev branch
$git checkout -- b dev origin/devCopy the codeNow you can develop on the dev branch and push the dev branch to the remote library. As follows:
The origin/dev branch has been pushed to commit to the origin/dev branch, and I have made changes to the same file in the same place in my directory file, and also tried to push to the remote library, as follows:
The latest submission submitted by my friend conflicts with the one I am trying to push. The solution is also very simple. We are advised to use Git pull first to grab the latest submission from Origin /dev, then merge it locally to resolve the conflict and push it again.
Git pull fails because the origin/dev branch is not linked to the origin/dev branch. Git pull fails because the origin/dev branch is linked to the origin/dev branch.
This git pull is successful, but the merge has conflicts that need to be resolved manually in the same way that conflicts are resolved in branch management. After that, push: We can look at the readme.txt content first.
Now that manual work is done, I need to submit it again and push it to the remote library. As follows:
First, you can try to push your own changes with Git push Origin branch-name. If the push fails, you will need to try merging with Git pull first because the remote branch updates earlier than your local branch. If the merge has conflicts, they need to be resolved and committed locally. Git push origin branch-name