If not specified, ' $ ' means execution under the Linux terminal command line
One. Install git
Linux Fedora Series installation command: $ sudo yum install git
Linux Debian Series installation command: $ sudo apt-get install git
Two. Configure Git
Assuming you have Git installed at this point, you'll configure Git first, with three levels of configuration:
1./etc/gitconfig file: Contains a common configuration for each user and their warehouse on the system. If you use Git config with the--system option, it reads and writes configuration variables from this file.
2. ~/.gitconfig or ~/.config/git/config file: only for the current user. You can pass the--global option to have Git read and write this file.
3. config file in the Git directory that is currently using the repository (that is. git/config): For this warehouse
You can view the list of configurations with the following command: $ git config--list
You can check one of the git config <key> by typing the git configuration, e.g: $ git config user.name
Three. Git warehouse operations
1. Cloning a remote repository that already exists
Default name Save: $ git clone https://github.com/libgit2/libgit2
Rename Save: $ git clone https://github.com/libgit2/libgit2 mylibgit
2. Use Git to manage existing projects
Enter the project directory and enter: $ git init
This command creates a subdirectory named. Git, which contains all the necessary files in your initialized git repository, which are the backbone of the Git repository. However, at this point, we just do an initialization operation, and the files in your project are not being tracked. (See Git internals for more information on what files are contained in the. git folder.) )
If you are initializing a Git repository for versioning in a folder that already has files (rather than an empty folder), you should start tracking these files and submitting them. You can use the git add command to track a specified file and then execute a git commit commit:
$ git Add *.c
$ git Add LICENSE
$ git commit-m ' initial project version '
Four. Command collection
1. View file status
$ git status//view current file status
$ git status-s <=> $ git status--short
Status symbol Description:
?? Newly added non-tracked files
A new file added to staging area
M m on the right: The file has been modified, but it hasn't been put into staging area.
M m on the left: the file has been modified and put into the staging area
MM has been modified in the workspace after it has been submitted to staging area and has been changed in the work area.
2. Git add
$ git add [filename]//Start trace file, or add modified file to staging area
3. Ignoring files
$ vim. Gitignore
---edit this file to filter out administration that does not need to be included in Git, and you do not want them to always appear in files that are not tracked in the list of files, it is important to note that these files must not be in the tracking state to be valid.
---A detailed example can be consulted: Https://github.com/github/gitignore
4. View the differences
$ git diff//view file changes that have not yet been staged
$ git diff--cached <=> git diff//view file changes that have not yet been staged, Git 1.6.1 and later also allow Git diff--staged, the effect is the same, but better to remember.
5. Submit Updates
$ git commit-m "submit files that have been stored in the cache"
$ git commit-a-M "Commit all tracked modified files" <=> git add and git commit-m ""
6. Git rm
$ git rm [filename]//Next time the file is submitted, it is no longer included in version management. You must use the force delete option-F if you have modified it before deleting it and have placed it in the staging area.
$ git RM log/\*.log//Delete all files with a. log extension under the log/directory (note the backslash before the asterisk *)
$ git RM \*~//Delete all files ending with ~
$ git RM--cached [filename]
---Keep files on disk, but don't want Git to keep tracking
---this is especially useful when you forget to add a. gitignore file and accidentally add a large log file or a bunch of. A compile-generated files to staging area.
7. Git MV
$ git MV readme.md README equivalent to running the following three commands
$ mv Readme.md README
$ git rm readme.md
$ git Add README
8. View commit History
$ git Log//list all updates by commit time, most recent updates on top
$ git log-p-2//-p to show the difference in content for each commit. -2, indicating that only the last two commits are displayed; This option, in addition to displaying the basic information, is accompanied by a change in each commit
$ git log--stat//each commit is listed below the amount of all modified files, how many files have been modified, and which lines of the modified files have been removed or added
$ git log--pretty=oneline
ca82a6dff817ec66f44342007202690a93763949 changed the version number
085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test
A11bef06a3f659402fe7563abf99ad00de2209e6 First Commit
$ git log--pretty=format: "%h-%an,%ar:%s"
Ca82a6d-scott Chacon, 6 years ago:changed the version number
085bb3b-scott Chacon, 6 years ago:removed unnecessary test
A11bef0-scott Chacon, 6 years Ago:first commit
Common options for git log--pretty=format
Option description
%H full hash string for commit object (commit)
%h a short hash string for the Commit object
Full hash string for%T tree object
Short hash string for%t tree object
The full hash string of the parent object (%P)
%p a short hash string for the parent object
The name of the%an author (author)
%ae Author's e-mail address
%ad Author revision date (can be customized with--date= option)
%ar Author revision date, by how long before the way display
%CN the name of the submitter (committer)
%ce The submitter's e-mail address
%CD Date of submission
%CR submission date, as of how long ago the way it appears
%s Submission Instructions
$ git log--short <=> $ git log-s
$ git log--pretty=full
$ git log--pretty=fuller
Common options for git log
Option description
-P Displays the difference between each update in a patched format.
--STAT Displays the file modification statistics for each update.
--shortstat only displays the last number of rows in the--stat modified to add remove statistics.
--NAME-ONLY Displays the modified list of files only after the information is submitted.
--name-status displays a list of new, modified, and deleted files.
--abbrev-commit displays only the first few characters of the SHA-1, not all 40 characters.
--relative-date uses a shorter relative time display (for example, "2 weeks Ago").
--graph Displays the branch merge history represented by the ASCII graphic.
--pretty Displays historical submission information in other formats. The available options are Oneline,short,full,fuller and format (followed by the specified format).
$ git log-s function_name//lists commits that have added or removed certain strings. For example, if you want to find a commit that adds or removes a reference to a particular function, you can use
$ git log--since=2.weeks//list all submissions in the last two weeks
Options for restricting git log output
Option description
-(n) show only the most recent n submissions
--since,--after only displays commits after the specified time.
--until,--before displays only the commits before the specified time.
--author displays only the commits associated with the specified author.
--committer displays only the commits that are related to the specified submitter.
--grep Show only submissions with the specified keyword
-S only show submissions that add or remove a keyword
Example:
$ git log--pretty= "%h-%s"--author=gitster--since= "2008-10-01"--before= "2008-11-01"--no-merges--t/
5610e3b-fix testcase failure When extended attributes is in use
Acd3b9e-enhance Hold_lock_file_for_{update,append} () API
F563754-demonstrate breakage of detached checkout with symbolic link HEAD
D1a43f2-reset--hard/read-tree--reset-u: Remove unmerged new paths
51a94af-fix "Checkout--track-b newbranch" on detached HEAD
9. Undo Action
$ git commit--amend//Sometimes when we're done, we find out that several files have not been added, or the submissions are wrong. At this point, you can run the commit command with the--amend option to try Resubmitting
This command will submit the file in the staging area.
If you have not made any changes since the last commit (for example, the command was executed immediately after the last commit), the snapshot remains the same, and the only thing you have modified is the submission information.
Once the text editor is started, you can see the previous submission information. Saving after editing overwrites the original commit information.
For example, after you commit, you find that you forget to temporarily save some of the changes you need, you can do it like this, and eventually you will only have one commit, and the second commit will replace the result of the first commit:
$ git commit-m ' initial commit '
$ git Add forgotten_file
$ git commit--amend
To cancel a staged file:
$ git reset HEAD [filename]
E.g: in the following example, the Readme.txt file will not be added to the staging area
$ git Add readme.txt
$ git reset HEAD readme.txt
Undo changes to a file
$ git checkout--[file]//will revert to the last time it was committed (or the way it was just cloned, the way it was just put into the working directory)
Remember that anything you commit in Git is almost always recoverable.
Even those submissions that were removed from the branch or overwritten with the--amend option can be recovered.
However, anything you have not submitted will probably never be found again.
10. Use of remote warehouses
1) View Remote repositories
$ git remote
$ git remote-v
Origin Https://github.com/schacon/ticgit (Fetch)
Origin Https://github.com/schacon/ticgit (push)
2) Add a remote repository
$ git remote add <shortname> <url>//Add a new remote Git repository while specifying a shorthand that you can easily reference
Example:
$ git remote
Origin
$ git remote add PB https://github.com/paulboone/ticgit
$ git remote-v
Origin Https://github.com/schacon/ticgit (Fetch)
Origin Https://github.com/schacon/ticgit (push)
PB Https://github.com/paulboone/ticgit (Fetch)
PB Https://github.com/paulboone/ticgit (push)
Now you can use the string PB in the command line instead of the entire URL. For example, if you want to pull a message from Paul's repository but you don't have it, you can run git fetch PB
Now Paul's master branch can be accessed locally through pb/master-you can merge it into one of your own branches, or you can check out a local branch that points to that point if you want to see it.
3) fetching and pulling from the remote repository
$ git fetch [remote-name]//Get data from the remote repository
---This command accesses the remote repository and pulls all the data you don't have. Once executed, you will have a reference to all the branches in that remote repository and can be merged or viewed at any time.
---If you clone a repository using the Clone command, the command automatically adds it as a remote repository and defaults to "origin". So, GIT fetch origin crawls all the work that was pushed after the clone (or last fetch). It is important to note that the git fetch command pulls the data to your local repository-it does not automatically merge or modify your current work. When you're ready, you have to manually merge it into your work.
---If you have a branch set up to track a remote branch, you can use the git pull command to pick up the crawl and then merge the remote branch into the current branch. This may be a simpler or more comfortable workflow for you; By default, the git clone command automatically sets the local master branch to track the master branch of the cloned remote repository (or whatever the default branch of the name). Running git pull typically fetches data from the server that was originally cloned and automatically attempts to merge to the branch that you are currently on.
4) push to remote repository
When you want to share your project, you have to push it upstream. This command is simple: git push [remote-name] [branch-name].
$ GIT push origin master//pushes the Master branch to the origin server (again, the clone usually automatically sets the two names for you).
5) View Remote repositories
If you want to see more information about a remote repository, you can use the Git remote show [remote-name] command. If you want to run this command in a specific abbreviated name, such as origin, you'll get a message like this:
$ git Remote show origin
$ git remote-v
6) Removal and renaming of remote repositories
If you want to rename a reference name, you can run git remote rename to modify the abbreviated name of a remote repository. For example, to rename a PB to Paul, you can do this with git remote rename:
$ git remote rename PB paul
$ git remote
Origin
Paul
Note: This will also modify the name of your remote branch. Those who used to cite Pb/master will now cite Paul/master.
If you want to remove a remote repository for some reason-you've moved away from the server or you no longer want to use a particular image, or a contributor is no longer contributing-you can use git remote rm:
$ git remote RM Paul
$ git remote
Origin
One. Tag tag
1) View Tags:
$ git tag
v0.1
v1.3
$ git tag-l ' v1.8.5* '
v1.8.5
V1.8.5-rc0
V1.8.5-rc1
V1.8.5-rc2
V1.8.5-rc3
v1.8.5.1
v1.8.5.2
v1.8.5.3
v1.8.5.4
v1.8.5.5
2) Create a label
Git uses two main types of tags: the note label (annotated) and the Light Weight label (lightweight).
A) Note tag: A complete object stored in a Git database. They can be verified, including the name of the tag, the e-mail address, the date time, and a label message, and the GNU Privacy Guard (GPG) signature and verification can be used. It is generally recommended to create a note tag so that you can have all of the above information, but if you just want to use a temporary tag, or for some reason you don't want to save that information, a lightweight label is also available.
The following command-M option specifies a piece of information that will be stored in the label. If you don't specify a piece of information for the note label, Git runs the editor asking you to enter the information.
$ git tag-a v1.4-m ' my version 1.4 '
$ git tag
v0.1
v1.3
v1.4
You can see the tag information and the corresponding commit information by using the GIT show command:
$ git show v1.4
Tag v1.4
Tagger:ben Straub <[email protected]>
Date:sat May 3 20:19:12 2014-0700
My version 1.4
Commit ca82a6dff817ec66f44342007202690a93763949
Author:scott Chacon <[email protected]>
Date:mon Mar 17 21:52:11 2008-0700
Changed the version number
b) Light weight tag: Much like a branch that doesn't change-it's just a reference to a specific commit.
$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
V1.4-lw
v1.5
3) Post Tag
You can also tag past submissions. Suppose the commit history is this:
$ git log--pretty=oneline
15027957951B64CF874C3557A0F3547BD83B3FF6 Merge Branch ' experiment '
A6b4c97498bd301d84096da251c98a07c7723e65 Beginning Write support
0d52aaab4479697da7686c15f77a3d64d9165190 One more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge Branch ' experiment '
0B7434D86859CC7B8C3D5E1DDDFED66FF742FCBC added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166AE0C4D3F420721ACBB115CC33848DFCC2121A started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 Updated Rakefile
964F16D36DFCCDE844893CAC5B347E7B3D44ABBC Commit the Todo
8A5CBC430F1A9C3D00FAAEFFD07798508422908A Updated Readme
Now, let's say you forgot to label the project when you v1.2, which is the "updated Rakefile" submission. You can then make up the label. To tag on that commit, you need to specify the checksum (or partial checksum) of the commit at the end of the command:
$ git tag-a v1.2 9fceb02
You can see that you've tagged the submission:
$ git tag
v0.1
v1.2
v1.3
v1.4
V1.4-lw
v1.5
$ git Show v1.2
Tag v1.2
Tagger:scott Chacon <[email protected]>
Date:mon Feb 9 15:32:16 2009-0800
Version 1.2
Commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author:magnus Chacon <[email protected]>
Date:sun APR 27 20:43:35 2008-0700
Updated Rakefile
...
4) Share Tags
By default, the git push command does not send labels to the remote warehouse server. After you create the tag, you must explicitly push the label to the shared server. This process is like sharing a remote branch-you can run GIT push origin [tagname].
$ GIT push Origin v1.5
Counting objects:14, done.
Delta compression using up to 8 threads.
Compressing objects:100% (12/12), done.
Writing objects:100% (14/14), 2.05 KiB | 0 bytes/s, done.
Total (Delta 3), reused 0 (Delta 0)
to [email protected]:schacon/simplegit.git
* [New tag] v1.5-v1.5
If you want to push a lot of tags at once, you can also use the git push command with the--TAGS option. This will send all the labels that are not on the remote repository server to that place.
$ GIT push origin--tags
Counting objects:1, done.
Writing objects:100% (1/1), Bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (Delta 0)
to [email protected]:schacon/simplegit.git
* [New tag] v1.4-v1.4
* [New tag] V1.4-LW-V1.4-LW
Now, when other people clone or pull from the repository, they can also get your tags.
Check out labels
You can't really check out a tag in Git because they don't move back and forth like branches. If you want the working directory to be exactly the same as the specific label version in the Repository, you can use Git checkout-b [branchname] [tagname] to create a new branch on a specific label:
$ git checkout-b version2 v2.0.0
Switched to a new branch ' Version2 '
Of course, if you commit again after this, the Version2 branch will move forward because of the change, then the Version2 branch will be slightly different from the v2.0.0 tag, then you should be careful.
Git aliases
Git does not automatically infer the commands you want when you enter some commands. If you don't want to enter the full git command every time, you can easily set an alias for each command by using a git config file. Here are some examples you can try:
$ git config--global alias.co checkout
$ git config--global alias.br branch
$ git config--global alias.ci commit
$ git config--global alias.st status
When you enter Git commit, you only need to enter Git ci. As you continue to use Git, you may also use other commands frequently, so don't hesitate to create aliases.
This technique can be useful when creating commands that you think should exist. For example, to resolve the ease-of-use problem of canceling a staging file, you can add your own cancellation staging alias to Git:
$ git config--global alias.unstage ' reset HEAD--'
This causes the following two commands to be equivalent:
$ git unstage fileA
$ git reset HEAD--FileA
This looks a little clearer. A last command is also usually added, like this:
$ git config--global alias.last ' log-1 HEAD '
This makes it easy to see the last commit:
$ git Last
Commit 66938dae3329c7aebe598c2246a8e6af90d04646
Author:josh Goebel <[email protected]>
Date:tue 26 19:48:51 2008 +0800
Test for current head
Signed-off-by:scott Chacon <[email protected]>
As you can see, Git simply replaces the alias with the corresponding command. However, you might want to execute an external command instead of a GIT subcommand. If that's the case, you can join in front of the command! Symbol. It would be useful if you wanted to write some tools for collaborating with Git repositories. For example: Git visual is defined as an alias for GITK:
$ git config--global alias.visual '!gitk '
A. Git Branch
1) View Branches
$ git branch//view all local branches list
$ git branch-a//view all branches, including remote branches
$ git branch-v//view last commit for each branch
$ git Branch--merged//View list of branches that have been merged into the current branch
$ git Branch--no-merged//View the list of branches that have not been merged into the current branch
$ git ls-remote//To get a complete list of remote references explicitly
2) Create a branch
$ git Branch testing//New testing branch, but does not switch to that branch
$ git checkout testing//To switch to an existing branch, you need to use the git checkout command, this command will switch to the testing branch, note: After each switch branch, the local code will be changed, reset to the target branch code!
$ git checkout-b testing//New testing branch and switch to that branch
3) Branch merging--conflict-free scenarios
$ git checkout master//switch to Master Branch
$ git Merge testing//testing branch merged into master
$ git branch-d testing//Delete testing Branch
Note: Deleting a branch, special cases (including work that has not been merged or other reasons) will fail when you try to delete it using the git branch-d command, and you can force the deletion by using the-D option:
$ git branch-d Testing
4) Conflict resolution
$ git checkout master//switch to Master Branch
$ git merge iss53//ISS53 branch merged into master
$ git status//view status to see which file is in conflict state
--Edit conflict
$ git mergetool//If you want to use graphical tools to resolve conflicts, the command will start a suitable visual merge tool for you (already configured)
$ vim index.html//edit conflict file
$ git add index.html//resolves all files after a conflict, using the git add command for each file to mark it as a conflict has been resolved. Once these conflicting files are staged, Git will mark them as conflicts resolved.
$ git commit index.html-m "merge conflict"//complete Merge Commit
5) Remote Branch
Https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E8%BF%9C%E7%A8%8B%E5%88%86%E6%94%AF
$ git Remote show origin
* Remote origin
Fetch Url:https://gitlab.spetechcular.com/sds/sds-airobot-cloud.git
Push Url:https://gitlab.spetechcular.com/sds/sds-airobot-cloud.git
HEAD Branch:master
Remote branches:
Master tracked
REFS/REMOTES/ORIGIN/B1 stale (use ' git remote prune ' to remove)
Local branch configured for ' Git pull ':
Master merges with remote master
Local ref configured for ' Git push ':
Master pushes to master (up to date)
$ git remote prune
6) Variable Base
Https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA
Resources:
Https://git-scm.com/book/en/v2
Git client command summary under Linux
