git使用规范（绝密）.pdf

发布时间：2022-06-02 发布人：admin 分类：说明书资料大小：0.22M 资料格式：pdf 举报版权申诉

xiao987368-12561647-4744300845380732338.pdf-第1页.png

第1页 / 共6页

xiao987368-12561647-4744300845380732338.pdf-第2页.png

第2页 / 共6页

xiao987368-12561647-4744300845380732338.pdf-第3页.png

第3页 / 共6页

xiao987368-12561647-4744300845380732338.pdf-第4页.png

第4页 / 共6页

xiao987368-12561647-4744300845380732338.pdf-第5页.png

第5页 / 共6页

xiao987368-12561647-4744300845380732338.pdf-第6页.png

第6页 / 共6页

文本预览

git 使⽤规范 1 ⽬的开发⼈员 git 使⽤流程（规范） 2 提交规范 2 分⽀建⽴规范新功能开发分⽀建⽴规范 4 发布规范 4 4 目的作效率。此规范会不断地完善。强制执⾏！规范 git 的使⽤是为了避免 git 中央仓库分⽀混乱，导致发布出问题，提升我们的⼯　使⽤Git过程中，必须通过创建分⽀进⾏开发，坚决禁⽌在主⼲分⽀上直接开发。review的同事有责任检查其他同事是否遵循分⽀规范。　　　在Git中，默认是不会提交空⽬录的，如果想提交某个空⽬录到版本库中，需要在该⽬录下新建⼀个 .gitignore 的空⽩⽂件，就可以提交了　　把外部⽂件纳⼊到⾃⼰的 Git 分⽀来的时候⼀定要记得是先⽐对，确认所有修改都是⾃⼰修改的，然后再纳⼊。不然，容易出现代码回溯　　多⼈协作时，不要各⾃在⾃⼰的 Git 分⽀开发，然后发⽂件合并。正确的⽅法应该是开⼀个远程分⽀，然后⼀起在远程分⽀⾥协作。不然，容易出现代码回溯（即别⼈的代码被覆盖的情况）　　每个⼈提交代码是⼀定要 git diff 看提交的东西是不是都是⾃⼰修改的。如果有不是⾃⼰修改的内容，很可能就是代码回溯　　review 代码的时候如果看到有被删除掉的代码，⼀定要确实是否是写代码的同事⾃⼰删除的。如果不是，很可能就是代码回溯开发人员 git 使用流程（规范）

1-9项所有开发⼈员严格执⾏ 1. 下载代码（克隆分⽀） git clone git@gitserver.com:/path/project –b dev project 1) -b dev 指定想要下载的分⽀，去掉省略的话下载的是默认分⽀是master（注：默认分⽀可以修改） 2) project是我想要在本地创建的git库⽂件夹名字 2. 切换到分⽀，保证当前所在分⽀都已经提交完成 git ckeckout developer 3. 基于开发分⽀新建本地开发分⽀进⾏代码修改 git checkout -b lufei 4. 更新代码(注：每次修改前养成同步更新代码的好习惯) git pull --rebase 如果提⽰冲突，说明本地git库中未⼊库的提交中有修改和代码库中冲突了，修改冲突⽂件并删除冲突标识<<<<< ==== >>>>后: git add 冲突⽂件名 //加⼊git index中 git rebase –continue //继续更新到最新的base上 5. 修改、增加或删除代码⽂件到git index缓存中：修改或新增加代码⽂件： git add ﬁle_name 删除代码⽂件： git rm ﬁle_name 6. 提交本地git库index缓存中的修改

git commit –m “just a test for commit ” 如果本地修改不对或commit的LOG需要修改可以使⽤： git commit –-amend //修复上⼀次提交，不要修改Merge提交在提交代码时还要注意判断对代码的修改是否是⾃⼰的，多⽤diff⼯具，多查看log，防⽌代码回溯。 7. 更新代码(注：每次push前养成同步更新代码的好习惯) git pull --rebase 如果提⽰冲突，说明本地git库中未⼊库的提交中有修改和代码库中冲突了，修改冲突⽂件并删除冲突标识<<<<< ==== >>>>后: git add 冲突⽂件名 //加⼊git index中 git rebase –continue //继续更新到最新的base上 8. 推送提交到服务器上的git库中 git push 注：默认会推送到我们下载git库时的-b 后⾯加的那个分⽀，没有加默认是master，这个命令完整版实际上是: git push origin 当前分⽀名:我们下载的分⽀名 9. 解消代码冲突 git merge xxxx_branch 或者 git pull 时 or git rebase xxxx_branch 或者 git pull --rebase 时解消⽅法也是修改冲突⽂件并删除冲突标识<<<<< ==== >>>： git rebase –continue //继续更新到最新的base上 10. 代码提交前合并其他团队⼈员的提交 git checkout developer git pull origin developer 11. 将developer开发分⽀合并到⾃⼰修改的分⽀，并解决冲突 git checkout lufei git merge developer

12. 本地测试是否正常运⾏ 13. 切换到 developer 分⽀，合并本地分⽀，提交 git checkout developer git merge lufei git push origin developer 如果在测试过程别⼈有提交，这个 push 会有冲突，需要先 pull 为了尽量减少冲突，功能模块的开发⼀定要细分，每个开发⼈员负责⼀个模块的开发，尽量不要去修改其他团队成员模块的代码。每个开发⼩组的负责⼈切记做好功能开发细分！提交规范禁⽌使⽤-ff or –force 等强制提交，覆盖中央仓库的内容，除⾮你知道你在做什么！不要各⾃在⾃⼰的 Git 分⽀开发，然后发⽂件合并。正确的⽅法应该是开⼀个远程分⽀，然后⼀起在远程分⽀⾥协作。不然，容易出现代码回溯（即别⼈的代码被覆盖的情况）提交说明的结构括号中为可选): 当提交内容简单时，尽量⽤的⼀句话描述”做了什么”。句⼦结构可以分解为(⽅动作+组件+[原因-索引] 动作:即提交的⾏为，句⾸字母⼤写。有⽂章认为只使⽤ Update、Add、Remove三个动作就可以满⾜使⽤。但是为了更精准地描述，我还是倾向于使⽤其它动词，下图有常见的动作⽤词。每⼀次提交只应该有⼀个动作，多个动作请适当拆分。组件:指的操作内容，应该⽤精准的名称，类名⽅法名等，⽅便快速定位。不应该提供宽泛的⽂件名。原因及索引:必要情况下⽤精简的语句描述原因，有问题追踪系统的话可以指向

相应的 ID。分支建立规范所有项⽬采⽤分⽀开发⽅式，分⽀分为开发分⽀、新功能分⽀、修复分⽀、其他⽀和 master 分⽀分⽀命名说明 master developer feature bugﬁx-{date} 随意发布分⽀主要的提交分⽀新功能分⽀ bug 修复分⽀特殊情况时建⽴的分⽀ master 分⽀开发分⽀功能能分⽀修复分⽀其他分⽀

新功能开发分支建立规范有⼩组长负责创建通知组员。⼀项重⼤的功能，⼀定要新建⼀个分⽀，避免影响原来的 developer 分⽀，这个分⽀发布规范 1.⽣产环境必须使⽤主分⽀发布 2.测试环境使⽤ developer 或者 feature 分⽀

分享到：

赞收藏

资料库

git使用规范（绝密）.pdf

相关推荐

行业

热门标签

最新资料