Git notes, git Study Notes

Git notes, git Study Notes

This blog on git says it has crashed. It's broken. Pay attention to this issue next time.

Create a project:

• Midir xx: Create xx folder
• Git init: Create a code repository for the current folder

Code submission:

• Git add xx: Save the file named xx and submit it to the code repository when you commit it.
• Git commit-m "xx": Add a description for the current commit

Check status:

• Git status: Check the status of the current repository to check whether there are uncommitted new files.
• Git log: view the change list

Single Row history

You can control the processing.logCommand to precisely display the content. I like the single line format:

$ git log --pretty=oneline

You should see:

$ git log --pretty=oneline1f7ec5eaa8f37c2770dae3b984c55a1531fcc9e7 Added a comment582495ae59ca91bca156a3372a72f88f6261698b Added a default value323e28d99a07d404c04f27eb6e415d4b8ab1d615 Using ARGV94164160adf8faa3119b409fcfcd13d0a0eb8020 First Commit

Control which entries are displayed

logThe command has many options to select which entry to display. Play with the following options:

$ git log --pretty=oneline --max-count=2$ git log --pretty=oneline --since='5 minutes ago'$ git log --pretty=oneline --until='5 minutes ago'$ git log --pretty=oneline --author=<your name>$ git log --pretty=oneline --all

Seeman git-logLearn more.

More beautiful

This is the command I used to review changes made last week. If I only want to view my changes, I will add--author=jim.

$ git log --all --pretty=format:'%h %cd %s (%an)' --since='7 days ago'

Ultimate log format

Over time, I found that I liked the following log formats most during work.

$ git log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short'

It looks like this:

$ git log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short* 1f7ec5e 2013-04-13 | Added a comment (HEAD, master) [Jim Weirich]* 582495a 2013-04-13 | Added a default value [Jim Weirich]* 323e28d 2013-04-13 | Using ARGV [Jim Weirich]* 9416416 2013-04-13 | First Commit [Jim Weirich]

Let's take a look at the details:

• --pretty="..."Define the output format
• %hIs the abbreviation of hash submission
• %dIs submitted Decoration (such as branch head or label)
• %adIs the creation date
• %sYes Annotation
• %anIs the author's name
• --graphUse ASCII Image Layout to display the submission tree
• --date=shortThe retention date format is better and shorter.

 

Obtain the old version:

• Git checkout
• Cat file name: for example, hello. rb
• Git checkout master: returns the latest version.

Tag versions

• Git tag xx: tag XX for the current version, such as git tag v1

Mark the previous version ====== and use the above method to obtain the old version, and then tag the current version.

• Git tag: Get all the tags in the log

Remove tags:

• Git tag-d xx: Remove tag xx

Undo the changes: (Here we use the hello. rb file as an example)

@ Confirm that you have submitted the latest master before processing ===" git checkout master;

@ Check the status. Check whether the changed content is cached or not submitted. Undo local changes ===" git status;

@ Use the checkout command to check out the changed file. The version in the repository takes the hello. rb file as an example.

$ Git checkout hello. rb // The local change is revoked. The following two statements are used to view the content of hello. rb $ git status $ cat hello. rb

 

　　　2. Revoke cache changes

　　　　@ Check the status and confirm that the changed content has been cached but not submitted. It is a withdrawal cache change ===" git status;

@ Clear the content of the temporary storage area ===" git reset HEAD hello. rb

@ Use the checkout command to check the submitted version (that is, the last submitted content) ===" git checkout hello. rb

3. Undo submitted changes

　　　　@ Use create a commit to remove the changes introduced by the unwanted commit ===" git reset HEAD

@ The preceding statement will go to the editor. You can edit the default submission information or exit it directly. Save and close the file. You will see:

$ git revert HEAD[master f98cb24] Revert "third commit" 1 file changed, 1 insertion(+), 3 deletions(-)

 

@ The second step is successful. Now let's check the submission record (here, git hist is a self-defined command, which can be viewed using git log ):

$ git hist* f98cb24 2016-04-04 | Revert "third commit" (HEAD -> master) [mecury]* da6b209 2016-04-04 | third commit [mecury]* d44641b 2016-04-04 | second commit (tag: v1) [mecury]* 46de4a5 2016-04-04 | First Commit (tag: v1-beta) [mecury]

 

Reset Branch:

First, mark the branch

But before we remove the submission, let's use a tag to mark the latest submission so that we can find it again.

$ git tag oops

Reset to Oops

Looking at the log history above, we will know that the submission marked as "v1" is correct before the error submission. Let's reset the branch to this location. Because the Branch has been marked, we canresetUse the tag name in the Command (if it is not marked, we can only use the hash value ).

$ git reset --hard v1$ git hist

$ git reset --hard v1HEAD is now at 1f7ec5e Added a comment$ git hist* 1f7ec5e 2013-04-13 | Added a comment (HEAD, v1, master) [Jim Weirich]* 582495a 2013-04-13 | Added a default value (v1-beta) [Jim Weirich]* 323e28d 2013-04-13 | Using ARGV [Jim Weirich]* 9416416 2013-04-13 | First Commit [Jim Weirich]

Our master branch now refers to submitting to v1, And Oops and Revert Oops are no longer in the branch.--hardThe parameter indicates that the working directory should be updated to be consistent with the new branch header.

Nothing left

But what happened to the wrong submission? The result is that the submission is still in the repository. In fact, we can still reference them. Remember that at the beginning of this experiment, we marked the restore submission with the tag "oops. Let's take a look at all the submissions.

$ git hist --all

$ git hist --all* a10293f 2013-04-13 | Revert "Oops, we didn't want this commit" (oops) [Jim Weirich]* 838742c 2013-04-13 | Oops, we didn't want this commit [Jim Weirich]* 1f7ec5e 2013-04-13 | Added a comment (HEAD, v1, master) [Jim Weirich]* 582495a 2013-04-13 | Added a default value (v1-beta) [Jim Weirich]* 323e28d 2013-04-13 | Using ARGV [Jim Weirich]* 9416416 2013-04-13 | First Commit [Jim Weirich]

Here we can see that the incorrect submission does not disappear. They are still in the repository. They are not listed in the master branch. If we do not mark them, they are still in the repository, but there is no other way to reference them except using hash values. Unreferenced submissions are retained in the repository until the system runs the garbage collection software.

Correction submission:

Change Programs and submit

Add author comments to the program.

# Default is World# Author: Jim Weirichname = ARGV.first || "World"puts "Hello, #{name}!"

$ git add hello.rb$ git commit -m "Add an author comment"

Alas, there should be an Email.

After you submit the Email, you realize that any good author comment should contain an Email address. Update the hello program to include Email.

# Default is World# Author: Jim Weirich (jim@somewhere.com)name = ARGV.first || "World"puts "Hello, #{name}!"

Corrected previous submissions

We really don't want to submit the Email separately. Let's fix previous submissions to include Email changes.

$ git add hello.rb$ git commit --amend -m "Add an author/email comment"

$ git add hello.rb$ git commit --amend -m "Add an author/email comment"[master eb30103] Add an author/email comment 1 files changed, 2 insertions(+), 1 deletions(-)

Review history

$ git hist

$ git hist* eb30103 2013-04-13 | Add an author/email comment (HEAD, master) [Jim Weirich]* 1f7ec5e 2013-04-13 | Added a comment (v1) [Jim Weirich]* 582495a 2013-04-13 | Added a default value (v1-beta) [Jim Weirich]* 323e28d 2013-04-13 | Using ARGV [Jim Weirich]* 9416416 2013-04-13 | First Commit [Jim Weirich]

We can see that the original "author" submission is now gone, and it has been submitted and replaced by "author/email. By resetting the Branch to a certain commit and submitting new changes, you can achieve the same effect.

Move files:

• Mkdir xx: Create a XX file in the current folder.
• Git mv hello. rb lib ==> move the hello. rb file to the lib folder
• Git status: Check the following status:

$ git statusOn branch masterChanges to be committed:  (use "git reset HEAD <file>..." to unstage)        renamed:    hello.rb -> lib/hello.rbChanges not staged for commit:  (use "git add <file>..." to update what will be committed)  (use "git checkout -- <file>..." to discard changes in working directory)

• Git commit-m "xxxx": Submit this change

By using Git to move files, we notified Git of two things:

 

 

Git create Branch

Git checkedou-B greet // creates a new branch named greet.

! The preceding statement is short for git branch branchname and git checkout branchname (branchname: branch name)

Navigation Branch

Git checkout master // switch to the master Branch

Git checkout branchname: Switch to branch branchname

When there are two or more branches, use

Git hist -- all // -- all indicates all branches.

Merge Branch

Git merge master // merge the branch mster to the current Branch

Conflict arises from resolution (too many pitfalls, just for example)

Switch the branch to the master node. Changing hello. rb and submitting will cause a conflict.
Cause: the master has been merged with the greet branch, but a new commit has not been merged back to greet In the master, resulting in a conflict.

 

If the greet branch is returned and the master branch is merged, check hello. rb,

Conflict Resolution: Correct in hello. rb and submit hello. rb again.

After solution:

Address Change vs Merge (unknown problem: an error occurs when the master branch is reset immediately after the greet branch is reset. It seems that all files need to be submitted again)

An error occurred while changing the base.

 

Create a contact with a remote warehouse

View All remote connection information

git remote -v

View Details of a remote connection

git remote show [remote-name]

Add a Common Remote repository for the local devicegit remote add pb git://github.com/paulboone/ticgit.gitPb is the alias of the warehouse, followed by the warehouse address

Add a local origin Repository

Git remote add origin [repository url]

Rename a remote connectiongit remote renamed [old name] [new name]

Delete remote Repositorygit remote rm [shortname]

Difference between pull and fetch:

1. git fetch is equivalent to obtaining the latest version from a remote device to the local device, without automatic mergegit fetch origin master

2. When git pull gets the latest version from a remote device and merge to the local device

Git submits code to github

1. Create a new version Library
In GitHub, a project corresponds to a version library, and a new version library is created to create a new project.

Create a new version library in GitHub, clone it first, and then initialize the GitHub version library through push. The procedure is as follows:

1. Clone the version Library:

Git clone git@github.com: mecury/HelloWorld. git // mecury is the name of the registration, HelloWorld is the new version library </br>

2. Add the README. md file and submit it (this can also be modified directly in GitHub)

git add REAMDE.md

3. Push to GitHub to complete version library Initialization

git push origin master

2. Create an existing version Library

To upload a project, you must first create a local repository.

Git init // under the root directory of the current project

Add the README. md file to the file and submit the file (which can be omitted)

git add README.mdgit commit -m"README for project"

Execute push command

git push -u origin master

The Force push command will overwrite the differences between the remote warehouse

git push -f origin master

 

Exit the vim editor of git:

1. Press I to enter the insert edit mode.

2. After editing, Press esc

3. Input: wq! And press enter to delete the file.