Home
>
源代码吧
>
源代码管理
源代码管理

time:2020-07-30 10:47:04

author:重庆佰鼎科技有限公司

【Font size: big medium smail

本文由重庆佰鼎科技有限公司提供,重点介绍了源代码管理相关内容。重庆佰鼎科技有限公司专业提供源代码吧,源代码漫展,源代码怎么打开等多项产品服务。公司成立于至今,坚持用服务打动人心,用质量打造口碑,立志成为行业内的领军。

源代码管理为了方便管理代码,方便团队代码的持续迭代与发布,需要制定git工作流协调团队开发。本文将涉及到代码的开发、分支管理与日常的一些注意事项。首先介绍Git工作流的思路

依靠两个主分支master、develop保证代码的持续更新与部署的有序性。开发的时候主要是依托于develop分支开发,基于develop分支新建分支,经过严格测试之后,才能合并到develop中,保证develop代码的稳定性(也就是日常开发中不再轻易修改

develop分支代码,这与我们之前的习惯不一样,要求我们要掌握建立分支、分支切换、代码提交等基本命令)。而master的代码等于或者落后于develop的代码,是作为develop分支一个更加稳定版的保存与跟踪,用来部署正式的代码。master分支和develop分支配置不一样,前者是正式环境(生产环境),后者是开发环境。通过这两个分支保证团队代码的持续迭代更新。1 为什么使用分支?在项目层面,一个大项目切分成多个小项目,利用分支来管理每个小项目,保证项目的同步进行,提高开发效率。在代码层面,利用分支管理代码的提交、回滚、合并等操作,减少人工合并的成本,提高代码管理的效率。在个人层面,利用分支管理自己开发代码与团队代码,方便自己合并代码、开发单独的特色分支,提高个人开发效率。2 创建分支相关命令行:git branch [branch-name] 创建分支

git branch [branch-name] [commit-head] 创建基于head提交的分支

git branch 列出分支

git branch -r 列出远程分支

git branch -a 列出所有分支

git checkout -b [branch-name] 新建一个本地分支,并切换到该分支源代码管理

git checkout -b [branch-name] origin/[branch-name]

新建一个基于远程分支的本地分支,并切换到该分支

git checkout [branch-name] 切换分支

git branch -d [branch-name] 删除分支

git branch -dr [remote/branch-name] 删除远程分支

git fetch origin 下载远程仓库代码的变动

master分支、develop分支工作流源代码管理

分支分类:

master分支:专门用于部署以及负责线上代码回滚的分支。 develop分支:专门存放经过测试之后,保证代码无bug代码分支。develop衍生分支有:3.1、 项目开发分支(feature分支):此分支特点是周期长(最短项目周期可能为一周,最长可能会长达一个月甚至更久)、团队协作(一般至少包括一个前端和一个后台)、代码量大,工作方式是需要创建本地以及远程feature分支,代码基于develop分支代码,经过开发、测试之后,最终合并到develop分支上。当项目上线之后,分支会保留一段时间(一般一周左右,最长不超过1个月),直至最终删除。 3.2、紧急bug、其他问题修复分支(hotfix):此分支特点是修改时间短(一般时间可能为几个小时,也有可能会是一天甚至更久)、优先级高、代码量稍小、改完之后急需测试、上线。此分支代码也是基于develop(此时需要确认develop纯度,不能有不稳定的污染代码,如有回滚到稳定版代码,否则影响bug修复)。此分支会是团队协作或者单人,团队协作工作方式会类似feature分支,单人只需构建本地分支即可满足开发要求(本地分支千万不要放在线上,以免给同伴带来干扰),当修复上线一段时间之后(时间为3~7天),便可以删除。 feature分支工作流 分支命名规范:

feature分支:feature-xxx 例如 feature-paltformshotfix分支:hotfix-xxx 例如 hotfix-wholenet3.代码开发相关命令行:

git status 显示有变更的文件

git log -5 查看最近5条历史记录

git log --stat 显示commit历史及每次commit发生变更的文件

git add . 将文件添加到缓存去区

git add [file]将特定文件添加到缓存区

git rm [file] 删除工作空间的文件 前提:feature分支的开发属于日常开发,需要保证进度完成相关需求,在每个特定时间点完成功能开发。紧急bug、其他问题修复分支需要保证在短时间内走好日常开发流程,避免返工。

4.代码提交相关命令行:

git status 显示有变更的文件

git log -5 查看最近5条历史记录

git log --stat 显示commit历史及每次commit发生变更的文件

git add . 将文件添加到缓存去区

git add [file]将特定文件添加到缓存区

git rm [file] 删除工作空间的文件

git commit -m [comment] 提交到本地仓库

git push 推送到远程分支

git push origin [branch-name] 推送到对应的远程分支

git commit -a -m [branch-name] 直接提交到本地仓库

本地仓库代码提交条件:完成功能点,自测无问题,在保持头脑清晰情况下提交到本地分支。

远程仓库代码推送条件:通过一轮测试,bug问题不大,对同伴的影响较小;联调时是代码提交最为频繁的时候,注意解决好每个问题后,做好自测流程,千万不要匆忙提交影响同伴工作效率。测试的时候尽量做到bug批量解决,自测无误之后,再进行提交,减少代码污染。

提交代码之前的代码审查:在代码提交过程中可以做很多控制操作,例如pre-commit钩子是最先触发运行的脚本。在提交一个commit之前,该hook有能力做许多工作,比如检查待提交东西的快照,以确保这份提交中没有缺少什么东西、文件名是否符合规范、是否对这份提交进行了测试、代码风格是否符合团队要求等等。(这一块后期慢慢加入)

5.代码合并相关命令行:

git merge [branch-name] 要合并的分支名

git stash 代码存储到储藏室

git stash list 查看储藏室列表

git stash pop 弹出储藏室堆栈

git pull 下拉代码代码合并分为:

本地代码合并远程同伴代码git不会删除任何有冲突的代码,只会进行冲突标注。

注意:本地代码需要提交到本地仓库,方便回滚

远程代码和本地代码是基于同一节点、但序列头不同的两个版本代码。合并时,冲突较少直接解决冲突,然后进行提交操作;冲突过多,需要大量人肉,先将本地代码先回滚,备份一下,然后讲本地代码先存储起来,拉取远程代码进行人肉比对。

冲突较少,拉取远程代码失败,操作步骤:

git log -2 查看提交历史,找到需要回滚到的序列头

git reset [head] 代码回归到head版本

或者 git reset --hard 暂存区和工作区代码回到上一次提交状态

git stash 代码缓存

git pull 拉取代码

git stash pop 推出代码比对冲突过多,本地代码已经污染,操作步骤:git log -2 查看提交历史,找到需要回滚到的序列头

git reset [head] 代码回归到head版本

或者 git reset --hard 暂存区和工作区代码回到上一次提交状态

比对工具比对2.

本地分支合并另一个本地分支(feature分支代码基于develop分支,经过开发之后需要再合并到local develop分支上。)

本地开发的时候,可能会遇到同一个主项目需要同时开发多个子项目的情况(例如:边修改bug边上活动页边开发新功能),此时,需要建立自己的分支来辅助开发,来解决多个项目同时需要修改、优先级不同的情况。

注意:本地分支请不要推送到远程,分支经过测试之后再合并。工作情境:

公司最近刚过一周年就迎来国庆节,小贞贞童鞋需要制作活动新功能,她基于develop新建了一个feature-activity分支(feature-activity此时代码和develop代码相同)

git checkout –b feature-activity 紧张开发中,此时产品羊跑过来要求急需修改一个bug,且该bug的优先级就高于活动功能了。小贞贞没办法就先将代码提交到本地feature-activity 分支。

git add .

git commit –m ‘产品狗真可怕,我要跑路了’ (代码提交到feature-activity分支)

然后切换到develop分支

git checkout develop基于developing分支新建了hotfix-bug分支

git checkout –b hotfix-bug (hotfix-bug此时代码和develop代码一样)修复了bug之后,代码先提交到本地hotfix-bug分支

git add .

git commit –m ‘使出了洪荒之力终于解决了问题’经过测试,bug修复已经没问题,需要合并到develop小贞贞鼓起勇气将分支切换到develop

git checkout develop

git merge hotfix-bug将hotfix-bug分支合并后,小贞贞又可以去feature-activity 分支开发了,feature-activity 分支开发完后和hotfix-bug一样合并到develop分支。

通过这种方式,小贞贞有条不紊的在代码路上越走越远,越陷越深,保证了代码的持续迭代。

3.分支替换

出现这种情况一般属于重构、代码结构改动特别大,代码量差异太大。

需要反向操作,把develop分支代码合并到platforms分支,代码整合;当platforms分支经过超级严格测试之后(必须是3轮测试),替换develop 分支。

注意:如果合并出现问题,代码可以回退到之前版本;合并的时候新建一个项目,合并完成之后拿这个项目测试,然后用这个项目替换本地platforms分支。?增加新分支 若确实不想这么做,可以新建本地temp分支进行合并,然后temp分支替换platforms工作情境:

小天使童鞋对后台忍无可忍,坚定信念要重构后台,于是年轻的他开始夜以继日的码代码。

等到完成开发,经过测试大大惨无人道的测试之后,小天使童鞋人肉合并developing分支到platforms分支,此时操作是

拷贝platforms本地分支副本

本地副本分支与develop分支合并

合并完成,自测

自测完成,测试

测试无误,完成代码合并本地副本完成后,替换platforms分支代码,接着替换develop分支代码;

替换之后,推送到远程develop分支

替换develop的好处是继续维护develop分支,不需要新增项目就新增一个主分支,避免主分支换来换去,造成项目混乱。

6.代码打标签相关命令

git tag 列出所有标签

git tag -d [tag] 删除本地分支

git tag [tag-name] 新建本地标签

git show [tag] 查看标签信息

每次正式上线需要打一次标签,标签分级:VX.[ ].[ ]:新功能上线,大量的功能优化等;

V[ ].X.[]:较大的功能优化,性能优化等;

V[ ].[ ].X:较小的功能优化、性能优化等。

代码正式上线时,依据具体情况打好标签。

7.代码部署部署测试部署测试的代码,是经过自测且实现功能点代码,部署前需要通知到其他开发人员。

部署正式代码经过测试之后,已经是稳定代码,达到了上线标准之后就可以部署代码;

上线时代码需经过本地运行无误,确认没有问题再部署;遇到严重问题需回滚代码。

部署前需通知相关负责人。

注意:develop分支是测试环境,master分支是正式环境(生产环境),需要注意数据库配置以及其他不一样的配置。

8.代码回滚回滚条件

测试、正式线上遇到重大bug合并代码,污染了当前分支,问题很多本地代码需要到历史版本9.代码分级合并代码的时候根据优先级顺序来合并代码:P0级:如急需上线的项目代码,包括活动项目、紧急bug修改,为最高级;P1级:大项目代码、合并时间较长、影响较大的代码;P2级:优化样式、修复小问题、影响不大的代码。10.代码测试11.文件忽略

/target//.settings/.classpath/bin/

/.project(原始版本有,平时忽略)/src/main/webapp/WEB-INF/transactions/

/src/main/webapp/WEB-INF/resources

/*.DS_Store/.git-credentials

/npm-debug.log12.注意事项正常情况下,代码起源于develop分支。开发者自己本地的开发分支不要太多,避免分支过多遗忘分支作用。特殊情况下,如遇到节日banner活动上线,此时develop正好代码有问题,那么a同学可以基于master开发,此时代码量修改很小,不会影响代码稳定性,但a同学需要非常细心,避免发生低级错误。新项目进入开发阶段之前,负责管理代码的人首先新建分支,并通知到团队中所有的人并附上说明。项目进行时,a同学需要去处理优先级更高的bug或者是项目时,a有可能会新建一个自己的本地分支S,但是功能还未修改完,此时a同学有可能会遇到优先级更高的问题,a同学需要暂时中断S,然后将代码提交到本地分支;新建新分支X,当完成X开发后,将代码合并到本地根分支,删去X分支;然后切换到分支S,继续开发,直到最终完成各个项目的开发。优先级特别高的分支需要合并到develop上的时候,提前通知其他人需要合并代码,其他人暂停对develop代码的操作,来保证合并代码的有条不紊。Git工作流没有提交申请处理的队列或者提醒,需要团队所有人遵守:每当有合并代码操作时,需要通知所有人自己在合并代码;当代码合并完成,测试没问题之后,推送到远程的时候需要告知其他人,保证所有人知道代码有修改过。

Reprint please indicate:http://www.cnsoftweb.com/ydm-3433.html