目录什么是gitgit 配置基本操作工作区、暂存区、版本库版本回退撤销修改删除文件分支管理创建、切换、合并、删除分支合并冲突合并模式分支策略bug 分支强制删除分支远程操作理解分布式版本控制系统创建远程仓库克隆远程仓库方式一HTTPS方式二SSH向远程仓库推送拉取远程仓库忽略特殊文件给命令配置别名标签管理创建标签将标签推送到远端多人协作开发多人协作一多人协作二企业级开发模型DevOps系统开发环境Git 分支设计规范什么是git员工需要完成一份设计文档但不一定一次就能达到最终要求于是反复修改但之前某一次修改的样子已经无法获得了于是员工每次不再对源文档修改而是新拷贝一份文档修改这样就可以获取任意一次修改的文档但随着文档数增多维护成本很高也不易得知某一份文档修改了哪些内容于是诞生了版本控制器版本控制器是记录每次的修改以及版本迭代的一个管理系统git 就是一款最主流的版本控制器可以控制电脑上所有格式的文档对于开发人员来说主要就是项目中的源代码文档。文本文件很容易记录修改了什么内容而二进制文件是无法知道修改的具体内容因此尽管图片、视频这些二进制文件也能被 版本控制 管理但没法追踪文件变化具体改了什么内容版本控制器是无法知道的git 配置创建本地仓库git 可以管理电脑上所有格式的文档但并不能追踪任意位置的文档只有文档被放在了git 的本地仓库中才能被git追踪管理git init //创建本地仓库初始化完成后当前目录下就多了一个 .git 隐藏目录文件注意不要去修改 .git 目录下的任何内容否则就会破坏本地仓库配置本地仓库git config -l //查看仓库配置 git config user.name xxx //配置姓名 git config email.name xxx //配置邮箱 git config --unset xxx //删除配置如果想删除配置也是可以滴刚才配置的选项只是在当前的 git 仓库生效了而一台机器上可以有多个本地仓库如果要让配置在所有的本地仓库全部生效可以加上 --global 选项如果是全局配置的删除时也要携带--global选项才能进行删除基本操作工作区、暂存区、版本库我们在 gitcode 目录下新建了一个 readMe 文件这个文件能被 git 追踪管理吗是不能的当前的 gitcode 目录我们叫做工作区工作区就是在电脑上你要写代码或文件的目录工作区下的文件的变化是不能被 git 管理的需要将 工作区的变化 提交到本地仓库中才能修改而 .git 就是本地仓库不属于工作区又叫做版本库这个版本库中的所有文件都可以被Git管理起来因此我们需要将工作区变化提交都本地仓库中但要注意不要直接 在 .git 目录下操作这是不被允许的我们需要使用 git 提供的指令操作.git 目录下还有一个区域叫做暂存区工作区的修改是先被添加到暂存区的而后才会提交到版本库里面工作区、暂存区、版本库的关系如下当我们只是在 gitcode 工作区下新建了一个 readMe 文件并没有执行 git add readMe 到暂存区中此时暂存区 index 是不存在的当我们 git add 之后.git 目录下就会出现 indexHEAD是一个指针字段指向了 master而工作区文件发生的变化并不是直接被记录在暂存区/版本库中的而是记录在对象库中也就是上图中的 objects 对象暂存区以及master 分支中记录的是指针对象库中一个个对象的地址我们现在给 readMe 文件新增两行数据然后 add 到 暂存区再 commit 到 版本库使用 git log 查看历史提交记录commit 后面的数字是啥呢叫做 commit id每一次 commit都会有一个 commit id 这一串数字的前两位是 objects 文件夹下的一个目录文件名后面的数字是具体的该目录下的具体文件名git 提供了 git cat-file 指令可以直接根据 commit id查看对象库的具体对象的内容-p 是 pretty 的意思可以更加优雅的打印出来git add . 可以一次性将工作区的所有变化添加到暂存区中同时我们也可以看到master 分支记录的是最近一次 commit 的 commit id 最近一次 commit id 的对象中有一行 tree 字段存储了历史提交的所有 commit idgit 追踪记录的是文件发生的变化使用 git status 可以查看当前仓库的状态git diff 查看暂存区和工作区之间的差异版本回退之前我们也提到过Git 能够管理文件的历史版本这也是版本控制器重要的能力。如果有一天你发现之前的工作做的出现了很大的问题需要在某个特定的历史版本重新开始这个时候就需要版本回退的功能了。执行 git reset 命令用于回退版本可以指定退回某一次提交的版本git reset 是可以带参数的如果是 soft只回退版本库内容如果是 mixed回退版本库暂存区内容如果是 hard版本库、暂存区、工作区内容都会回退的如果只写 git reset默认是 --mixed上图我们验证了 git reset --hard commit id 确实会将工作区的内容回退到 commit id 对应命令的阶段并且只要知道了具体的 commit id我们也可以恢复刚才的回退也就是撤销回退操作但是如果我们中间经历了很多阶段呢回退前并没有 git log 打印出来那还能回退吗也是可以滴使用 git reflog 命令git 会记录下我们在命令行上的每一次操作包括回退操作使用 git reflog 就可以查看历史所有的操作可以看到回退操作是瞬间完成的那为啥回退操作这么快呢因为 git 只需要直接修改 HEAD 指针指向的 master 内容即可修改成上一次提交的 commit id就完成了回退撤销修改情况一对于工作区的代码还没有 add这种情况下就是我们在本地修改了文件代码发生了改动但是还没有进行任何 git 操作我们当然可以手动修改文件回到上个版本但非常不推荐这么做很容易出错推荐使用 git checkout -- filename就可以撤销修改情况二已经 add但没有 commit情况二现在是工作区和暂存区内容发生了变化而我们要撤销修改就是要让工作区和暂存区都恢复到修改前的状态从上图可以看出我们可以使用 --hard 选项当然也可以使用 --mixed 选项然后回到情况一再使用 git checkout -- filename 即可完成工作区修改的撤销情况三已经 add并且也 commit 了删除文件删除文件当然可以直接使用 rm 命令然后再 add commitgit 提供了一条命令git rm filename可以直接删除工作区文件同时自动 add 到暂存区然后我们再手动 commit 即可分支管理你现在要去参加一个比赛你和对手如果都是按照 练习基本功-学习降龙十八掌-参加比赛 的过程练习那么你最后不一定获胜而你是由分身功能的可以在练习好基本功后学习降龙十八掌的同时让分身学习辟邪剑法然后进行合体那么你获胜概率就很大了文章开始就提到了版本库中有1个HEAD指针指向了 master而 master 内部存储了最新一次的 commit id而 最新一次的 commit id 对应的对象中又存储了上一次的 commit id依次类推git 也是提供了分支的功能的目前我们看到的这条时间线上的提交就叫做 master 主分支而我们未来也可以在 master 主分支的某个时间节点上创建其他分支而后进行分支的合并创建、切换、合并、删除分支查看当前存在的分支git branch创建新的分支git branch 分支名上图中的 * 表示当前的工作分支master 分支是我们在初始化完本地仓库就自动创建的主分支默认的提交就是在主分支下的我们创建了 dev 分支之后依旧是在主分支下工作的HEAD 指针指向的依旧是 master 分支并且 refs/heads 下多了一个 dev 分支并且我们可以看到master 指向的 commit id 和 dev 指向的 commit id 是完全一样的因为 dev 分支是基于当前节点创建的所以 dev 分支是能看到 master 的最新一次提交的要想在 dev 分支上进行提交需要先切换到 dev 分支上切换的命令是 git checkout dev至此我们提交的所有操作都会在 dev 分支上master 分支是看不到的要想让 master 分支也看到 dev 分支上的提交需要将 dev 分支合并到 master 分支上注意要合并到哪个分支上必须先切换到该分支上上图中的 Fast-forward 是快进模式直接将 master 分支的指向改为 dev 最新一次的提交因此合并起来非常快当 dev 分支完成了它的任务最好就删掉该分支否则浪费资源删除的指令是 git branch -d 分支名注意删除 dev 分支要在 master 分支上删除不能在 dev 分支上删除 dev 分支补充分支创建和切换也是可以一步完成的使用git checkout -b 分支名合并冲突上面的演示中只有 dev 分支上在修改 readMe 文件而在真实开发过程中多个程序员可能在不同的分支上同时进行开发都在修改 readMe 文件比如 程序员A在 dev 分支上新增了一行 bbbbbbbbbbbbbbb 代码而程序员B 在 master 分支上新增了一行 cccccccccccccc 代码那么合并分支时就会产生冲突各自完成修改提交后合并时发生了冲突提示说让我们修复冲突然后提交结果我们进入 readMe 文件后发现内容是这样的解决冲突的方式就是手动修改 readMe 文件自己决定要怎么修改最终只要把 readMe 文件中的 、、 标记全部删除了即可可以只保留 add ccc... / add bbb也可以都保留也可以全部删掉重写此处我们把这两句话都保留下来然后再进行 add 和 commit 操作冲突问题就解决了git log --graph --abbrev-commit 指令可以以图的方式查看历史提交记录合并模式合并模式有两种Fast-forward 模式 和 非 Fast-forward 模式我们刚开始演示的只在 dev 分支上修改master 分支没有改动合并分支时采用的模式就是 Fast-forwardFast-forward 模式有啥问题呢我们下面再演示一遍 Fast-forward 模式采用 Fast-foward 模式我们是看不出来最新提交是在分支上正常的 commit 还是合并进来的但是采用 非 Fast-foward 模式使用 git log --graph --abbrev-commit 指令是可以明显看到提交的地方标注了 merge 的Git 支持我们强制禁用 Fast-foward 模式会在 merge 时生成一个新的 commit这样从分支历史上就可以看出分支信息合并时 git merge 携带 --no-ff 选项表示禁止使用 快进模式选项ff 就是 Fast-forward 的缩写同时强制禁用 Fast-foward 模式会在 merge 时生成一个新的 commit因此我们也需要 -m 指定 commit 提交时的信息非 Fast-forward 模式分支策略在实际开发中我们应该按照几个基本原则进行分支管理首先master分支应该是非常稳定的也就是仅用来发布新版本平时不能在上面干活那在哪干活呢干活都在dev分支上也就是说dev分支是不稳定的到某个时候比如1.0版本发布时再把dev分支合并到master上在master分支发布1.0版本你和你的小伙伴们每个人都在dev分支上干活每个人都有自己的分支时不时地往dev分支上合并就可以了所以团队合作的分支看起来就像这样bug 分支假如我们现在正在dev分支上进行开发开发到一半突然发现master分支上面有bug需要修复bug怎么做呢可以直接在 master 分支上修复吗肯定是不能的master 分支是用于发布稳定版本的万一在 master 分支上修复修出了一个更大的 bug 怎么办因为要修复 bug 我们必须新建一个分支专门用于修复 bug修复完成之后合并到 master 分支上如上图所示我们正在 dev 分支上进行开发现在发现 master 分支上出现了 bug于是切换回master 分支我们发现 在 master 分支上是可以看到 readMe 文件被修改了的而 实际还没有开发完呢现在需要的是修复bug因此我们不能让 新开发的未完成的代码影响我们因此我们需要在 dev 分支中将工作区的修改暂时储存起来使用 git stash 指令下面就可以安心修复bug了同时上文提到不能直接在 master 分支上修复 bug我们需要创建一个新的分支来修复bug修复完 bug 之后我们要将 fix_bug 分支上的提交 合并到 master 分支上那么目前 readMe 的 bug 就修复完成了现在 master 分支上看到的是一个正确的开发版本而 dev 分支还在开发中我们切回 dev 分支继续开发使用 git stash pop 指令恢复之前储存起来的内容然后我们需要将 dev 分支和 master 分支合并但直接切回 master 分支合并 dev 分支是有一定风险的因为在合并分支时可能会有冲突而代码冲突需要我们手动解决在master上解决。我们无法保证对于冲突问题可以正确地一次性解决难免掉因为在实际的项目中代码冲突不只一两行那么简单有可能几十上百行甚至更多解决的过程中手误出错导致错误的代码被合并到master上。此时的状态为建议的做法是先将 master 分支合并到 dev 分支上产生了冲突就在 dev 分支上解决冲突解决完冲突之后再合并回 master 分支此时的状态为下面我们就演示建议的做法强制删除分支我们程序员在开发的过程中产品经理可能突然叫停这个时候使用上文提到的 git branch -d dev 是删除不了 dev 分支的我们只需要将 -d 选项改为 -D 选项即可远程操作理解分布式版本控制系统上文我们已经感受到了控制的含义就是追踪管理文件修改而上文所有的操作都是在本地进行的都只有一台机器但实际开发不可能是很多人用一台机器做开发而是每个人都有一台机器每个人都有一台机器那么开发人员在自己机器上开发开发完后及时推送到对方主机上但可能会存在一些问题比如对方主机出问题了断电了等可能会影响开发于是搞了一台24h不停机的机器充当中央服务器这个服务器的作用仅仅是用来交换大家的修改没有它大家也一样干活只是交换修改不方便而已每个开发者自己电脑的仓库叫做本地仓库而这个服务器上建立的 git 仓库叫做远程仓库这就是分布式版本控制系统中的分布的含义创建远程仓库上述的中央服务器不需要我们自己搭建一个能运行 git 的机器已经有人开发好了运行 git 的网站github / gitee下面我们使用 gitee 演示在实际开发中一般一个项目对应一个仓库因此仓库名称必然和项目相关仓库是可以设置成员的有不同的角色、如管理员、观察者、报告者等创建好仓库之后默认就有以上内容RAEDME 就是一个说明文档用于说明仓库的相关情况.gitee 文件夹中有两个 md 文件分别是和 Issues 和 Pull_Rquest 相关的当别人发现了你仓库中的 bug就可以通过 Issues 模块进行提交上文提到了dev 分支直接合并到 master 分支上是比较危险的因此合并前必须先提交一个 Pull Request 内容说明 dev 分支的相关提交审核通过了才能进行合并克隆远程仓库方式一HTTPS注意执行克隆命令时一定不能在本地仓库下除了本地仓库外的任意一个路径都是可以的克隆远程仓库到本地后本地除了创建完远程仓库时就带有的三个部分之外也是有 .git 目录的内容和上文讲解本地仓库的内容也是完全一样的使用 git remote 命令可以查看远程仓库名字统一都叫做 origin-v可以查看更加详细的信息fetch 表示获取push 表示推送这就表明当前拉取下来的仓库是有拉取和推送权限的方式二SSHssh是采用公钥加密和公钥登录的方式进行的我们必须先配置公钥否则直接克隆是会报错的第一步创建SSHKey。在用户主目录下看看有没有.ssh目录如果有再看看这个目录下有没有 id_rsa 和 id_rsa.pub 这两个文件如果已经有了可直接跳到下一步。如果没有需要创建SSH Key:ssh-keygen -t rsa -C xxxxxxqq.com然后一路回车即可顺利的话可以在用户主目录里找到.ssh目录里面有 id_rsa 和 id_rsa.pub 两个文件这两个就是 SSHKey 的秘钥对id_rsa 是私钥不能泄露出去id_rsa.pub 是公钥可以放心地告诉任何人。然后将这段公钥配置到 gitee 的 SSH 公钥中向远程仓库推送先配置好用户名和密码必须和 gitee 上的用户名和密码完全一样之前在本地仓库对文件进行了修改使用 git add 和 git commit 之后 git status 查看仓库状态发现就是干净的但从远程仓库克隆到本地的要同步到远程仓库还需要使用git push 远程仓库名 本地分支名:远程分支名push 操作本质是分支到分支的而要从本地分支推送到远程分支前提是分支之间要提前建立好联系而 在我们克隆远程仓库的时候两个 master 分支就默认建立好了联系因此可以直接 push细节当push的本地分支和远程分支名一样时可以只写一个分支名即可拉取远程仓库当本地仓库领先于远程仓库时我们需要 push 本地仓库修改到远程仓库而当远程仓库领先于本地仓库时我们需要 pull 远程仓库修改到本地仓库为啥远程仓库会领先于本地仓库呢假如现在远程仓库只有一行 git 代码两个开发者都clone到本地了于是两个电脑上都有一行git开发者在本地添加了一行 world 代码然后 push 到了远程仓库于是远程仓库就比开发者1的本地仓库领先了因此开发者1需要 pull 操作细节当pull的本地分支和远程分支名一样时可以只写一个分支名即可注意git pull 其实做了两件事拉取合并git pull 拉取远程更新到“远程跟踪分支” 把远程跟踪分支合并进“当前本地分支”本地除了 master 分支外其实还有一个隐藏的远程跟踪分支origin/master当执行 git pull 时分为两个阶段第一个阶段从远程仓库下载最新提交更新本地的远程跟踪分支origin/master此时本地的 master 分支还没有变第二个阶段将 origin/master 合并进你当前所在的分支也就是本地 master如果没分叉就是快进如果分叉了就会产生合并提交忽略特殊文件在日常开发中我们有些文件不想或者不应该提交到远端比如保存了数据库密码的配置文件那么怎么让 Git 知道呢那直接 git add 要提交的文件名 不就行了但是在大型项目中我们一次可能要修改很多个文件难道把这几十个文件的文件名一个个打出来吗显然是不现实的我们还是希望使用 git add . 操作要想让 Git 不再追踪管理特定的文件可以在Git 的工作区的根目录下创建一个特殊的 .gitignore 文件把要忽略的文件名填进该文件Git 就会自动忽略这些文件了在我们创建 git 仓库的时候其实就可以勾选相关选项让 .gitignore 文件自动生成如果创建仓库时没有勾选该选项我们自己在工作区下新建一个 .gitignore 文件也是可以滴如上图所示我们在 .gitignore 中添加了 a.txt然后在工作区新建了 a.txt 文件git status发现只打印出来了让 add .gitignore 文件并没有提示 add a.txt 文件并且当我们 add commit 了发现工作区就干净了这就说明 a.txt 不再被 git 追踪管理执行 git push 后发现 gitee 上确实没有 a.txt 文件除了在 .gitignore 中直接写文件名指定具体的文件也可以指定一批文件比如想要忽略所有以 .so 结尾的文件就可以在 gitignore 中添加 *.so虽然 *.so 被添加到了 .gitignore 文件中但是我们确实要强制追踪某个.so文件也是可以的使用 git add -f filename.so-f 表示强制除了在 git add 时手动 -f 指定强制追踪被git忽略的某一类文件中的具体文件也可以在 .gitignore 文件中以 ! filename 的方式强制追踪如果我们在开发的过程中git push 之后发现有点文件修改了但没有被推送到远端此时我们想知道该文件被忽略的具体原因可以使用git check-ignore -v filename给命令配置别名在使用 git 命令的时候是可以给 git 命令起别名的使用git config [--global] alias.命令别名命令原名加了 --global 在所有的本地仓库都生效不加只在当前仓库生效并且起别名之后原命令依旧可以正常使用标签管理创建标签标签 tag可以简单的理解为是对某次commit的一个标识相当于起了一个别名。例如在项目发布某个版本的时候针对最后一次commit起一个v1.。这样的标签来标识里程碑的意义。这有什么用呢相较于难以记住的commitidtag很好的解决这个问题因为tag一定要给一个让人容易记住且有意义的名字。当我们需要回退到某个重要版本时直接使用标签就能很快定位到。如果直接 git tag 标签名那么默认是给最新一次提交创建标签的我们也可以给特定的一次 commit id 打标签git tag 标签名 commit id在打标签的同时我们也可以指定详细的描述信息使用 git tag -a 标签名 m 描述信息 commit id如何查看标签的具体描述信息呢使用 git show 标签名将标签推送到远端git push origin 标签名表示推送特定的标签到远端git push origin --tags表示将所有标签推送到到远端如何删除远程的标签呢非常不建议直接在 远端 gitee 中直接点击删除推荐在本地删除后推送删除修改到远端git push origin:标签名多人协作开发多人协作一目标远程 master 分支下 file.txt 文件新增代码 aaa、bbb实现由开发者1新增 aaa由开发者2新增 bbb条件在一个分支下协作完成master 分支必须保证稳定因此我们要新建一个分支完成开发我们直接在 gitee 远程仓库中新建一个 dev 分支用 Linux 服务器模拟开发者1用 windows 模拟开发者2由于要在一个分支下协作完成因此都是需要 dev 分支的开发者1执行 git pull 操作git pull 的第一步本质是 fetch会去拉取远程所有的分支由于刚刚在 gitee 上新建了一个 dev 分支因此执行完 git pull 后本地仓库会多一个 origin/dev 远程跟踪分支开发者2直接 clone 远程仓库就会自动在本地仓库创建 origin/master 和 origin/dev 分支此时远程仓库和本地仓库的状态如下图所示下面开发者1在自己的本地创建 dev 分支同时可以将 本地 dev 分支 和 远程 dev 分支关联起来往后执行 git push / git pull 操作时就可以简写了不用再详细指定要将本地哪个分支推送到远程哪个分支接下来开发者1在file.txt中新增了一行 aaa 代码然后 add commit push推送到远程dev分支下面切换到开发者2开发者2也要在自己的本地创建 dev 分支这次我们在创建 dev 分支时并没有直接和 远程 dev 分支建立连接那么就无法直接使用 git push / git pull 等简写的指令使用git branch --set-upstream-toorigin/dev dev可以建立连接下面我们就在 file.txt 中添加一行 bbb然后 add commit push为啥远程仓库拒绝了呢因为远程仓库的 file.txt 此时有一行 aaa而开发者2的 file.txt 最后一行是 bbb这就是上文遇到过的 合并冲突问题如何解决呢我们需要先执行 git pull将远程仓库之前更新的内容先拉取下来发现产生了冲突我们手动修改 file.txt 文件 解决冲突之后再三板斧提交即可现在远程的 dev 分支已经是上图所示了但我们最终的目标是在 master 分支下的 file.txt 文件新增 aaa、bbb因此还需要将远程的 dev 分支 合并到 master 分支上此时有两种做法方法一直接在 gitee 上创建 Pull Request提交 PR 申请单审核员审核通过就可以完成合并真实开发时推荐这种做法因为有审核员的审核安全性更高方法二先在本地进行合并将本地的 dev 分支合并到 本地的 master分支上然后再将 本地 master 分支内容 push 到远程仓库上这是整体思路但上文提到过最好先将 master 分支合并到 dev 分支上因为有可能有冲突有冲突尽量在 dev 分支上解决然后再将 dev 分支合并回 master 分支但将 master 分支合并回 dev 分支之前建议先在 master 分支上执行 git pull 操作因为有可能远程仓库的 master 分支已经更新了因此需要和远程仓库的 master 分支同步这是一个好习惯因此步骤如下1. master 分支上 git pull2. dev 分支上 git merge master3. master 分支上 git merge dev4. master 分支上 git push在开发者1 或 开发者2 的本地仓库上执行上述过程都是可以的我们以开发者1为例演示由于开发者1目前的 file.txt 文件只有aaa我们需要先 git pull同步一下 dev 分支1. master 分支上 git pull2. dev 分支上 git merge master3. master 分支上 git merge dev4. master 分支上 git push至此在同一个分支下进行开发的整个流程就完成了但是在同一个分支下开发经常需要解决冲突实际开发时可能一个功能点就需要拉出一个分支不同的开发者是在不同的分支下开发的多人协作二目标远程master分支下新增function1和function2文件实现由开发者1新增function1由开发者2新增function2条件在不同分支下协作完成开发者1在 feature-1分支下完成开发者2在feature-2分支下完成在多人协作一中我们演示的是直接在远程创建分支这也是推荐的做法这里我们再演示一下在本地创建分支然后推送到远程的过程直接 git push 是不行的因为远程分支是不存在的也就没有建立好连接也没法使用系统提示的 git push --set-upstream.. 命令因为远程分支还没有创建此时我们可以直接 git push origin feature-1远程如果不存在 feature-1分支会自动创建的下面是开发者2进行开发先 git pull 一下是一个好习惯然后创建 feature-2 分支新建 funciton2 文件提交到远端现在远程仓库中就有了 feature1 分支 和 feature2 分支目前没有发生任何冲突就是因为不同的开发者使用的是不同的分支开发时没有任何影响但假如此时开发者2生病了需要开发者1帮助自己完成剩下的开发工作于是把自己的开发分支名字告诉开发者1了此时开发者1就需要在 feature-2 上完成开发先将远端的仓库拉取到本地仓库于是本地仓库新增了 origin/feature2 分支然后在本地创建 feature2 分支完成开发推送到远端仓库接下来两个开发者就都开发完毕了最后还需要将 feature-1 分支 和 feature-2 分支合并到 master 分支合并方式还是之前提到的最好先将 master 分支合并到 其他分支有冲突在其他分支解决完冲突提交到远程分支最后再在远程master 分支上合并其他远程分支具体合并操作就是提交 Pull Request然后审查人员审查、测试人员测试完成后就合并成功了补充当我们在远程仓库中删除了分支之后发现在本地仓库 git branch -a 依旧可以查到远程跟踪分支相关状态此时可以执行 git remote prune origin git branch -a 就查看不到任何 origin/feature-1 等远程跟踪分支了企业级开发模型DevOps我们知道一个软件从零开始到最终交付大概包括以下几个阶段规划、编码、构建、测试、发布、部署和维护。最初程序比较简单工作量不大程序员一个人可以完成所有阶段的工作。但随着软件产业的日益发展壮大软件的规模也在逐渐变得庞大。软件的复杂度不断攀升一个人已经hold不住了就开始出现了精细化分工。如下图所示但在传统的IT组织下开发团队Dev和运维团队Ops之间诉求不同开发团队尤其是敏捷团队追求变化而运维团队追求稳定双方往往存在利益冲突DevOps 由此登上历史舞台DevOpsDevelopment和Operations的组合词是一种重视“软件开发人员Dev)”和“IT运维技术人员Ops”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在DevOps的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控由此可见DevOps的强大。系统开发环境1.开发环境开发环境是程序猿们专门用于日常开发的服务器。为了开发调试方便一般打开全部错误报告和测试工具是最基础的环境。2.测试环境一个程序在测试环境工作不正常那么肯定不能把它发布到生产机上。该环境是开发环境到生产环境的过渡环境。3.预发布环境该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境。其配置等基本和生产环境一致目的是能让我们发正式环境时更有把握所以预发布环境是你的产品质量最后一道防线因为下一步你的项目就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内为单独的一些机器。4.生产环境是指正式提供对外服务的线上环境例如我们目前在移动端或PC端能访问到的APP都是生产环境。这几个环境也可以说是系统开发的三个重要阶段开发-测试-上线。一张图总结对于规模稍微大点的公司来说可不止这么几个环境比如项目正式上线前还存在仿真/灰度环境再比如还存在多套测试环境以满足不同版本上线前测试的需要。一个项目的开始从设计开始而一个项目的成功则从测试开始。一套良好的测试体系可以将系统中绝大部分的致命Bug解决在系统上线之前。测试系统的完善和成熟也是衡量一个软件企业整体水平的重要指标之一测试往往被忽视因为它对可以的隐性、对软件开发企业不产生直接的效益但是它却是软件质量的最终保障乃至项目能否成功的重要因素Git 分支设计规范企业常用的一种 Git 分支设计规范Git Flow 模型分支名称适用环境master主分支生产环境release预发布分支预发布/测试环境develop开发分支开发环境feature需求开发分支本地hotfix紧急修复分支本地master 分支● master为主分支该分支为只读且唯一分支。用于部署到正式发布环境一般由合并release分支得到。● 主分支作为稳定的唯一代码库任何情况下不允许直接在master分支上修改代码。● 产品的功能全部实现后最终在master分支对外发布另外所有在master分支的推送应该打标签(tag做记录方便追溯。● master分支不可删除。release 分支● release为预发布分支基于本次上线所有的 feature 分支合并到 develop 分支之后基于develop分支创建。可以部署到测试或预发布集群。● 命名以release/开头建议的命名规则:release/version_publishtime。● release分支主要用于提交给测试人员进行功能测试。发布提测阶段会以release分支代码为基准进行提测。● 如果在release分支测试出问题需要回归验证develop分支看否存在此问题。● release分支属于临时分支产品上线后可选删除。develop 分支● develop为开发分支基于 master 分支创建的只读且唯一分支始终保持最新完成以及bug修复后的代码。可部署到开发环境对应集群。● 可根据需求大小程度确定是由 feature 分支合并还是直接在上面开发非常不建议。feature 分支● feature分支通常为新功能或新特性开发分支以 develop 分支为基础创建 feature 分支● 命名以feature/开头建议的命名规则feature/user_createtime_feature。● 新特性或新功能开发完成后开发人员需合到develop分支。● 一旦该需求发布上线便将其删除。hotfix 分支● hotfix 分支为线上 bug 修复分支或叫补丁分支主要用于对线上的版本进行bug修复。当线上出现紧急问题需要马上修复时需要基于 master 分支创建 hotfix 分支。● 命名以 hotfix/开头建议的命名规则hotfix/user_createtime_hotfix● 当问题修复完成后需要合并到 master 分支和 develop 分支并推送远程。一旦修复上线便将其删除。
