1. Introduction of git

In real development, Git is used as a version control tool for team collaboration. Therefore, it is very necessary to summarize the basic Git operation instructions. In this paper, we can refer to Teacher Liao Xuefeng’s blog post without re-coding some terms or theoretical basis

Git’s general operation flow is shown below (from the network).

There are four key points:

  1. Workspace: a place on the local computer where project files are stored, such as the learnGitProject folder;
  2. Git folder is called “version repository”. Git folder is called “version repository”. Git folder contains two parts, one is the staging area (Index or Stage), which is the temporary storage of files, usually use the add command to add files from the workspace to the staging area.
  3. The git folder also contains the master branch that git automatically creates, and the HEAD pointer points to the master branch. You can use the commit command to add files from the staging area to the local repository.
  4. Remote repository: the project code is stored on the remote Git server instead of the local repository. For example, the project is stored on Github, which is a remote repository. Usually, clone command is used to copy the remote repository to the local repository and push it to the remote repository after development.

In more detail:

During daily development, the code is actually placed in the workspace, i.e. local files such as xxx. Java, and the code text is submitted to the staging area (Index/Stage) through commands such as add, which means that the code is fully managed by Git. The staging area is then committed to the master branch through commands such as commit, which means that a version has been made and the code has been committed to the local repository. In addition, the team collaboration process naturally involves interaction with remote warehouses.

Therefore, after such analysis, git commands can be divided into the following logic to understand and remember:

  1. Git management configuration commands;

    Several core storage interaction commands:

  2. Interaction between workspace and staging area

  3. Interaction between staging area and local repository (branch);

  4. Interaction between local and remote repositories.

Git configuration command

Querying Configuration Information

  1. List the current configuration:git config --list;
  2. List the repository configuration:git config --local --list;
  3. List global configuration:git config --global --list;
  4. List the system configuration:git config --system --list;

Configure user information for the first time using Git

  1. Configure the user name:git config --global user.name "your name";
  2. Configuring user email addresses:git config --global user.email "[email protected]";

Other configuration

  1. Configure which difference analysis tool to use when resolving conflicts, for example to use Vimdiff:git config --global merge.tool vimdiff;
  2. Configure git command output to be colored:git config --global color.ui auto;
  3. Configure git with a text editor:git config --global core.editor vi;

#3. Action commands on the workspace

The new warehouse

  1. To manage project files in your workspace using Git, create a new local repository:git init;
  2. Copy projects from remote Git repositories:git clone <url>, such as: git clone git://github.com/wasd/example.git; If you want to define a new project name when cloning a project, you can specify a new project name after the clone command:git clone git://github.com/wasd/example.git mygit;

submit

  1. Commit all files in your workspace to staging:git add .
  2. Commit the specified file in the workspace to staging:git add <file1> <file2> ...;
  3. Commit all files in a folder in the workspace to staging:git add [dir];

undo

  1. Delete the workspace file, and also delete the record of the corresponding file from the staging area:git rm <file1> <file2>;
  2. Delete file from staging area, but workspace still has the file:git rm --cached <file>;
  3. To cancel files that have been temporarily stored in the staging area:git reset HEAD <file>...;
  4. To undo the last operation on a file:git checkout --<file>. Stashing and branching can be used to determine that a previous change to a file is no longer needed, if you want to save the previous change for later work.
  5. Hide current changes so you can switch branches:git stash;
  6. View all current stores:git stash list;
  7. Apply the latest storage:git stash applyIf you want to apply earlier storage:git stash apply stash@{2}; Reapply temporary changes that need to be added--indexParameters:git stash apply --index;
  8. Using the apply command simply applies the store while the content is still on the stack, removing the specified store:git stash drop stash{0}; If you use the pop command, you can not only reapply the store, but also clear it from the stack immediately:git stash pop;
  9. In some cases, you may want to apply changes to the store and then undo the changes you applied to the store after making some other changes. Git does not provide a command similar to Stash unapply, but the same effect can be achieved by undoing the stash patch:git stash show -p stash@{0} | git apply -R; Also, if you don’t specify a specific store, Git will select the nearest store:git stash show -p | git apply -R;

Update file

  1. Rename the file and submit the renamed file to the staging area:git mv [file-original] [file-renamed];

Novelty search information

  1. Query the status of all files in the current workspace:git status;
  2. Git diff; git diff; git diff; git diff; git diff. Specify file differences between workspace and staging:git diff <file-name>;

#4. Operation command on staging area

Commit files to the repository

  1. To submit a file from the staging area to the local repository, print a new version:git commit -m "commit_info";
  2. Save all files managed with Git and commit them, skipping the process of adding them to the staging area:git commit -a -m "commit_info";
  3. When submitting a file, you can cancel the previous submission if you find that several files are missing or the comments are incorrectly written:git commit --amend;

Check the information

  1. Compare the difference between the staging area and the previous version:git diff --cached;
  2. Specify the difference between a file in the staging area and a local repository:git diff <file-name> --cached;
  3. Git log; parameter-pTo expand the content differences of each submission, use2 -Displays the last two updates, such asgit log -p -2;

tagging

Git uses two types of tags: Lightweight and annotated. A lightweight tag is like a branch that doesn’t change, but is actually a reference to a particular submitted object. The tagged tag, on the other hand, is actually a separate object stored in the repository. It has its own checksum information, including the tag name, email address and date, as well as the label description. The tag itself also allows signing or validation using the GNU Privacy Guard (GPG). It is generally recommended to use annotated labels in order to retain relevant information. Of course, lightweight tags are fine if they are only for temporary tagging, or if you don’t need to marginalize additional information.

  1. List all the tags now:git tag;
  2. List qualifying tags using a specific search pattern, for example only versions of the 1.4.2 series are of interest:Git tag - l v1.4.2. * "";
  3. Create a label that contains the annotation type-aParameters, such asGit tag-a v1.4-m "My version 1.4";
  4. Git show git show git show git show git show git showGit show v1.4;
  5. If you have your own private key, you can use GPG to sign labels, just in the command-sParameters:Git tag -s v1.5 -m "My signed 1.5 tag";
  6. Verify signed labels:git tag -v <tag-name>, such asGit tag - v v1.5;
  7. To create a lightweight tag, just use git tag-a.-sAs well as-mNo option is required, just give the tag name, for exampleGit tag v1.5;
  8. Push a label to a remote repository:git push origin <tag-name>, such asGit push origin v1.5;
  9. Push all locally owned tags to the remote repository:git push origin --tags;

Branch management

  1. Create a branch:git branch <branch-name>, such asgit branch testing;
  2. Switch from the current branch to another branch:git checkout <branch-name>, such asgit checkout testing;
  3. New and switch to new branch:git checkout -b <branch-name>;
  4. Delete branch:git branch -d <branch-name>;
  5. Merges the current branch with the specified branch:git merge <branch-name>;
  6. Display all branches of the local repository:git branch;
  7. Query information about the last submitted object in each branch:git branch -v;
  8. To see which branches have been merged into the current branch:git branch --merged;
  9. To see which branches are not currently merged into the current branch:git branch --no-merged;
  10. Merge the remote branch into the current branch:git merge <remote-name>/<branch-name>, such asgit merge origin/serverfix; If it is a single-line historical branch, there is no disagreement to resolve, and the HEAD pointer is simply moved forward, so the merge process can be called Fast forward. If it is a historical branch, the two branches of the current fork will be used as two ancestors to create a new commit object. If a merge conflict occurs during the merge of branches and needs to be manually resolved, it can be submitted.
  11. Create a new local branch based on the remote branch<branch name> <branch name>/<branch name>, such asgit checkout -b serverfix origin/serverfix;
  12. The local branch from the remote branch checkout is called the trace branch. Push content on a trace branch to a remote branch:git push. This command automatically determines which branch in the remote warehouse to push data to; Merge remote branches on trace branches:git pull;
  13. Move the changes committed in a branch to the base branch and replay:git rebase <rebase-branch> <branch-name>, such asgit rebase master server, repeat the changes submitted by the feature branch server on the base branch Master; The biggest benefit of using the Rebase operation is that as with a single branch, the committed change history is a single line; This can be used if you want to base another feature branch on another feature branch--ontoOperation:git rebase --onto <rebase-branch> <feature branch> <sub-feature-branch>, such asgit rebase --onto master server client; The principles to follow when using rebase operations are as follows:Never rebase a branch once the commit object in that branch has been published to the common repository;

#5. Operations on local warehouses

  1. View remote warehouses associated with local warehouses:git remote; After cloning each remote repository, the remote repository defaults toorigin; add-vWill display the remote repositoryurlAddress;
  2. Add a remote repository with a short alias:git remote add [remote-name] [url], such as:git remote add example git://github.com/example/example.git;
  3. Fetching updates from a remote repository that are not present in the local repository:git fetch [remote-name], such asgit fetch origin; Using FETCH only pulls remote data to the local repository, it is not automatically merged into the current work branch, it can only be manually merged. This can be used if you have a branch associated with a branch of the remote repositorygit pullPull and pull data from remote branches, and then automatically merge the remote branches into the current branch in the local repository;
  4. Push a branch of a local repository to a remote repository:git push [remote-name] [branch-name], such asgit push origin master; If you want to push a local branch to a branch with a different name in the remote repository:git push <remote-name> <local-branch>:<remote-branch>, such asgit push origin serverfix:awesomebranch; If you want to delete remote branches:git push [romote-name] :<remote-branch>, such asgit push origin :serverfix. By omitting the local branch, you push blank content to the remote branch, and you delete the remote branch.
  5. To view details of the remote warehouse:git remote show origin;
  6. Modify the local abbreviation of a remote repository:git remote rename [old-name] [new-name], such asgit remote rename origin org;
  7. Remove remote repository:git remote rm [remote-name];

#6. Ignore files. Gitignore

There will always be files that don’t need to be managed by Git and that you don’t want to end up in the list of untracked files. These are usually automatically generated files, such as log files, or temporary files created during compilation. We can create a file named.gitignore that lists the file modes to ignore. The following cases:

## This is a comment - and will be ignored by Git
## Ignore all.a ending files
*.a
## Except lib.a! lib.aOnly TODO files in the project root directory are ignored, excluding subdir/TODO
/TODO
Ignore all files in the build/ directory
build/
## ignore doc/notes.txt but not doc/server/arch.txt
doc/*.txt
Ignore all files with TXT extensions in doc/
doc/**/*.txt
Copy the code

The resources

Very detailed and accurate git learning materials

Git – cheat sheet – Chinese version

Command summary, general information, not detailed enough for reference

Common commands are complete