svn及git使用筆記

這周發生好幾件大事：

1. 谷歌發佈SHA-1安全加密碰撞實例
2. Cloudflare 泄露網絡會話中的加密數據
3. linux內核漏洞 CVE-2017-6074

加密在網絡中愈來愈受關注，目前github的提交仍然是以SHA-1做爲標籤的，期待後期改善。

下面是安裝使用git的簡短記錄， 有些翻譯不完整

安裝

若是須要 Bash 命令補完（也即按下 Tab 來完成你正在鍵入的命令），請在~/.bashrc文件中添加以下內容：

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

你也能夠安裝 bash-completion 來自動爲 shell 提供命令補完。

若是你想使用 Git 內建的圖形界面（例如 gitk 或者 git gui），你須要安裝 tk 軟件包，不然你會遇到一個隱晦的錯誤信息：

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

配置

Git 從若干 INI 格式的配置文件中讀取配置信息。在每個 git 版本庫中，.git/config 用於指定與該版本庫有關的配置選項。在 $HOME/.gitconfig 中的用戶 ("global") 的配置文件將被用做倉庫配置的備用配置。你能夠直接編輯配置文件，可是更推薦的方法是使用 git-config 工具。例如，

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

會在 ~/.gitconfig 文件的 [core] 部分中添加 editor = nano -w。

git-config 工具的 man page 提供了完整的選項列表。

這是一些你可能用到的常見的配置：

$ git config --global user.name "Firstname Lastname"
$ git config --global user.email "your_email@youremail.com"

在 Git 命令行下啓用彩色輸出
配置 color.ui 選項能夠令 Git 以彩色輸出信息。

$ git config --global color.ui true

解決 Git 在命令行下中文文件名顯示爲數字的問題

$ git config --global core.quotepath false

基本用法

克隆一個版本庫

如下命令能夠將一個 Git 版本庫克隆至本地目錄的新文件夾中：

git clone <repo location> <dir>

若是留空

字段，就會以 Git 版本庫的名稱命名新文件夾，例如：

git clone git@github.com:torvalds/linux.git

能夠將 GitHub 上 Linux 內核的鏡像克隆至名爲「linux」的文件夾中。

提交（commit）文件到版本庫
Git 的提交過程分爲兩步：
添加新文件、修改現有的文件（都可經過 git add 完成), 或者刪除文件（經過 git rm 完成）。這些修改將被存入名叫 index 的文件中。

使用 git commit 提交修改。
Git 提交時會打開文本編輯器，填寫提交信息。你能夠經過 git config 命令修改 core.editor 來選擇編輯器。

此外，你也能夠直接用 git commit -m 命令在提交時填寫提交信息，這樣就不會打開編輯器。

其它有用的技巧：

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 命令能夠跳過添加修改的部分，可是若是建立新文件依然須要 git add。
git add -p 命令能夠提交修改文件的特定部分。若是你進行了許多修改並且但願將其分屢次提交的話，這一選項很是有用。

將改動提交（push）到公共版本庫
如下命令能夠將修改提交至服務器（例如 Github）：

git push <server name> <branch>

添加 -u 參數能夠將該服務器設爲當前分支（branch）提交時的默認服務器。若是你是經過上文的方法克隆的版本庫，默認服務器將是你克隆的來源（別名「origin」），默認分支將是 master。也就是說若是你按照上文的方法克隆的話，提交時只要執行 git push 便可。若是須要的話，能夠令 Git 提交至多個服務器，不過這比較複雜。下文將講解分支（branch）。

從服務器公共版本庫下載修改
若是你在多臺電腦上工做，而且須要將本地版本庫與服務器更新，能夠執行：

git pull <server name> <branch>

與 push 相似，server name 與 branch 均可以根據默認來，因此只需執行 git pull。
Git pull 其實是以下兩個命令的簡寫：

git fetch，將服務器文件複製至本地，這一分支被稱做「remote」也即它是遠程服務器的鏡像。
git merge，將「remote」分支的文件與本地文件合併。若是你的本地提交記錄與服務器的提交記錄相同，就能夠直接獲得服務器的最新版本。若是你的提交記錄與服務器的記錄不符（例如在你最後一次提交以後別人進行了提交），兩份提交記錄將被合併。

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.
分步執行兩個命令而非 git pull 並非壞事，這樣能夠確保合併以前服務器的文件與你指望的相同。

查看歷史記錄
git log 命令能夠顯示當前分支的歷史記錄。注意每一次提交（commit）會以一個 SHA-1 標記區分，接下來是提交者、提交日期以及提交信息。更實用的命令：

git log --graph --oneline --decorate

能夠顯示與 TortoiseGit 的提交記錄相似的窗口，這一窗口包含了以下內容：
每次提交的 SHA-1 標記的前七位（足以區分不一樣的提交）
--graph 選項能夠顯示從當前分支 fork 的分支數目（若是有的話）
--oneline 選項能夠在一行內顯示每次提交的信息
--decorate 選項能夠顯示全部的提交信息（包括分支與標籤）

能夠經過以下命令將這一命令以 git graph 的別名保存：

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

如今執行 git graph 將等價於執行 git log --graph --oneline --decorate。
git graph 與 git log 命令也能夠帶 --all 的參數執行，這將顯示全部的分支信息，而不止當前的分支。
也能夠帶 --stat 參數執行，它能夠顯示每次提交時哪些文件有修改、修改了多少行。

處理合並（merge）
當你執行 pull、進行復原操做，或者將一個分支與另外一個進行合併時會須要處理合並。與其它 VCS 相似，當 Git 沒法自動處理合並時，就須要使用者進行處理。
能夠查看 Git Book 的這一部分講解如何處理衝突合併。
若是你須要經過合併來還原的話，能夠帶 --abort 參數運行合併相關的命令，例如 git merge --abort，git pull --abort，git rebase --abort)。

使用分佈式版本控制系統

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.

建立一個分支

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.

提交爲檢查點
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.

編輯以前的提交

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.

插入、從新排序和更改歷史記錄

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提示符
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: 表格格式化

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

傳輸協議

智能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.

特定非標準端口
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://user@example.org: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 = git@example.org:repo.git

becomes:

url = ssh://git@example.org:443/~git/repo.git

Git守護進程
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版本庫權限 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