本地库

通过命令 git init 把这个目录变成 git 可以管理的仓库

git 本地工作流程

git 的工作流程一般是这样的：

1、在工作目录中添加、修改文件；

2、将需要进行版本管理的文件放入暂存区域；

3、将暂存区域的文件提交到版本库。

文件 4 种状态

本地库提交

首先新建一个文件 readme.txt，把文件提交到仓库:

git add readme.txt

git commit -m "description"

如果有大量文件进行改变，全部进行 add, 则使用 git add .。
如果想 add 并 commit，则使用 git commit -a -m “Changed some files”。
git commit 命令的 - a 选项可将所有被修改或者已删除的且已经被 git 管理的文档提交到仓库中。
千万注意，- a 不会造成新文件被提交，只能修改。

我们现在可以使用 git show 命令查看这一提交详细信息。

如果想查看全部提交信息，则使用 git log。

git log 
git log --pretty=oneline 

时光机穿梭

现在改变 readme.txt 文件，添加一些内容，使用 git status 命令看看结果。

git status 命令可以让我们时刻掌握仓库当前的状态，上面的命令告诉我们，readme.txt 被修改过了，但还没有准备提交的修改。

虽然 Git 告诉我们 readme.txt 被修改了，但如果能看看具体修改了什么内容，自然是很好的。比如你休假两周从国外回来，第一天上班时，已经记不清上次怎么修改的 readme.txt，所以，需要用 git diff readme.txt 这个命令看看。

git diff <file> # 比较当前文件和暂存区文件差异

git diff <id1><id1><id2> # 比较两次提交之间的差异

git diff <branch1> <branch2> # 在两个分支之间比较

git diff --staged # 比较暂存区和版本库差异

git diff --cached # 比较暂存区和版本库差异

git diff --stat # 仅仅比较统计信息

git 的撤销操作：reset、checkout 和 revert
这三个命令都可以用于撤销。

reset 和 checkout 可以作用于 commit 或者文件，revert 只能作用于 commit。

commit 级别的操作

1.reset

$ git checkout hotfix
$ git reset HEAD~2

git reset --hard HEAD^   // 回退上一个版本
在 Git 中，用 HEAD 表示当前版本。git reset --hard HEAD~100     // 往上 100 个版本

git reset 用于撤销未被提交到 remote 的改动，即撤销 local 的修改。除了移动当前分支的 HEAD，还可以更改 workspace 和 index：

–soft：修改 HEAD，不修改 index 和 workspace。

–mixed：修改 HEAD 和 index，不修改 workspace。默认行为。

–hard：修改 HEAD、index、workspace。

git reset –mixed HEAD 把 index 的内容退回到 workspace 中。
git reset –hard HEAD 把 index 和 workspace 的修改全部撤销。

2.revert

$ git checkout hotfix
$ git revert HEAD^^

revert 通过新建一个 commit 来撤销一次 commit 所做的修改，是一种安全的方式，并没有修改 commit history。

revert 用于撤销 committed changes，reset 用于撤销 uncommitted changes。
3.checkout
checkout 作用于 commit 级别时，只是移动 HEAD 到不同的 commit。如果有 unstaged 的文件，git 会阻止操作并提示。这对于快速查看文件旧版本来说非常方便，但如果你当前的 HEAD 没有任何分支引用，那么这会造成 HEAD 分离。因此，在为分离的 HEAD 添加新的提交时候你应该创建一个新的分支。

file 级别的操作

1.git revert
1)暂存区回退

git reset [file]
git reset HEAD readme.txt

2.git checkout
1)工作区回退
如果比对后，发现这次改动不是我们想要的，那么我们可以回退到未修改之前：

git checkout readme.txt
git checkout .
git checkout -- readme.txt  // 以防判断成分支

2)用指定 commit 提交的内容覆盖工作区, 并不是真正的回退

git checkout HEAD filename
git checkout  commit_Id  -- readme.txt

远程库

当你从远程库克隆时候，实际上 Git 自动把本地的 master 分支和远程的 master 分支对应起来了，并且远程库的默认名称是 origin。

1. 要查看远程库的信息 使用 git remote
2. 要查看远程库的详细信息 使用 git remote –v

git clone < 版本库的网址 > < 本地目录名 >

如果本地库需要和远程库进行关联，则：

git remote add [shortname] [url]

远程拉取

git pull = git fetch + git merge
git pull --rebase = git fetch + git rebase  // 推荐

git rebase 和 git merge 区别

想要更好的提交树，使用 rebase 操作会更好一点，这样可以线性的看到每一次提交，并且没有增加提交节点。

在 rebase 的过程中，也许会出现冲突(conflict)。在这种情况，Git 会停止 rebase 并会让你去解决冲突；在解决完冲突后，用 ”git add” 命令去更新这些内容，然后，你无需执行 git-commit，只要执行:

git rebase --continue      // 继续
git rebase --abort         // 取消
git rebase –skip           // 忽略冲突

而 merge 操作遇到冲突的时候，当前 merge 不能继续进行下去。手动修改冲突内容后，add 修改，commit 就可以了。

给 git pull 默认加上 rebase 功能

git pull 时可以加上 –rebase 参数, 使之不产生 Merge 点, 保证了代码的整洁, 即: git pull –rebase
但每次都加 –rebase 似乎有些麻烦，我们可以指定某个分支在执行 git pull 时默认采用 rebase 方式：

git config branch.dev.rebase true

如果你觉得所有的分支都应该用 rebase，那就设置：

git config --global branch.autosetuprebase always

这样对于新建的分支都会设定上面的 rebase=true 了，已经创建好的分支还是需要手动配置的。

git stash

如果当前开发内容并不想提交，但是又有另外紧急开发任务，可以使用此命令。

git stash          // 把当前工作的改变隐藏起来
git stash list     // 查看已存在更改的列表
git stash pop      // 可从堆栈中删除更改并将其放置在当前工作目录中

远程提交及撤销

git push origin master

// git 远程版本回退
git push origin HEAD --force

git 分支

 查看分支：git branch
 创建分支：git branch name
 切换分支：git checkout name
 创建 + 切换分支：git checkout –b name
 合并某分支到当前分支：git merge name
 删除分支：git branch –d name
  删除远程分支：git push origin --delete [branch-name] //git push origin :br 

合并分支

git checkout master                    // 切换到 master
git merge <branch name>                // 合并分支

–no-ff 指的是强行关闭 fast-forward 方式。

fast-forward 方式就是当条件允许的时候，git 直接把 HEAD 指针指向合并分支的头，完成合并。属于“快进方式”，不过这种情况如果删除分支，则会丢失分支信息。因为在这个过程中没有创建 commit

git merge –squash 是用来把一些不必要 commit 进行压缩，比如说，你的 feature 在开发的时候写的 commit 很乱，那么我们合并的时候不希望把这些历史 commit 带过来，于是使用 –squash 进行合并，此时文件已经同合并后一样了，但不移动 HEAD，不提交。需要进行一次额外的 commit 来“总结”一下，然后完成最终的合并。

总结：
–no-ff：不使用 fast-forward 方式合并，保留分支的 commit 历史
–squash：使用 squash 方式合并，把多次分支 commit 历史压缩为一次

提取其他分支提交

在 cherry-pick，您可以从其他分支复制指定的提交，然后导入到现在的分支。

git cherry-pick <commit id>

分支策略

master 主分支应该非常稳定，用来发布新版本，一般情况下不允许在上面工作，工作一般情况下在新建的 dev 分支上工作，工作完后，比如上要发布，或者说 dev 分支代码稳定后可以合并到主分支 master 上来。
阮一峰：Git 分支管理策略

---

参考链接：
一个小时学会 Git
Git 教程