Git笔记
前言
最早的时候只知道在GitHub注册账号,尝试把自己的代码放到GitHub.看的git book不太明白的地方都跳过了.这样在实习时遇到了麻烦~第一次交代码提到了upstream/master被leader骂,还有提交一次之后代码有问题多了好几个fix commit.于是就记了些笔记.
打算本周写一篇关于git知识的总结.本想分成两篇来写,初级篇给学校的学弟学妹参考,但是想了很长时间发现并不会比别人的教程写得好,还是把资料归类摆好大家自取吧~毕竟如第一句话所言……
基础
为什么要版本控制
如下图所示~如果把每一版都放到单独的文件,显得很杂乱还占空间.使用一个文件的话,如果发现哪里做错了想恢复就非常困难.版本控制工具能同时兼顾以上两点.而且,在多人合作开发的时候也可以使用版本控制来管理版本问题.
入门学习
- 初识Git/Github
上图就是这里来的
- 廖雪峰的Git教程
最好的中文入门教程之一
- 猴子都能懂的Git入门
另一个看起来不错的入门教程
- 15分钟学号Git
Github推出的交互式的教程,强烈推荐.最好的入门教程没有之一! 不过讲解是英文的,而且有些静态文件要翻墙
- 学习Git分支
交互式的学习很赞,但是没有讲解文件的变化,适合了解基础概念后练习使用
然而并没有推荐如”Git book”厚厚的书.就像学习Linux一样.我们学习工具是为了更好的工作,而不是做工具的奴隶~掌握常用命令和最佳实践就好
Git工作流
Git是强大的工具,但是使用不当也无法发挥效果.对于工作流来说,几年前讨论出了最佳实践.但是每个团队根据实际情况不同,还是稍有变化.
自己的实践
最早自学git的时候,只会 git add . git commit -m "abcd..." git push origin master这三个命令~并没有分支的概念
在豆瓣实习的时候,用CODE系统.项目的部署分支是master,推荐fork一份到自己的目录下,在自己的origin dev分支做开发,然后向upstream master提PR.豆瓣有Code Review的规范,要求PR至少被一个人review并给出LGTM(Look Good To Me)才能合并.后半段的实习在review最严格的条目团队,虽然代码天天被吐槽嫌弃,但是学到了很多东西
现在的公司,项目仓库是leader的github私人仓库,所以看起来并不能fork,而且有两到三个分支需要部署.学到了一些新的东西~比如master分支和一个更新的nf分支在部署,各有bugfix分支.如果bug只在nf分支存在,就在nf-bugfix分支改bug(更好的实践是在自己的my-nf-bugfix修改,在merge进nf-bugfix,最好merge到nf,这样log更好看写),如果是master的不过(两个分支都存在的bug),就在master-bugfix修改,然后merge到master后,再把master分支merge到nf分支(原谅我语死早)
笔记
添加ssh-key
ssh-keygen -t rsa -b 4096 -C "[email protected]"
cat id_rsa
ssh-add -K id_rsa写在这里是因为,Mac在ssh-add的时候要加上-K
与上游代码同步
将 fork 的仓库与上游同步时（当新建分支的时候应该首先和上游同步一次），应使用 git fetch upstream && git rebase upstream/master （或 git pull --rebase upstream master ），而不是 git merge 或 git pull ，个人开发永远不要使用 Merge（之后在 web 上合并 PR 的时候才会 Merge）！ 这样可以保持清晰的提交历史，并防止覆盖他人的修改
- 对于一个commit,如果之后发现有错误.修改完最好合并在之前的commit
改动内容插入之前的commit（倒数第二个）
如果你的一个commit,发现有问题.如果是最上面的commit,修改的话直接git add . && git commit --amend就行,但是不在最上面的话,就可以用这个方法.
并不建议为了(在同一个PR下)用一个新的commit去修正之前的commit
git stash
git rebase HEAD~2 --interactive
(想改的点前面的pick改成edit，更多的命令看说明)
git stash pop
git add . && git commit --amend
git rebase --continueCommit格式
第一行是标题,不建议太长.Github推荐60个字符之内.豆瓣的一个同学给我举了栗子说最好30个字符内(QwQ这么短根本表达不了意思好吧)
在一篇文章看到了这样的格式,很喜欢:
- Add: something
- Bug [fix|found]: describe the bug or fix.
- Chg: something
- Del: something
- Enh: some treatment
- New: something
- Tmp: for some cause
空一行之后写具体的内容,可以带上团队协作软件对于这个功能/Bug的需求描述地址
其他好资源
- git-recipes
高质量的Git中文教程，来自国外社区的优秀文章和个人实践