1 创建仓库
1.1.1 创建并初始化本地仓库
- 1
- 2
- 3
1.1.2 初始化本地仓库提交
- 1
- 2
- 3
- 4
1.2 或者可以使用别人的仓库
- 1
2 Git工作流 / 系统构成
你的本地仓库由 git 维护的三棵“树”组成。第一个是你的 工作目录,它持有实际文件;第二个是 缓存区(Index),它像个缓存区域,临时保存你的改动;最后是 HEAD,指向你最近一次提交后的结果。
2.1 提交改动(add)
捕获/追踪改动:
- 1
或者:
- 1
提交改动:
- 1
现在,你的改动已经提交到了 HEAD,但是还没到你的远端仓库。
2.2 推送改动(push)
你的改动现在已经在本地仓库的 HEAD 中了。执行如下命令以将这些改动提交到远端仓库:
- 1
可以把 master 换成你想要推送的任何分支。
2.3 提交冲突时
如果将本地代码提交到远端仓库发生冲突时,可以获取远端版本库并与本地提交版本库进行合并后再提交
- 1
- 2
2.4 修补提交
修补最近一次的提交而不创建新的提交
- 1
2.5 从暂存区恢复到工作区
- 1
3 分支
分支是用来将特性开发绝缘开来的。在你创建仓库的时候,master 是“默认的”。在其他分支上进行开发,完成后再将它们合并到主分支上。
创建一个叫做“feature_x”的分支,并切换过去:
- 1
上面这条命令相当于执行如下两个命令:
- 1
- 2
查看分支:
- 1
切换回主分支:
- 1
再把新建的分支删掉:
- 1
除非你将分支推送到远端仓库,不然该分支就是 不为他人所见的
- 1
删除远端分支:
- 1
4 更新与合并
更新本地仓库至最新改动:
- 1
相当于,在工作目录中获取(fetch)并合并(merge)远端的改动。
合并其他分支到你的当前分支(例如 master),执行:
- 1
两种情况下,git 都会尝试去自动合并改动。不幸的是,自动合并并非次次都能成功,并可能导致 冲突(conflicts)。 这时候就需要你修改这些文件来人肉合并这些 冲突(conflicts) 了。改完之后,你需要执行如下命令以将它们标记为合并成功:
- 1
在合并改动之前,也可以使用如下命令查看:
- 1
5 查看状态和日志
查看仓库状态:
- 1
- 2
查看日志:
- 1
- 2
- 3
- 4
6 标签
在软件发布时创建标签,是被推荐的。这是个旧有概念,在 SVN 中也有。可以执行如下命令以创建一个叫做 1.0.0 的标签:
- 1
1b2e1d63ff 是你想要标记的提交 ID 的前 10 位字符。
tag的其他命令:
- 1
- 2
- 3
- 4
- 5
- 6
7 场景模拟
7.1 替换本地改动
假如你做错事(自然,这是不可能的),你可以使用如下命令替换掉本地改动:
- 1
此命令会使用 HEAD 中的最新内容替换掉你的工作目录中的文件。已添加到缓存区的改动,以及新文件,都不受影响。
假如你想要丢弃你所有的本地改动与提交,可以到服务器上获取最新的版本并将你本地主分支指向到它:
- 1
- 2
7.2 错误代码push至远端仓库
首先将远端仓库代码拉回本地:
- 1
然后查看版本log:
- 1
将本地仓库(刚从远端仓库拉下来的副本)回滚至正确版本:
- 1
- 2
- 3
- 4
强行推送本地仓库至远程仓库:
- 1
- 2
8 其他
内建的图形化 git:
- 1
彩色的 git 输出:
- 1
显示历史记录时,只显示一行注释信息:
- 1
交互地添加文件至缓存区: