分支管理
直至现在为止,我们的项目版本库一直都是只有一个分支 master。在GIT版本库中创建分支的成本几乎为零,所以不必吝啬多创建几个分支。下面列举一些常见的分支策略,仅供大家参考:
- 创建一个属于自己的个人工作分支,以避免对主分支MASTER造成太多的干扰,也方便与他人交流协作。
- 当进行高风险的工作时,创建一个试验性的分支,扔掉一个烂摊子总比收拾一个烂摊子好得多。
- 合并别人的工作的时候,最好是创建一个临时的分支。
①. 查看分支:
运行下面的命令可以得到你当前工作目录的分支列表,输出的分支中前面带*的就是你现在所在的分支:
git branch
使用如下命令,也可以查看当前所在的分支:
cat .git/HEAD
使用如下命令,可以查看所有的分支(本地+远程)
git branch -a
②. 创建分支:
下面将创建我自己的工作分支,名叫 mallx-dev,并将以后的工作转移到这个分支上开展。
git branch mallx-dev #创建分支
git checkout mallx-dev #切换到此分支
③. 删除分支:
要删除版本库中的某个分支,使用 git-branch -D 命令就可以了,例如:
git branch -D branch-name
git branch -d只能删除那些已经被当前分支的合并的分支. 如果你要强制删除某个分支的话就用git branch –D;
④. 合并两个分支:
既然我们为项目创建了不同的分支,那么我们就要经常地将自己或者是别人在一个分支上的工作合并到其他的分支上去。现在我们看看怎么将 mallx-dev分支上的工作合并到 master分支中。
现在转移我们当前的工作分支到 master,并且将 mallx-dev分支上的工作合并进来。
git checkout master
git merge "Merge work in mallx-dev" HEAD mallx-dev
合并两个分支,还有一个更简便的方式,下面的命令和上面的命令是等价的。
git checkout master
git pull . mallx-dev
标签管理
GIT跟其它版本控制系统一样,可以打标签(tag)。其作用是标记一个点为一个版本号,如0.1.3, 0.1.7, 0.1.8。在程序开发到一个阶段后,我们需要打个标签,发布一个版本,这样的话标记的作用显而易见。
A. 打标签的操作一般发生在将修改COMMIT到本地仓库之后,标签不会随代码推送到远程而自动被推送到远程,需要单独执行推送标签到远程仓库的命令。
B. 默认标签是打在最新提交的COMMIT上的。
C. 标签总是和某个COMMIT挂钩。如果这个COMMIT既出现在MASTER分支,又出现在DEV分支,那么在这两个分支上都可以看到这个标签。
①. 查看所有标签(标签不是按打标签的时间顺序列出,而是按字母排序的):
git tag
查看0.1.3这个标签的信息:
git show 0.1.3
②. 创建标签:
git tag -a 0.1.3 -m "Release version 0.1.3"
git tag:打标签的命令
-a 0.1.3:增加一个名为0.1.3的标签
-m "Release version 0.1.3":标签的注释
有时候如果忘了打标签,比如,现在已经是周五了,但应该在周一打的标签没有打,怎么办?????
先通过以下命令找到提交日志:
git log --pretty=oneline --abbrev-commit
然后使用以下命令在对应的COMMIT上打标签:
git tag v0.1.1 b09e0f04ce
③. 推送标签到远程仓库
因为创建的标签都只存储在本地,不会自动推送到远程。
如果要推送某个标签到远程,使用如下命令(普通的git push origin master操作不会推送标签到服务器端):
git push origin 0.1.3
推送所有本地标签到远程仓库,使用如下命令:
git push origin --tags
④. 删除本地标签的命令
git tag -d 0.1.3
⑤. 删除远端服务器的标签
假设在远程仓库中有一个名为 prod1.0 的标签,可以使用带有 --delete 选项的 git push 命令删除远程标签,如下命令:
git push --delete origin prod1.0
有时,我们可能有一个与分支同名的标签。在这种情况下,我们需要使用带有 refs 语法的 git push 命令而不是 --delete 选项,如下命令:
git push origin :refs/tags/prod1.0
⑥. 一般的操作流程如下:
git add .
git commit -m "fixed some bugs"
git tag -a 0.1.4 -m "Release version 0.1.4"
git push
git push origin 0.1.4
日志查看
git log
或者
git log --pretty=oneline --abbrev-commit
撤销与恢复
版本控制系统的一个重要任务就是提供撤销和恢复某一阶段工作的功能。
git reset 命令就是为这样的任务而准备的,它可以将项目当前版本定位到之前提交的任何版本中。
git reset 命令有三个选项:–mixed 、–soft 和–hard 。我们在日常使用中仅使用前两个选项;第三个选项由于杀伤力太大,容易损坏项目仓库,需谨慎使用。
–mixed
仅是重置索引的位置,而不改变你的工作树中的任何东西(即,文件中的所有变化都会被保留,也不标记他们为待提交状态),并且提示什么内容还没有被更新了。这个是默认的选项。
–soft
既不触动索引的位置,也不改变工作树中的任何内容,我们只是要求这些内容成为一份好的内容(之后才成为真正的提交内容)。这个选项使你可以将已经提交的东西重新逆转至“已更新但未提交(Updated but not Check in)”的状态。就像已经执行过 git-update-index 命令,但是还没有执行 git-commit 命令一样。
–hard
将工作树中的内容和头索引都切换至指定的版本位置中,也就是说自 之后的所有的跟踪内容和工作树中的内容都会全部丢失。因此,这个选项要慎用,除非你已经非常确定你的确不想再看到那些东西了。