工具下载安装
-
git客户端工具 - 图形化操作工具
TortoiseGit -
TortoiseGit汉化语言包
内部下载地址：ftp://192.168.3.2/版本管理/Git/ 帐号密码:ftpdown down_888
- Git-2.12.2.2-64-bit
- TortoiseGit-2.4.0.2-64bit
- TortoiseGit-LanguagePack-2.4.0.0-64bit-zh_CN
开始干活
常用配置
通过TortoiseGit工具的设置,可以提高日常操作代码仓库的效率,请根据自己后续的需要回看此点进行配置.
- 设置右键直接可以看到的菜单,比如拉取、提交、推送、签出等常用菜单项
- 设置隐藏菜单项,即在二级菜单中你都找不到的,可以防止干扰,使用一定时间后可以根据自己的需要干掉一部分,清爽舒心
- 查看差异及合并工具指定,此处强烈安利
BCompare,自带的工具让人感到绝望
具体配置项
克隆版本库（下载代码）
打开 公司内部代码仓库,定位参与开发的版本库并打开到概况页面（默认即进入概况页）
本地准备好存放代码的目录,右键克隆(git clone)并确认窗口内的目录是否为想要存放代码的位置,请一定按默认名称存储,防止多个项目的代码搞混
获取最新代码
首次克隆代码,本地代码仓库为远程仓库设置的缺省分支的最新提交,若开发阶段暂未启用新分支的项目组可以不需要再次获取代码,否则通过右键菜单中的拉取（git pull）获取最新提交的代码.
拉取与获取的区别？（
git pull&fetch）
- 拉取：获取最新提交代码 + 获取
- 获取：仅获取远程仓库最新分支、标签等指针类信息
分支策略（项目经理关注）
git带有非常强大的分支管理能力,可以满足各类研发或迭代项目的版本控制需要,很多灵活高级的用法可以根据项目的需要去调整,大家可以根据相关的教程模拟测试并应用,此处不再赘述.本次仅以最简单常见的敏捷开发过程中如何保障发布版本与开发不相干扰.
单主干模式由于所有开发人员都在维护同一套版本代码,如果没有自动集成及自动化测试支撑,无法确保主干代码的稳定性.通常已发布的产品,至少会有两个主分支,其中之一对应生产环境,另一支对应开发环境,线上问题的修正与快速迭代同步进行.
- 默认创建的版本已存在
master分支,此分支用于发布到生产环境,生产环境出现问题基于此分支创建新分支进行修复,修复完成后合并到master及开发分支. - 创建一个用于新功能研发的分支
develop,每次新功能的发布都基于此分支,发布后的分支需要及时合并到master分支.
如果项目组中开发成员较多,可以再切割为更小规模的小组用于某独立新功能的研发.
日常研发是否需要分拆多个分支进行,取决与团队的规模,通过人员或功能的划分尽可能的减少多人改写同一代码单元的可能性,以减少日常冲突出现的几率.
创建分支
项目经理根据研发团队版本控制需要创建对应分支,可以通过签出(git checkout)时选择create new branch或直接右键创建分支(create branch).
开发成员根据为避免冲突及代码覆盖,可以签出时创建本地工作分支(原因见如何减少冲突部分).
分支选择（成员关注）
- 研发角色
根据项目经理分配,管理与开发任务对应的开发分支,日常开发时,请确保分支选择正确,每日开始工作前获取最新代码,确认分支名称.
查看或查看分支名称,通过菜单右键中的
签出（git check out)来操作或查看.
到需要提测发布阶段时,从develop分支开出发布分支(release类型),系统测试完成后合并到develop及master分支并删除该发布分支.
- 维护角色
值班或其他排查问题的同事,需要将分支定位到master分支进行跟踪,发现紧急问题基于master分支开出修复新分支(hotfix类型),修复后及时合并到主干及开发分支并删除修正分支.
| 分支类型 | 命名规范 | 创建自 | 合并到 | 说明 |
|---|---|---|---|---|
| feature | feature/* | develop |
develop |
新功能 |
| release | release/* | develop |
develop和master |
一次新版本的发布 |
| hotfix | hotfix/* | master |
develop和master |
生产环境中发现的紧急bug的修复 |
提交代码
提交与推送的区别(
git commit&git push)
前置是提交到本地的代码仓库,后者是将本地代码仓库已提交的内容同步到远程代码仓库
代码做出更改后,右键选择提交,备注本次提交变更的内容,或者在vs等ide中集成的工具直接提交.也可以提交并推送,推送时可能会遇到提示本地代码仓库版本较低或出现冲突的情况,具体处理见合并分支及冲突解决部分.
合并分支(merge)
- 开发成员的代码合并
每个开发的电脑上都相当于有一套版本库,在将代码推送到远程仓库时,就涉及代码合并.
原因说明
从远程拉取最新代码时,相当于建立了一个远程分支的分支,并基于此分支做后续改动,而远程的分支又有其他同事在同步改动,此时就出现两个不同的分支,所以在拉取代码时也相当于做了一次代码合并,一旦代码存在冲突就需要做合并
- 项目经理的代码合并
新功能的发布\生产环境bug修正,最终都需要合并到master或develop分支,如果功能划分时重合度较高,此时合并代码的工作量多\风险高.
具体合并的方法:
- 先签出到目标分支上,拉取最新代码.
- 操作合并(
merge),选择源分支(及需要合并到主干或开发分支的工作分支). - 通过日志与合并前的最后一次提交做对比,复核代码的正确性.
- 如果3中出现冲突,按下方解决冲突的方法处理.
冲突解决(resolve conflicts)
具体开发过程中会发现,其实冲突做所难免,大家都需要知道如何正确的解决冲突.
- 何为冲突
多人在同时维护同一份代码文件且git无法判断是否改动不同的代码块时,就需要人工介入协助完成无法自动合并的内容.
- 处理冲突
可以通过BCompare直观的查看冲突的原因,从下图中可以看出解决冲突涉及三个版本(BASE LOCAL REMOTE),其中BASE为冲突产生的两个分支最近一次继承的提交(都是从此出衍生而来).
根据实际情况整合得到正确的输出在工作目录下.
创建标签(create tag)
标签作用是定位到某个稳定的版本,可以供发布时回滚或问题追溯,标签的使用与分支基本一致,差别在于标签不可再次提交改动,具体应用同如何签出到某个分支.
- 项目进入发布阶段时,项目经理需要及时对稳定的
develop或master分支打上标签 - 生产环境出现bug修复后及时给
master分支加上新标签
如何减少冲突
解决冲突是非常耗费精力且风险很高的一项工作,而我们通过一些技巧可以避开一些不必要的冲突.
- 合理划分各开发成员维护代码的范围,尽可能的减少多人维护同一单元的情况出现.可以通过模块的划分\公共单元特定人维护等工作任务分配时进行物理隔离.
- 合理拆分开发团队,通过分支策略隔离日常开发过程中的冲突(注:不能解决发布时合并代码的冲突).
-
开发成员在具体开发过程中,尽量自行在本机工作区再次建立工作分支,在专项工作完成后再合并到开发分支并推送到远程仓库.
git日常开发分支管理
少量修正代码,可以不新建分支再合并,可以直接调整完后不提交,使用贮藏(
stash save)将当前的变更存储起来,然后再次拉取最新代码,再弹出贮藏(pop stash).
另外可以通过贮藏列表(stash list)查看多次贮存的内容
如何避免覆盖他人代码
当你若无其事的推送完一次代码,不久后队友发现令人绝望的事故---提交的代码不见了!
没有动过他们的代码\没看到有任何冲突的提示,为什么???
具体的原因基于git自动合并代码的机制,合并代码时基准版本是local而不是remote,当发现你本地的文件较新时(与本地操作系统的文件系统有关),它可能会认为你把部分代码删除了,然后他人所加的代码自然被无情的覆盖.
为了减少不必要的麻烦(可能整个团队都要为此做一次代码恢复...),大家最好参照如何减少冲突部分推荐的做法进行日常的版本维护(可能有其它更实用的办法,集思广益).另外再每次推送代码到远程仓库后,请按开发规约review提交的代码,如果发现自己提交中包含多个未改动的文件,及时找项目经理协调解决减少对其他成员的影响.
如何恢复被覆盖代码
- 先定位到源头,找到该成员提交前最后一位其他成员的提交
- 本地代码拉取到最新状态,复原(revert to this commit)指定的提交(含工作区与仓库索引项,最下面的选项)
- 推送到远程仓库,推送时把强制(
force)选项中的 知道所有的变更(known changes) 勾选,确认后将强制把远程仓库的代码恢复到此提交 - 所有项目成员检查本地代码仓库,是否包含源头中被覆盖的提交
- 源头及在被覆盖的代码基础上做过代码改动的成员,按如下步骤修复:
5.1 确认所有内容提交后在此本地分支上建立一个新的分支
5.2 将工作分支复原到未被影响的提交(可再拉取一次确保最新)
5.3 将刚才新建的分支合并到工作分支,提交并推送到远程仓库
入门到精通(DIY)
- git中文手册
- git官方手册
- 廖雪峰Git教程