Git usage summary, git Summary

Git usage summary, git Summary

When we use Git push to github, the following error occurs: "error: failed to push some refs to" solution: Use git pull and then git push

After playing git for one night, let's summarize the following:

User settings

$ git config --global user.name "Your Name"$ git config --global user.email "email@example.com"

Initialize a repository

$ git initInitialized empty Git repository in /Users/learngit/.git/

Add a file to a repository

git add filename

Submit the file to the repository

git commit -m "comment message"

Initialize a Git repository and use the git init command.

Add the file to the Git repository in two steps:

• Step 1: run the git add command. Note that you can use it multiple times to add multiple files;

• Step 2: Run git commit.

Run the git status Command to check the result.

git status

But if you can see what has been modified

git diff filename

• You can use the git status Command to understand the status of the workspace at any time.

• If git status tells you that a file has been modified, you can use git diff to view the modification content.

The version control system certainly has a command that tells us the history. In Git, we use the git log command to view

git loggit log --pretty=oneline

First, Git must know which version the current version is. In Git, use HEAD to indicate the current version, that is, the latest submission. The previous version is HEAD ^, the previous version is HEAD ^. Of course, it is easier to write 100 ^ in 100 versions, so it is written as HEAD ~ 100.

git reset --hard HEAD^git reset --hard 3628164

Git provides the git reflog command to view the history.

git reflog

• The version pointed to by HEAD is the current version. Therefore, Git allows us to shuttle between versions and use the command git reset -- hard commit_id.

• You can use git log to view the submission history to determine the version to be rolled back.

• To return to the future, use git reflog to view the command history to determine which version to return.

Working Directory: the Directory you can see on your computer. For example, my learngit folder is a work zone.

Repository: there is a hidden directory ". git" in the workspace. This is not a workspace, but a Git Repository.

The Git version library stores a lot of things, the most important of which is the stage (or index) temporary storage zone, and the first branch master that Git automatically creates for us, and a pointer to the master is HEAD.

As mentioned above, when we add files to the Git version library, we perform the following two steps:

The first step is to use "git add" to add the file, which is actually to add the modification to the temporary storage area;

The second step is to use "git commit" to submit changes. In fact, it is to submit all the content in the temporary storage area to the current branch.

 

Git checkout -- file can discard workspace modifications

git checkout -- filename

The "--" in the git checkout -- file command is very important. Without "--", it becomes the "Create a new branch" command.

 

Run the git reset HEAD file command to undo the modification of the temporary storage area (unstage) and put it back into the workspace.

git reset HEAD  filename

The git reset command can be used to roll back the version or to the workspace. When we use HEAD, it indicates the latest version.

 

Scenario 1: When you change the content of a file in the workspace and want to discard the modification, run git checkout -- file.

Scenario 2: When you not only disrupt the content of a file in the workspace, but also add the file to the temporary storage area, you want to discard the modification in two steps. The first step is to use the command git reset HEAD file, return to scenario 1. Step 2: perform operations based on scenario 1.

 

To delete the file from the version library, run the git rm command to delete the file and run the commit command.

git rm test.txtgit commit -m "remove test.txt"

Another case is that the file is deleted incorrectly. Because there is still a version library, you can easily restore the accidentally deleted file to the latest version.

git checkout -- test.txt

Git checkout replaces the version of the workspace with the version in the version library. You can "Restore it with one click" Whether the workspace is modified or deleted ".

Run git rm 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 that you can only restore the file to the latest version, you will lose the content you modified after the last submission.

 

Remote Repository

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

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

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

 

Run git to clone a local database

// Source code of Git itself you can use git: // protocol to access: git clone git: // git.kernel.org/pub/scm/git/git.git//you can also access: git clone http://www.kernel.org/pub/scm/git/git.git through HTTP protocol

Git Branch

View branch: git branch

Create branch: git branch name

Switch branch: 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

 

Merge the content of the dev branch under the current branch.

git merge dev

When Git cannot automatically merge branches, the conflict must be resolved first. After resolving the conflict, submit it again and merge it.

Run the git log-graph command to view the branch merge graph.

 

In actual development, branch management should follow several basic principles:

First of all, the master branch should be very stable, that is, it is only used to release new versions, and usually cannot work on it;

Where can I work? All work is on the dev branch. That is to say, the dev branch is unstable. at a certain time, for example, when version 1.0 is released, the dev branch is merged to the master, release Version 1.0 on the master branch;

Everyone you and your friends work on the dev branch. Everyone has their own branch. You can merge them on the dev branch from time to time.

 

Git also provides a stash function to "Store" the current work site and resume the work after it recovers:

git stash

Now, using git status to view the work zone is clean (unless there are any files managed by Git), so you can safely create branches to fix bugs.

First, determine the branch on which the bug will be fixed. If the bug needs to be fixed on the master branch, create a temporary branch from the master:

// Convert to the master branch git checkout master // The Branch git checkout-B issue-101 created and converted

 

Git stash list

git stash list

The work site is still there. Git has stored the stash content somewhere, but there are two ways to restore it:

First, use git stash apply for recovery, but after recovery, the stash content is not deleted. You need to use git stash drop to delete it;

Another method is to use git stash pop to restore and delete the stash content:

 

When fixing a bug, we will fix it by creating a new bug branch, merging it, and deleting it;

When the work is not completed, first git stash the work site, then fix the bug, fix it, then git stash pop, and return to the work site.

 

If you want to discard a branch that has not been merged, you can use git branch-D name to forcibly delete it.

 

When you clone from a remote repository, Git automatically maps the local master branch to the remote master branch, and the default name of the remote repository is origin.

To view the remote database information, use git remote or git remote-v to display more detailed information:

git remotegit remote -v

Push Branch

The push branch refers to pushing all local commits on the branch to the remote database. When pushing, you must specify a local branch. In this way, Git will push the branch to the remote branch corresponding to the remote library.

Git push origin master // if you want to push other branches, such as dev, change it to git push origin dev

However, it is not necessary to push local branches to a remote device. Which branches need to be pushed and which do not?

• The master branch is the master branch, so it must be synchronized from time to time;

• The dev branch is a development branch. All members of the team need to work on it, so they also need to be remotely synchronized;

• Bug branches are only used to fix bugs locally, so there is no need to push them to the remote computer unless the boss wants to see if you have fixed several bugs each week;

• Whether the feature branch is pushed remotely depends on whether you work with your partner to develop it.

In a word, in Git, branches can be hidden locally and pushed or not, depending on your mood!

 

Capture Branch

When multiple users collaborate, they will push their modifications to the master and dev branches.

Now, to simulate a friend, you can clone it in another computer (add the SSH Key to GitHub) or in another directory on the same computer:

git clone git://git.kernel.org/pub/scm/git/git.git

Specifies the link between the local dev Branch and the remote origin/dev branch.

git branch --set-upstream dev origin/devgit pull

Therefore, the working mode of multi-person collaboration is usually as follows:

1. First, you can try to use git to push origin branch-name to push your own changes;

2. If the push fails, you need to use git pull to try to merge the local updates because of the remote distribution ratio;

3. If a merge conflict exists, the conflict is resolved and submitted locally;

4. If there is no conflict or the conflict is resolved, you can use git push origin branch-name to push it!

If git pull prompts "no tracking information", the link between the local branch and the remote branch is not created. Run git branch -- set-upstream branch-name origin/branch-name.

This is the working mode of multi-person collaboration. Once you are familiar with it, it is very simple.

 

• View the remote database information and use git remote-v;

• If a new local branch is not pushed to a remote server, it is invisible to others;

• Use git to push origin branch-name from the local branch. If the push fails, use git pull to capture remote New commits;

• Create the branch corresponding to the remote branch locally and use git checkout-B branch-name origin/branch-name. The name of the local branch should be the same as that of the remote branch;

• Create an association between a local branch and a remote branch, and use git branch -- set-upstream branch-name origin/branch-name;

• Use git pull to capture branches remotely. If a conflict exists, you must first handle the conflict.

Tag

Run the git tag name command to create a new tag. You can use the git tag command to view all the tags.

// Create a tag git tag v1.0 // tag the previous version with the commit id 25656e2 for the tag git tag v1.0 25656e2 // view the tag git tag

Use git show tagname to view Tag Information

git show v1.0

• The git tag name command is used to create a new tag. The default value is HEAD. You can also specify a commit id;

• -A tagname-m "blablabla..." can specify tag information;

• -S tagname-m "blablabla..." you can use the PGP signature label;

• Command git tag to view all tags;

To push a tag to a remote device, run the command git push origin tagname, or one-time push of all the tags not yet pushed to the remote local device.

git push origin v1.0git push origin --tags

Delete tags

In two steps, 1. Delete the local device; 2. Delete the remote device.

// Delete the local git tag-d v0.9 // Delete the remote git push origin: refs/tags/v0.9

• Command git push origin tagname to push a local tag;

• Command git push origin -- tags can push all local labels not pushed;

• Command git tag-d tagname to delete a local tag;

• Run git push origin: refs/tags/tagname to delete a remote tag.

Ignore File

You do not need to write the. gitignore file from the beginning. GitHub has prepared various configuration files for us. You only need to combine them to use them. All configuration files can be viewed online: https://github.com/github/gitignore

The principle of ignoring files is:

1. Ignores automatically generated files, such as thumbnails;
2. Ignore the intermediate files and executable files generated by compilation, that is, if one file is automatically generated by another file, the automatically generated files do not need to be put into the version library, for example. class file;
3. Ignore your own configuration files with sensitive information, such as the configuration files that store passwords.

Configure aliases

If you press git st, it indicates git status.

git config --global alias.st statusgit config --global alias.co checkoutgit config --global alias.ci commit git config --global alias.br branch

git config --global alias.unstage 'reset HEAD'