有用的git建议

> 本文参考 [Git - Useful Tips](http://ericdouglas.github.io/2016/04/01/Git-Useful-Tips/) 一文翻译，不当之处，敬请谅解


这篇文章的目的是给经常使用git管理项目提供一个有益的提醒。如果你是git新手，可以先阅读文后的引用部分，然后在回头阅读此篇文章。在介绍git命令之前，你可以先看看来自 [on-my-zsh](https://github.com/robbyrussell/oh-my-zsh/wiki/Cheatsheet#git) 提供的别名。
### 基本命令
- `git config --global user.name "Your Name"`
- `git config --global user.email "youremail@example.com"`
- `git config --global core.editor `
- Ex: `git config --global core.editor vim`
- `git init`：初始化一个repo。
### Commit 结构
- `git status`(`gst`)：查看 repo 状态
- 工作区：
- **.git 目录**
- **暂存区**
- **工作目录**

- `git add `(`ga`)：添加一个文件到暂存区
- `git add .`(`gaa`)：添加所有文件到暂存区
- `git add *.js`：添加所有后缀为js的文件到暂存区
- `git rm --cached `：从暂存区删除一个新文件
- `git commit -m "My first commit"`(`gcmsg`)：创建一次带 message 的提交
- `git commit -v -a`(`gca`)：
- `-v`是 verbose 的缩写，会在底部显示差异信息和更多有意义的信息
- `-a` 类似于 `git add .`，会添加所有被修改和删除的文件，但会忽略新创建的文件
- `git help `：查看对应命令的帮助手册
- `git log`(`glg`,`glgg`,`glo`, `glog`)：查看项目的提交历史
### 暂存区管理
- `git reset HEAD `(`grh`)：从暂存区删除一个被修改的文件
- `git reset HEAD`(`grh`)：从暂存区删除所有被修改的文件
- `git checkout `(`gco`)：从暂存区删除一个被修改的文件，并撤销文件的更改
- `git commit -m "My first commit" --amend`：添加文件/更改在暂存区的最后一次提交
- `git commit -v -a --amend`(`gca!`)：添加文件/更改在暂存区的最后一次提交
- `.gitignore`：告诉git，哪些文件不被加入版本跟踪
- 可以使用 `git add -f` 命令添加一个不被版本跟踪的文件
- `git diff `(`gd`)：查看基于当前文件的最后一次提交的更改差异
- `git diff` (`gd`)：查看基于所有文件的最后一次提交的更改差异
- `git reset HEAD~2 --soft`：从项目提交历史中删除最近两次提交，但不丢弃文件的更改
- `git reset HEAD~2 --hard`：从项目提交历史中删除最近两次提交，但会丢弃文件的更改和在(最后两次)提交中创建的新文件
- `git reset --soft --hard`：
- `--soft`：将所有被更改的文件回溯到“待提交”状态
- `--hard`：`commit` 之后，对被git追踪的文件的任何更改都被丢弃
- `git reflog`：显示包括"被撤销"在内的所有提交
- `git merge `：重新提交(restore the commit)
- `git clean -f`：删除工作目录中不被git进行版本追踪的文件
### Stashed & Branches
#### Stash
- `git stash`(`gsta`)：将所有暂存区的文件移动到“储藏区”，类似于另一种类型的工作区
- `git stash list`：查看储藏队列(Stash lists)
- `git stash apply`：将最近一次储藏恢复到暂存区(可以用类似 `git stash apply stash@{num}`(num从0开始计数) 的命令来使用在队列中的任意一个储藏(stashes))
- `git stash clear`：清空储藏队列
- `git stash save "name of the stash"`：为储藏设置命名
- `git stash pop`(`gstp`)：将最近一次储藏恢复到暂存区并从储藏队列删除此储藏
- `git stash drop`(`gstd`)：从储藏队列删除最近一次储藏(`stash@{0}`)(`git stash drop stash@{num}` 从储藏队列删除指定储藏)
#### Branch
- `git checkout -b dev`(`gco`)：创建 dev 分支并从当前分支切换到 dev 分支
- `git branch`(`gb`)：查看所有分支
- `git checkout master`(`gcm`)：切换到主分支
- `git merge `(`gm`)：合并分支
- `git rebase master`：先将 master 上的更改合并到当前分支，再添加当前分支的更改。如果有冲突，解决冲突后加 `--continue` 参数继续合并
- `git branch -d `： 删除分支，`-D` 则强制删除分支
- `git merge --squash`：将多次提交合并成一个，其流程如下：

```
# Go to the `master` branch
git checkout master
# Create a temp branch
git checkout -b temp
# Merge the feature/x branch into the temp using --squash
git merge feature/x --squash
# See the new modifications/files in the Staging Area
git status
# Create the unified commit
git commit -m "Add feature/x"
# Delete the feature/x branch
git branch -D feature/x
```
- rebase 和 merge 的区别：
- rebase:
- 提交历史(的展示)是线性的
- 缺点：会删除最近一个 commit，然后创建一次新的 commit
- 如果已提交到远程，不要使用 rebase
- merge:
- 提交历史(的展示)是分叉的
- 对于两个分支的合并，会创建一个次新的 commit
### 远程仓库管理
- `git remote add `：添加一个将被追踪的远程仓库
- `git remote rm `：移除一个远程仓库
- `git push `(`gp`,`ggp`)：将当前分支的本地 commit 推送到远程仓库
- `git fetch `：拉取远程仓库的最新 commit 到当前(本地)分支(`/`)，不会合并
- `git pull `(`gl`,`ggl`)：拉取远程仓库的最新 commit 到当前(本地)分支，并自动 merge
- `git pull --rebase`(`gup`)：以 rebase 的方式进行合并，而不是 merge
### 其它有用的命令
- `git tag `：创建一个 tag(如：v1.3)
- `git push --tags`：将本地 tags 推送到远程仓库
- `git push `：推送指定的本地 tag 到远程
### 引用
- [Comecando com git](http://www.akitaonrails.com/2010/08/17/screencast-comecando-com-git)
- [A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/)
- [Comparing workflows](https://www.atlassian.com/git/tutorials/comparing-workflows/)
- [git-flow cheatsheet](http://danielkummer.github.io/git-flow-cheatsheet/)
- [Resource to learn git](https://github.com/open-source-society/computer-science#prerequisite)
- [More resources](https://github.com/ericdouglas/dev-log/blob/master/source/git.md)

The issue contains a Chinese translation of a Git tips article, but names no repository file, documentation entry point, or required change. First inspect the repository structure and the existing blog-content conventions, then confirm the intended documentation outcome with maintainers before editing; done should mean the agreed article is integrated without broken links or formatting.

Written by the indexing model from the issue text.