Git basic operation

Git's job is to create and save snapshots of your project and compare them with subsequent snapshots.

This chapter describes the commands for creating and submitting snapshots of your project.

Git commonly uses the following six commands: git clone, git push, git add, git commit, git checkout and git pull, which will be described in detail later.

explain:

• Workspace: workspace
• Staging area: staging area / cache area
• Local repository: version library or local repository
• Remote repository: remote repository

A simple procedure:

$ git init    
$ git add .    
$ git commit  

• git init - initialize the warehouse.
• git add . - Add files to staging area.
• git commit - adds the contents of the staging area to the warehouse.

Create warehouse command

The following table lists git commands for creating warehouses:

command	explain
git init	Initialize warehouse
git clone	Copy a remote warehouse, that is, download a project.

$ mkdir runoob
$ cd runoob/
$ git init

$ git clone https://github.com/tianqixin/runoob-git-test
$ cd simplegit/
$ ls
README.md    runoob-test.txt    test.txt

To clone a warehouse, you must first know the address of the warehouse, and then clone it with the git clone command.

Git supports a variety of protocols, including https, but ssh is the fastest.

In addition to the slow speed of using https, the biggest trouble is that you must enter a password for each push. However, in some companies that only open the http port, you can't use the ssh protocol but only https.

Submission and modification

Git's job is to create and save snapshots of your project and compare them with subsequent snapshots.

The following table lists commands for creating and submitting snapshots of your project:

command	explain
git add	Add files to staging area
git status	View the current status of the warehouse and display the changed files.
git diff	Compare the differences between files, that is, the differences between staging area and workspace.
git commit	Submit staging area to local warehouse.
git reset	Fallback version.
git rm	Delete workspace file.
git mv	Move or rename workspace files.

Add and submit

#Add all files in the current directory to the staging area
$ git add .
#Add the specified directory to the staging area, including subdirectories:
$ git add [dir]
#Add one or more files to the staging area:
$ git add [file1] [file2] ...
#Usually we use the - s parameter to get a short output.
$ git status -s


#-a after the parameter setting is modified, it is not necessary to execute the git add command. The [message] can be some remarks.
$ git commit -a -m 'message'
$ git commit -m 'message'


We can use --oneline Option to view a concise version of the history.
$ git log --oneline

Version fallback

--mixed It is the default and can be used to reset the file in the staging area and the last submission without this parameter(commit)Keep consistent, and the content of the workspace file remains unchanged.
$ git reset HEAD^            # Back out all content to the previous version  
$ git reset HEAD^ hello.php  # Fallback hello PHP file version to previous version  
$ git reset  052e           # Fallback to the specified version

--hard Parameter undo all uncommitted modifications in the workspace, return the staging area and workspace to the previous version, and delete all previous information submissions:

$ git reset –-hard HEAD~1  # Back to previous version  
$ git reset –-hard bae128  # All information before fallback to a version fallback point. There is no need to write the version number completely. The first few digits are OK. Git will automatically find it.
$ git reset --hard origin/master    # Fallback the local state to the same as the remote state 

Note: now, you go back to a certain version, turn off the computer, and regret the next morning. What if you want to restore to a new version? What if the new version of commit id cannot be found?

In git, there is always regret medicine to take. When you use $git reset --hard HEAD ^ to go back to the add distributed version, if you want to restore to the append GPL, you must find the commit id of the append GPL. Git provides a command git reflog to record your every command:

$ git reflog
e475afc HEAD@{1}: reset: moving to HEAD^
1094adb (HEAD -> master) HEAD@{2}: commit: append GPL
e475afc HEAD@{3}: commit: add distributed
eaadf4e HEAD@{4}: commit (initial): wrote a readme file

HEAD Description:

• HEAD indicates the current version

• HEAD ^ previous version

• HEAD ^ ^ previous version

• HEAD ^ ^ previous version

It can be represented by numbers

• HEAD~0 indicates the current version
• HEAD~1 previous version
• Previous version of HEAD^2
• Previous version on HEAD^3
• And so on

Management modification

#Show differences between staging and workspace:
$ git diff [file]

How does git track changes? If Git is not added to the temporary storage area for each change, it will not be added to the commit.

Undo modification

You can find that Git will tell you that git checkout -- file can discard changes in the workspace:

$ git checkout -- readme.txt

Command git checkout -- readme Txt means to put readme The modification of txt files in the workspace is completely revoked. There are two cases:

One is readme As like as two peas, TXT has not been put in the temporary storage area since it has been modified.

One is readme Txt has been added to the staging area and modified. Now, undo the modification and return to the state after adding to the staging area.

In short, it is to return the file to the state of the last git commit or git add.

Now, look at readme Txt file content:

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.

The contents of the file were restored.

git checkout -- one of the file commands -- is very important. Without --, it becomes the command of "switching to another branch". We will encounter the git checkout command again in the later branch management.

Now suppose it's 3 a.m., you not only write some nonsense, but also git add to the temporary storage area:

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN.

$ git add readme.txt

Fortunately, you found this problem before commit. Check with git status. The modification has only been added to the temporary storage area and has not been submitted yet:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   readme.txt

Git also tells us that the command git reset head < File > can undo the modification of the staging area and put it back into the workspace:

$ git reset HEAD readme.txt
Unstaged changes after reset:
M	readme.txt

The git reset command can either roll back the version or the modification of the staging area to the workspace. When we use HEAD, it means the latest version.

Check git status again. Now the staging area is clean and the workspace has been modified:

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   readme.txt

Remember how to discard workspace changes?

$ git checkout -- readme.txt

$ git status
On branch master
nothing to commit, working tree clean

The whole world is finally quiet!

Now, suppose you not only correct something wrong, but also submit it from the temporary storage area to the version library. What should you do? Remember the version fallback section? You can go back to the previous version. There is no condition for you to push your own version to the remote library. Remember Git is a distributed version control system? We will talk about the remote version library later. Once you push the stupid boss submission to the remote version library, you will be really miserable

• Summary

It's time to summarize again.

Scenario 1: when you change the contents of a file in the workspace and want to discard the changes in the workspace directly, use the command git checkout -- file.

Scenario 2: when you not only mess up the contents of a file in the workspace, but also add it to the temporary storage area, if you want to discard the modification, there are two steps. In the first step, use the command git reset head < File >, and then return to scenario 1. In the second step, operate according to scenario 1.

Scenario 3: when an inappropriate modification has been submitted to the version library, if you want to cancel this submission, refer to the version fallback section, but only if it is not pushed to the remote library.

Delete file

The following instances are deleted from staging and workspace runoob.txt File:
$ git rm runoob.txt 
If the deletion has been modified before and has been put into the staging area, the forced deletion option must be used -f. 
Forcibly delete the modified from the staging area and workspace runoob.txt File:
$ git rm -f runoob.txt 
It can be deleted recursively, that is, if a directory is followed as a parameter, all subdirectories and files in the whole directory will be deleted recursively:
$ git rm –r *
$ git commit -m "remove"

Another case is that the deleted file is wrong. Because there are still files in the version library, it is easy to restore the wrongly deleted file to the latest version:

$ git checkout -- test.txt

git checkout actually replaces the version of the workspace with the version in the version library. No matter whether the workspace is modified or deleted, it can be "restored with one click"

The command git rm is used to delete a file. If a file has been submitted to the version library, you never have to worry about accidental deletion, but be careful. You can only restore the file to the latest version, and you will lose the content you modified after the last submission.

Commit log

command	explain
git log	View submission history
git blame <file>	View the modification history of the specified file in the form of a list

Remote operation

command	explain
git remote	Remote warehouse operation
git fetch	Get code base from remote
git pull	Download remote code and merge
git push	Upload remote code and merge

Show all remote warehouses:
$ git remote -v
 Display information for a remote warehouse:
$ git remote show [remote]


Add remote version Library:
git remote add [shortname] [url]
shortname The local version of the library is, for example:
# Submit to Github
$ git remote add origin git@github.com:tianqixin/runoob-git-test.git
# Push all contents of local library to remote library
$ git push -u origin master
 Note: since the remote library is empty, we push it for the first time master When branching, add-u Parameters, Git Not only will the local master Remote branch content push master Branches, and local master Branch and remote master Branches are associated, and commands can be simplified when pushing or pulling in the future.

git remote rm name  # Delete remote warehouse
git remote rename old_name new_name  # Modify warehouse name

git pull <Remote host name> <Remote branch name>:<Local branch name>
$ git pull
$ git pull origin
 Connect remote host origin of master The branch is pulled over and connected with the local brantest Branch merge.
$ git pull origin master:brantest
 If the remote branch is merged with the current branch, the part after the colon can be omitted.
$ git pull origin master

git push <Remote host name> <Local branch name>:<Remote branch name>
If the local branch name is the same as the remote branch name, you can omit the colon:
git push <Remote host name> <Local branch name>
The following command will the local master Branch push origin Mainframe master Branch.
$ git push origin master
 Equal to:
$ git push origin master:master

To associate a remote library, use the command git remote add origin git@server-name:path/repo-name.git；

When associating a remote library, you must specify a name for the remote library. origin is the default custom name;

After association, use the command git push -u origin master to push all the contents of the master branch for the first time;

Thereafter, after each local submission, you can use the command git push origin master to push the latest modification as long as necessary;

One of the biggest benefits of the distributed version system is that working locally does not need to consider the existence of remote libraries, that is, it can work normally with or without networking, while SVN refuses to work when there is no networking! When there is a network, it is very convenient to push the local submission to complete the synchronization!