在使用github前, 先熟悉一下git的命令行(git可视化工具收费),不管可视化工具还是命令行, 都需要理解git常用哪些操作.
复制代码
git的核心概念
1. 仓库 (通常origin为远程仓库, 区别于本地仓库, 一般操作远程仓库只需要在命令行后面加上远程仓库名,例: git checkout -b dev origin, 创建远程dev分支)
2. 区域 (工作区,暂存区,仓库区(本地代码区) 管理文件的版本控制, 与之相关的操作有 git status git commit等)
3. 分支 (多人开发最重要的协作方式)
复制代码
git相关的简单命令
git提交文件流程
提交三步走用起来觉得麻烦的,可以使用git bash输入命令, 创建别名
alias ed=’git add .;git commit -m “project update”‘;git push origin
之后在命令行中输入 ed(自定义的) 可以完成提交到远程仓库
冲突的产生是因为在合并的时候,不同分支修改了相同的位置。所以在合并的时候git不知道那个到底是你想保留的,所以就提出疑问(冲突提醒)让你自己手动选择想要保留的内容,从而解决冲突。
git stash pop取出备份的时候也会出现冲突
比如,有个文件login.java,,你修改了一段代码,git stash保存以后,你从服务器上继续git pull了别人的代码,
如果此时,别人的代码也修改了login.java。
此时当我们使用git stash pop 的时候,就会发生冲突,因为我们的修改不是基于最新的pull下来的文件的基础上。。所以git很难判断
处理方式:
备份我们修改后的文件,,删除程序文件中我们所做的修改,重新pull,,然后在用我们备份好的文件替换掉,,再push上去即可。
git命令行相关的知识就讲这么多, 如果需要更深入的理解,可以了解下列网站
gitbook.liuhui998.com/4_2.html
github中参与开发有两种方式:
1、Collaborators:
项目所有者 进入Repo,点击Settings-> Collaborators-> Add collaborator 即可邀请。
第一次push代码时需要输入自己的账号密码进行验证,如果账号在Collaborators中,就可以push成功。
2、Fork & Pull request:
pull request 之后, 往往都需要code review(代码审查)
代码审查 Code Review 注意事项:
一次不要提交太多commit, 降低评审工作量;
评审时间,不能隔太久再提交评审, 不然评审这可能要把思绪拉回到上周甚至上上周, 影响评审进度.
代码风格是否满足公司代码规范【reviewer要求熟悉规范要求。】;(交给机器做, 推荐prettier + eslint)
代码经过完善的设计;
代码不应该复杂超过原本所必须的;
开发者不该实现一个现在不用而未来可能需要的功能;
代码有适当的单元测试;
开发者对于每样东西有使用清晰、明了的命名;
注释要清楚且有用,并只用来解释why而非what;
评审结论要具有指导意义;
解决冲突难以达成共识时,需要面对面或者拉起更大的团队讨论,带上Leader;
结语:
总之无非就是 配置, 日志, 分支的增删改查, 代码提交(退回)流程, 冲突处理技巧, 这些次生的概念都是为核心概念而服务的, 站在更高的角度理解这些细枝末节, 甚至命令行都能推导出来大致的结构, 根本不需要死记硬背, 想做什么,相对应的命令行就能想到.
最后, 如果想更快的了解更多的命令行或者工作中突然忘记了该用什么命令行, 在git bash中输入 git –help即可查看当前所有的命令行及其含义, 一旦你早已理解了git的核心能力,运用起来当然会得心应手.