This happened last week several things:

1. Google released SHA-1 collision secure encryption examples
2. Cloudflare leaked encrypted data networking session
3. linux kernel vulnerability CVE-2017-6074

Encryption in the network, more and more attention, currently before github still based on SHA-1 as the label and look forward to the late improvement.

The following is a brief record of the installation git, some incomplete translation

installation

If you need Bash command-completion (ie, press Tab to complete the command you are typing), please~/.bashrcFile add the following:

source /usr/share/git/completion/git-completion.bash

You can also install bash-completion to automatically provide command shell finished up.

If you want to use Git built-in graphical user interface (for example gitk or git gui), you need to install the tk package, otherwise you will encounter a cryptic error message:

/usr/bin/gitk: line 3: exec: wish: not found.

Configuration

Git read configuration information from a plurality of profile INI format. In each git repository,.git/config It is used to specify the configuration options related to the repository. In$HOME/.gitconfig User ( "global") profile is configured as a backup repository configuration. You can edit the configuration files directly, but more recommended method is to use git-config tool. E.g,

$ git config --global core.editor "nano -w"

Added in editor = nano -w ~ / .gitconfig file [Core] section.

man page git-config tool provides a complete list of options.

Here are some common configurations you might use:

$ git config --global user.name "Firstname Lastname"
$ git config --global user.email "[email protected]"

Color output at the command line Git
color.ui configuration options can make information Git color output.

$ git config --global color.ui true

Git solve the problem for the Chinese digital file name display at the command line

$ git config --global core.quotepath false

Basic Usage

Clone a repository

The following command will file a new version of Git library clones to a local directory folder:

git clone <repo location> <dir>

If left empty

git clone [email protected]:torvalds/linux.git

GitHub file on the Linux kernel image can be cloned called "linux" folder.

Submit (commit) files to the repository
Git submitted two-step process:
add new files, modify existing files (can be completed by git add) or delete files (complete by git rm). These modifications will be stored in a file named index.

Use git commit to commit changes.
text editor will open when submitted Git, complete and submit information. To select the editor you can modify core.editor by git config command.

In addition, you can also directly use git commit -m command to fill in the information submitted at the time of submission, so as not to open the editor.

Other useful tips:

git commit -a lets you commit changes you have made to files already under Git control without having to take the step of adding the changes to the index. You still have to add new files with git add.
git commit -a command to skip adding modified part, but if you still need to create a new file git add.
git add -p command to submit a specific portion of the modified file. If you make a number of changes and want to submit multiple times, then this option is useful.

The submission of the changes (push) to public repository
command can be modified to be submitted to the server (e.g. Github):

git push <server name> <branch>

Add -u parameter can be set to the default server when the server's current branch (branch) submission. If you are cloning by the method described above repository, the default server will be the source of your clone (alias "origin"), default branch will be master. This means that if you clone, then in accordance with the method described above, as long as you can execute git push the time of submission. If desired, you can make Git submit to multiple servers, but it is more complex. Hereinafter will explain branch (branch).

Downloaded from the server to modify the common repository
If you are working on more than one computer, and your local repository and server need to be updated, you can do:

git pull <server name> <branch>

And push similar, server name and branch can be based on default, so simply execute git pull.
Git pull actually two commands following abbreviations are used:

git fetch, copy the file to a local server, this branch is called "remote" that is, it is a mirror of the remote server.
git merge, merge "remote" branch files and local files. If you submit a local record and submit records of the same server, you can directly get the latest version of the server. If you submit a recording with the server does not match (for example, after the last time you submit others were submitted), filed in duplicate records will be merged.

It is not a bad idea to get into the practice of using these two commands instead of git pull. This way you can check to make sure that the server contains what you would expect before merging.
command instead of stepping through the two git pull not a bad thing, so you can make sure that before you merge a file server and expect the same.

View History
git log command to display the current history of the branch. Note that each submission (the commit) SHA-1 will be a marked distinction, followed by submission, submission date, and submission of information. More useful commands:

git log --graph --oneline --decorate

TortoiseGit can be displayed with the record submitted a similar window, the window contains the following elements:
SHA-1 marker every seven before submission (sufficient to distinguish between different submitted)
--graph options may be displayed (if any) from the current number of branches of the fork branches
--oneline option to display information in one line each submission
--decorate option to display all the submissions (including branches and tags)

This may be an alias command to git graph saved with the following command:

git config --global alias.graph 'log --graph --oneline --decorate'

Now execute git graph would be equivalent to execute git log --graph --oneline --decorate.
git graph git log command and parameters --all be performed, which will display all the branch information, and not just the current branch.
may be performed with --stat parameters, it can display what files have to modify each commit, modify the number of rows.

The combined treatment (Merge)
when you pull executed, perform the recovery operation, or a branch will be required to merge with another merging process. Similar to the VCS other, when the automatic processing can not be combined Git, the user needs to be processed.
Git Book can view this section to explain how to handle merge conflicts.
If you want to restore it by merging, --abort combined operating parameters associated with the command may be, for example, git merge --abort, git pull --abort, git rebase --abort) .

Using a distributed version control system

The above commands only provide the basics. The real power and convenience in Git (and other distributed version control systems) come from leveraging its local commits and fast branching. A typical Git workflow looks like this:
Create and check out a branch to add a feature.
Make as many commits as you would like on that branch while developing that feature.
Squash, rearrange, and edit your commits until you are satisfied with the commits enough to push them to the central server and make them public.
Merge your branch back into the main branch.
Delete your branch, if you desire.
Push your changes to the central server.

Creating a branch

git branch <branch name>

can be used to create a branch that will branch off the current commit. After it has been created, you should switch to it using

git checkout <branch name>

A simpler method is to do both in one step with

git checkout -b <branch name>

To see a list of branches, and which branch is currently checked out, use

git branch

A word on commits
Many of the following commands take commits as arguments. A commit can be identified by any of the following:
Its 40-digit SHA-1 hash (the first 7 digits are usually sufficient to identify it uniquely)
Any commit label such as a branch or tag name
The label HEAD always refers to the currently checked-out commit (usually the head of the branch, unless you used git checkout to jump back in history to an old commit)
Any of the above plus ~ to refer to previous commits. For example, HEAD~ refers to one commit before HEAD and HEAD~5 refers to five commits before HEAD.

Submit to checkpoints
In Subversion and other older, centralized version control systems, commits are permanent - once you make them, they are there on the server for everyone to see. In Git, your commits are local and you can combine, rearrange, and edit them before pushing them to the server. This gives you more flexibility and lets you use commits as checkpoints. Commit early and commit often.

Edit submitted before

git commit --amend

allows you to modify the previous commit. The contents of the index will be applied to it, allowing you to add more files or changes you forgot to put in. You can also use it to edit the commit message, if you would like.

Insert, reorder, and change history

git rebase -i <commit>

will bring up a list of all commits between and the present, including HEAD but excluding . This command allows you rewrite history. To the left of each commit, a command is specified. Your options are as follows:
The "pick" command (the default) uses that commit in the rewritten history.
The "reword" command lets you change a commit message without changing the commit's contents.
The "edit" command will cause Git to pause during the history rewrite at this commit. You can then modify it with git commit --amend or insert new commits.
The "squash" command will cause a commit to be folded into the previous one. You will be prompted to enter a message for the combined commit.
The "fixup" command works like squash, but discards the message of the commit being squashed instead of prompting for a new message.
Commits can be erased from history by deleting them from the list of commits
Commits can be re-ordered by re-ordering them in the list. When you are done modifying the list, Git will prompt you to resolve any resulting merge problems (after doing so, continue rebasing with git rebase --continue)
When you are done modifying the list, Git will perform the desired actions. If Git stops at a commit (due to merge conflicts caused by re-ordering the commits or due to the "edit" command), use git rebase --continue to resume. You can always back out of the rebase operation with git rebase --abort.
Warning: Only use git rebase -i on local commits that have not yet been pushed to anybody else. Modifying commits that are on the central server will cause merge problems for obvious reasons.
Note: Vim makes these rebase operations very simple since lines can be cut and pasted with few keystrokes.

Git prompt
The Git package comes with a prompt script. To enable the prompt addition you will need to source the git-prompt.sh script and add $(__git_ps1 " (%s)") to you PS1 variable.
Copy /usr/share/git/completion/git-prompt.sh to your home directory (e.g. ~/.git-prompt.sh).
Add the following line to your .bashrc/.zshrc:
source ~/.git-prompt.sh
For Bash:

PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '

Note: For information about coloring your bash prompt see Color_Bash_Prompt
For zsh:

PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ '

The %s is replaced by the current branch name. The git information is displayed only if you are navigating in a git repository. You can enable extra information by setting and exporting certain variables to a non-empty value as shown in the following table:

TODO: Table Format

Variable    Information
GIT_PS1_SHOWDIRTYSTATE  * for unstaged and + for staged changes
GIT_PS1_SHOWSTASHSTATE  $ if something is stashed
GIT_PS1_SHOWUNTRACKEDFILES  % if there are untracked files

Transfer Protocol

Smart HTTP

Since version 1.6.6 git is able to use the HTTP(S) protocol as efficiently as SSH or Git by utilizing the git-http-backend. Furthermore it is not only possible to clone or pull from repositories, but also to push into repositories over HTTP(S).
The setup for this is rather simple as all you need to have installed is the Apache web server (with mod_cgi, mod_alias, and mod_env enabled) and of course, git:

Once you have your basic setup up and running, add the following to your Apache's config usually located at /etc/httpd/conf/httpd.conf:

<Directory "/usr/lib/git-core*">
    Order allow,deny
    Allow from all
</Directory>

SetEnv GIT_PROJECT_ROOT /srv/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/

The above example config assumes that your git repositories are located at /srv/git and that you want to access them via something like http(s)://your_address.tld/git/your_repo.git. Feel free to customize this to your needs.
Note: Of course you have to make sure that your Apache can read and write (if you want to enable push access) on your git repositories.
For more detailed documentation, visit the following links:
http://progit.org/2010/03/04/smart-http.html
https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-http-backend.html

Git SSH
You first need to have a public SSH key. For that follow the guide at Using SSH Keys. To set up SSH itself, you need to follow the SSH guide. This assumes you have a public SSH key now and that your SSH is working. Open your SSH key in your favorite editor (default public key name is ~/.ssh/id_rsa.pub), and copy its content (Ctrl+c). Now go to your user where you have made your Git repository, since we now need to allow that SSH key to log in on that user to access the Git repository. Open ~/.ssh/authorized_keys in your favorite editor, and paste the contents of id_rsa.pub in it. Be sure it is all on one line! That is important! It should look somewhat like this:
Warning: Do not copy the line below! It is an example! It will not work if you use that line!

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCboOH6AotCh4OcwJgsB4AtXzDo9Gzhl+BAHuEvnDRHNSYIURqGN4CrP+b5Bx/iLrRFOBv58TcZz1jyJ2PaGwT74kvVOe9JCCdgw4nSMBV44cy+6cTJiv6f1tw8pHRS2H6nHC9SCSAWkMX4rpiSQ0wkhjug+GtBWOXDaotIzrFwLw== username@hostname

Now you can checkout your Git repository this way (change where needed. Here it is using the git username and localhost):
git clone git@localhost:my_repository.git
You should now get an SSH yes/no question. Type yes followed by Enter. Then you should have your repository checked out. Because this is with SSH, you also do have commit rights now. For that look at Git and Super Quick Git Guide.

Specific non-standard port
Connecting on a port other than 22 can be configured on a per-host basis in /etc/ssh/ssh_config or ~/.ssh/config. To set up ports for a repository, specify the path in .git/config using the port number N and the absolute path /PATH/TO/REPO:

ssh://[email protected]:N/PATH/TO/REPO

Typically the repository resides in the home directory of the user which allows you to use tilde-expansion. Thus to connect on port N=443,

url = [email protected]:repo.git

becomes:

url = ssh://[email protected]:443/~git/repo.git

Git daemon
Note: The git daemon only allows read access. For write access see #Git SSH.
This will allow URLs like "git clone git://localhost/my_repository.git".
Edit the configuration file for git-daemon /etc/conf.d/git-daemon.conf (GIT_REPO is a place with your git projects), then start git-daemon with root privileges:

# systemctl start git-daemon@

To run the git-daemon every time at boot, enable the service:

# systemctl enable git-daemon@

Clients can now simply use:

git clone git://localhost/my_repository.git

Git repository rights
To restrict read/write access, you can simply use Unix rights, see http://sitaramc.github.com/gitolite/doc/overkill.html
For a fine-grained rights access, see gitolite and gitosis