赞
踩
JIRA 是 Atlassian 公司出品的项目与事务跟踪工具,被广泛应用于缺陷跟踪、客户
服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域
公司;
互联网公司的产品线多,分支多,不同的分支出不同的产品
我们不像一些互联网公司会有上千种产品线,会有上千个分支。
我们的产品结构相对单一,所以这里并不太用的到。
是的
master是主支,下面的是分支
(公司)SW的策略是onetrack
就是所有的代码全整到一个链上
就是你可以用同一套代码编出很多不同的产品
有专门的人员轮流管理MASTER分支,有的代码递进去当下通过了测试,之后报错了,需要专门的人进行监管。如果错误累计到一定数量,会关闭master主分支,先修代码和测试线,然后才允许开放,继续递代码进库
有专门的TEAM专门处理测试线上没跑过的代码的问题,用log文件去找具体是谁递交的代码。如果找不到对应的人,那么只能自己去修代码
Gerrit是一种免费、开放源代码的代码审查软件,使用网页界面。利用网页浏览器,同一个团队的软件程序员,可以相互审阅彼此修改后的程序代码,决定是否能够提交,退回或者继续修改。
代码审核(Code Review)是软件研发质量保障机制中非常重要的一环,但在实际项目执行过程中,却因为种种原因被Delay甚至是忽略。在实践中,免费、开放源代码的代码审查软件Gerrit是一个很好的选择。
它在传统的源码管理协作流程中强制性引入代码审核机制,通过人工代码审核和自动化代码验证过程,将不符合要求的代码屏蔽在代码库之外,确保核心代码多人校验、多人互备和自动化构建核验。
Gerrit适用性:几乎任何需要正式发布的项目都应当使用Gerrit来进行代码审查,如果Team中有新人,必须使用Gerrit确保代码质量。
1.什么是分布式和集中式?
分布式:
在不同服务器上部署不同服务模块,然后通过远程协同使用不同服务器模块;这类似于司令官模式,军队里的司令官充当着发号指令,给不同军种分配不同任务的角色;有了司令官统一协调军种,一切行动听指挥,那就能打胜仗;如果没了司令官也能打仗吗?答案:能;只不过没有司令官发号施令,各军种士兵就容易当炮灰;三个关键词:司令官,各军种,打仗;
集中式:
在同一服务器(也称为中央服务器)中部署不同的服务器模块,有需要的时候则统一调用中央服务器中的服务模块;这类似于学校图书馆,图书馆承担着学生借书和还书等功能;当图书馆关闭之后,那么学生就无法再借书或还书了;所以集中的最大的缺点就是当中心服务器出现问题后,其他人的就无法工作了;三个关键词:图书馆,学生,借书或还书;
From <https://www.jianshu.com/p/8b03546a7487>
安装完成后,还需要最后一步设置,在命令行输入:
$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"
From <https://www.liaoxuefeng.com/wiki/896043488029600/896067074338496>
创建一个仓库 git base
$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit
From <https://www.liaoxuefeng.com/wiki/896043488029600/896827951938304>
$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/
From <https://www.liaoxuefeng.com/wiki/896043488029600/896827951938304>
此时此文件夹就变成了一个git 仓库
下载notepad++
Git add<file>
Git commit -m "xxxx"
Git status 查看文件上传状态
Git diff 可以查看具体文件内部修改了什么东西
Git add 推送到版本库
Git log 可以查看每个版本改了什么
Git log --pretty=oneline 可以简化界面
git reset --hard +节点 就可以回退到上一个版本
如果你记得未来的版本号,就可以 git reset --hard + 未来的节点号
Cat + <file> 查看文件
记不到版本号:git reflog 查看之前的每一条命令
工作区(Working Directory)
就是你在电脑里能看到的目录,比如我的learngit文件夹就是一个工作区:
版本库(Repository)
工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。
Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD。
提交后,用git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别:
命令git checkout -- readme.txt意思就是,把readme.txt文件在工作区的修改全部撤销,这里有两种情况:
一种是readme.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
一种是readme.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
总之,就是让这个文件回到最近一次git commit或git add时的状态。
git checkout -- file命令中的--很重要,没有--,就变成了“切换到另一个分支”的命令,我们在后面的分支管理中会再次遇到git checkout命令。
如果已经 git add到暂存区, 用命令git reset HEAD <file>可以把暂存区的修改撤销掉(unstage),重新放回工作区:
git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD时,表示最新的版本。
如果想删除已经git add , git commit 的文件:
删除本地文件: rm test.txt
删除版本库当中的文件:
现在你有两个选择,一是确实要从版本库中删除该文件,那就用命令git rm删掉,并且git commit
删错了, 想要恢复 $ git checkout -- test.txt
小结
要关联一个远程库,使用命令git remote add origin git@server-name:path/repo-name.git;
关联后,使用命令git push -u origin master第一次推送master分支的所有内容;
此后,每次本地提交后,只要有必要,就可以使用命令git push origin master推送最新修改;
分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在,也就是有没有联网都可以正常工作,而SVN在没有联网的时候是拒绝干活的!当有网络的时候,再把本地提交推送一下就完成了同步,真是太方便了!
分支:
分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
小结
Git鼓励大量使用分支:
查看分支:git branch
创建分支:git branch <name>
切换分支:git checkout <name>或者git switch <name>
创建+切换分支:git checkout -b <name>或者git switch -c <name>
合并某分支到当前分支:git merge <name>
删除分支:git branch -d <name>
并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该bug,怎么办?
幸好,Git还提供了一个stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
From <https://www.liaoxuefeng.com/wiki/896043488029600/900388704535136>
注意:
git rebase 和 git merge 有啥区别?
rebase会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。
举例:如果你从 master 拉了个feature分支出来,然后你提交了几个 commit,这个时候刚好有人把他开发的东西合并到 master 了,这个时候 master 就比你拉分支的时候多了几个 commit,如果这个时候你 rebase master 的话,就会把你当前的几个 commit,放到那个人 commit 的后面。
作者:曹九朵_
链接:https://www.jianshu.com/p/4079284dd970
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
merge 会把公共分支和你当前的commit 合并在一起,形成一个新的 commit 提交
merge和rebase实际上只是用的场景不一样
更通俗的解释一波.
比如rebase,你自己开发分支一直在做,然后某一天,你想把主线的修改合到你的分支上,做一次集成,这种情况就用rebase比较好.把你的提交都放在主线修改的头上
如果用merge,脑袋上顶着一笔merge的8,你如果想回退你分支上的某个提交就很麻烦,还有一个重要的问题,rebase的话,本来我的分支是从3拉出来的,rebase完了之后,就不知道我当时是从哪儿拉出来的我的开发分支
同样的,如果你在主分支上用rebase, rebase其他分支的修改,是不是要是别人想看主分支上有什么历史,他看到的就不是完整的历史课,这个历史已经被你篡改了
作者:曹九朵_
链接:https://www.jianshu.com/p/4079284dd970
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
想问个问题~ 如果我在gerrit上面点merge(submit)和rebase,是什么区别?点submit的话,是直接把我gerrit链接的代码提到主分支上,然后rebase是会重新把当前主分支的加上我gerrit提交的代码重新再跑一遍测试,跑完之后过了之后,还需要 review之后,再submit一遍哇
submit就是最后的操作了。
submit之后就没有任何其他操作了。
rebase是跟库上最新的合一起,然后会自动重新跑测试
跑完测试肯定也是需要review的,因为git自动把库上最新的跟你的代码合在一起了
哦哦,相当于rebase是我自己git reset到最新的节点,然后cherry pick自己的链接再commit一遍的效果是一样的
是的
有时候你点rebase会报错就是有冲突,git的算法自己判断不了你到底需要哪些部分,不需要哪些部分
就需要手动cherry-pick下来,手动把你想要改成最终的样子保留。
那点了rebase那个框之后,勾选的 change parent version是什么意思哇
这个是可以选某个节点去做rebase
你可以指定某一个节点去做rebase,框里就填commitID
不填就是默认最新的
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
赞
踩
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。