Git笔记

前言

最早的时候只知道在GitHub注册账号,尝试把自己的代码放到GitHub.看的git book不太明白的地方都跳过了.这样在实习时遇到了麻烦~第一次交代码提到了upstream/master被leader骂,还有提交一次之后代码有问题多了好几个fix commit.于是就记了些笔记.

打算本周写一篇关于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 mergegit 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 --continue

Commit格式

第一行是标题,不建议太长.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中文教程,来自国外社区的优秀文章和个人实践


Git笔记
https://blog.kdwycz.com/archives/git-note/
作者
kdwycz
发布于
2015年12月13日
许可协议