高端建站什么意思,河北中瑞建设集团有限公司网站,做一般的网站要多久,网站备案地1.Git的定位
在我们自己开发项目的过程中#xff0c;经常会遇到这样的情况#xff0c;为了防止代码丢失#xff0c;或者新变更的代码影响到原有的代码功能#xff0c;为了在失误后能恢复到原来的版本#xff0c;不得不复制出一个副本,比如#xff1a;“坦克大战1.0”“坦…
1.Git的定位
在我们自己开发项目的过程中经常会遇到这样的情况为了防止代码丢失或者新变更的代码影响到原有的代码功能为了在失误后能恢复到原来的版本不得不复制出一个副本,比如“坦克大战1.0”“坦克大战2.0”“坦克大战-确定版”“坦克大战-验收版”…
虽然每个版本我们都进行了备份但是每个版本都有自己的内容随着版本的不断增多各自版本修改的内容是什么我们就不清楚了。
因此就需要有一个版本控制器来记录每次的修改以及版本的迭代信息比如“坦克大战2.0”在“坦克大战1.0”上变更了Move类中第3行的代码那么git的作用就会记录此次的变更具体信息以此来方便我们回滚或者继续开发。 Git可以控制电脑上所有格式的文档不仅是文本文件源代码还可以是二进制文件比如图片、视频这类文件无法记录具体的变更只能记录空间占用的变化比如100kb–200kb 2.Git的安装(Linux-centos)
如果你的平台是centos安装git如下操作以我的centos7.6为例
首先你可以尝试输入git --version,如果提示类似于git version 1.8.3.1 说明你已经安装好了如果提示-bash: git: command not found,则执行以下命令进行安装sudo yum install git -y,完成安装后可以再通过命令git --version来检验自己是否安装完成。
3.Git基本操作
3.1创建git本地仓库
只有把文件放在git仓库中我们才能对文件的版本进行控制所以我们首先需要创建一个仓库出来。 先通过mkdir xxx命令创建一个目录切换到对应目录后输入命令git init,来创建一个git本地仓库可以通过tree .git/命令来查看Git仓库的具体细节。 注意不允许在.git下手动修改
3.2配置git
当安装git以后首先要做的就是配置你的用户名和Email地址命令如下
git config [--global] user.name Your Name
git config [--global] user.email emailexample.com
# 把 Your Name 改成你的昵称
# 把 emailexample.com 改成邮箱的格式只要格式正确即可。其中--global是一个可选项因为一台机器上可以创建多个Git仓库通过该选项就是给所有仓库都进行了配置全局配置。如果系统在不同仓库中使用不同的name或e-mail可以不要--global选项但要注意执行命令时必须要在想要操作的仓库中。 查看配置的命令为
git config -l删除对应配置的命令为
git config [--global] --unset user.name
git config [--global] --unset user.email3.3认识工作区、暂存区、版本库
我们前边说了只有把文件放在git仓库中才能对文件版本进行控制那么我们在git仓库中通过touch ReadMe来创建一个ReadMe文件以后可以对ReadMe文件进行操作吗 答案是不行通过以上命令列举出来的就划分为两个区域 .git在版本库仓库中 ReadMe在工作区中 只有将工作区的内容通过add、commit放入版本库中以后才能进行文件版本控制。
下图展示了工作区、暂存区和版本库之间的关系 第一步操作add就是将工作区中文件的修改内容添加进版本库中的暂存区中 修改内容包含增加、修改、删除 第二步操作commit就是把暂存区中的内容提交到版本库中的master分支下 走完这两步操作我们才可以真正意义上来管理ReadMe文件了 版本库中还存在一个对象区——objects工作区每次的修改内容都会写入到一个git对象中每次add,都会把这个git对象来交给对象区来维护那么也就相当于对象区维护了文件所有的版本。
暂存区存储一个个git对象的索引master分支下存储的也是一个个git对象的索引不存储具体的对象。 如果文件出现变更最下边应该还有分支index。
3.4提交文件修改
我们在.git目录下创建了ReadMe文件如果对ReadMe文件进行修改需要通过add、commit的方式来进行记录以下是具体的操作过程。
首先通过vim命令在ReadMe文件中添加一行内容hello git如下展示现在我们想要把ReadMe文件的变更记录进行保存就需要下一步的add操作。
git add [文件名1] [文件名2]添加一个或者多个文件到暂存区git add .添加当前目录下的所有文件到暂存区
完成add以后我们紧接着就需要commit操作来真正意义上把文件变更内容保存到本地仓库中。
git commit -m 此次变更的具体描述细节提交暂存区的全部内容到本地仓库git commit [文件名1] [文件名2] -m 此此变更的具体描述细节提交暂存区的指定内容保存到本地仓库中 注意git commit后边的-m选项要跟上本次提交的message由用户自己完成这部分内容不可省略并要好好描述用于记录此次变更的细节是给我们自己看的。 整体操作流程如下图所示
我们可以通过git log命令来查看我们的提交记录该命令可以帮我们打印出来时间由近到远的所有记录下图中都标红部分就是该次commit的commit ID由这个唯一的ID就可以定位到这次提交。 如果觉得输出的信息太多可以加上 --prettyoneline参数
3.5查看.git文件
在我们完成上边的提交操作以后再通过tree .git命令来查看文件目录如下图所示多了index目录 我们可以通过cat命令来查看不同的目录下的文件.
首先我们来看HEAD指针通过cat .git/HEAD命令面板上打印出ref: refs/heads/master说明HEAD指针指向master分支再通过命令cat .git/refs/heads/master命令该命令打印出最新一次提交的commitID面板上打印出一行commitID再通过命令git cat-file -p commitID,面板打印如下图结果打印出了这次commitID提交对应的提交信息。
我们可以发现打印结果中的tree后也跟着一个commitID打印这个commitID,得到提交文件的commitID,再打印这个commitID就可以得到文件里具体修改的内容。 总结 HEAD指针指向.git/refs/heads/mastermaster分支打印该分支可以得到最新一次提交的commitID,打印这个commitID可以得到该次commit的描述详情打印结果的tree后还跟着一个commitID打印这个ID可以得到具体提交的文件的commitID再打印这个ID就可以得到文件具体修改的内容。
3.6场景学习 如上图所示提交后打印1 file changed, 0 insertions(), 0 deletions(-),意思是只有一个文件改变了这是因为我们只将file1提交到暂存区了commit不会把暂存区以外的东西提交想要提交file2就需要再重新add、commit。
3.7修改文件
Git跟踪并管理的是修改而非文件。
新增、删除或更改都属于修改甚至创建一个新文件也算一个修改。
让我们通过vim命令将ReadMe文件进行一次修改里边增加一行代码hello world。 接着可以通过git status来查看当前仓库的状态 上面的结果告诉我们ReadMe文件被修改过了但还没有完成添加与提交。 目前我们只知道文件被修改了如果想要知道具体哪些地方被修改了可以通过git diff命令
git diff [file]命令用来显示暂存区和工作区文件的差异显示的格式是Unix通用的diff格式。
我们add文件以后再通过status命令来查看状态显示有待提交。 commit文件并带上描述再通过status命令来查看状态
3.8版本回退
Git能够管理文件的历史版本如果有一天你发现之前的工作做的出现了很大的问题需要在某个特定的历史版本重新开始这个时候就需要版本回退了。 执行git reset命令用于回退版本可以指定退回某一次提交的版本回退的本质是将版本库中的内容进行回退工作区或暂存区是否回退由命令参数决定 git reset命令语法格式为git reset [--soft | --mixed | --hard [HEAD]]
--soft参数对于工作区和暂存区的内容都不变只是将版本库回退到某个指定版本。--mixed为默认选项使用时可以不带该参数该参数将暂存区的内容退回为指定提交版本内容工作区文件保持不变。--hard参数将暂存区和工作区都退回到指定版本。该参数需要慎用因为如果工作区有未提交的代码时使用该命令工作区会回滚你没有提交的代码就再也找不回了。
HEAD说明
可直接写成commit ID表示指定退回的版本HEAD 表示当前版本HEAD^ 上一个版本HEAD^^ 上上一个版本以此类推
可以使用~数字表示
HEAD~0 表示当前版本HEAD~1 上一个版本HEAD~2 上上一个版本
以下是实际操作场景 通过git reset --hard commit ID回退到指定版本ReadMe文件里边的内容也发生了回滚。 如果想要再返回原来的状态就再找到指定的commit ID进行回滚即可。 只要commit ID我们能找到我们就可以回退到指定的版本可以通过git reflog命令来查看所有的commit ID记录此处我们发现gommit ID很短但是通过这个短的ID也能够进行正常回退
我们进行版本回退的速度很快这是因为我们的每个版本都有一个commit IDgit只需要更改指针的指向HEAD指针指向mastermaster存储最新一次commit ID就可以进行版本的回退了。
总结
3.9撤销修改
如果我们在工作区写了很长时间代码但是后来写的代码质量都很差想要撤销掉我们的修改恢复到上一个版本分以下几种情况来讨论。
情况一工作区的代码没有add情况二已经add但没有commit情况三已经add并且也commit了
我们还以ReadMe文件作为举例我们在工作区给ReadMe文件新增了一行代码xxx code。 对应情况一我们只需要命令git checkout --[filename]即可撤销 对应情况二我们可以先通过命令git reset HEAD ReadMe默认参数为--mixed将暂存区的内容回退到当前版本区的内容都为空然后再通过git checkout --[filename]命令来撤销工作区修改的内容。 对于情况三我们可以通过命令git reset --hard HEAD^将三个区域都回退到上一版本的内容【注意该情况为commit之后,push之前】 总结
3.10删除文件
在git中如果我们想要做一个删除操作只通过在工作区的rm命令是无法完成删除的还需要add和commit操作才能完成暂存区和工作区的删除
所以我们一般可以直接通过命令git rm可以完成工作区和暂存区的删除然后再通过git commit -m ,来完成版本库中的删除。
4.Git分支管理
4.1理解分支
分支就是一个复制版本的概念它与主版本互不干扰可以在分支上进行操作防止在主干上直接操作造成失误在分支上完成开发操作以后可以再合并分支到主干上。
在版本回退中每次提交Git都会把它们串成一条时间线这条时间线就可以理解为一个分支如果只有这一条时间线那么这个分支就叫做主分支即master分支。
HEAD指针不仅可以指向master还可以指向其他分支被指向的分支就是当前正在工作的分支。
4.2创建、切换、合并分支
Git支持我们查看或创建其他分支在这里我们创建第一个自己的分支dev对应的命令为 *表示当前HEAD指向的分支是master分支并且目前dev和master指向同一个修改。 如果我们想要在dev分支下进行开发工作就需要将分支切换到dev上来可以通过git checkout dev命令来完成切换如下演示 接下来我们在dev分支下修改ReadMe文件新增一行内容并进行一次提交操作 在dev分支上commit以后当前仓库的状态如下
如果我们想要在master主分支上看到新的提交就需要将dev分支合并到master分支示例如下 当前仓库的状态如下 Fast-forward代表“快进模式”也就是直接把master指向dev的当前提交所以合并速度非常快。 命令: git branch查看本地所有分支 git branch -r查看远程所有分支 git branch -a查看所有分支 4.3删除分支
合并完成以后dev分支对我们来说就没用了那么dev分支就可以被删除掉注意如果当前正处于某分支下就不能删除当前分支需要先切换到master分支下再来删除dev分支。
git branch -d 分支名 此时的仓库状态如下所示 因为创建、合并和删除分支非常快所以更建议使用分支完成某个任务合并后再删掉分支这和直接在master分支上工作效果是一样的但过程更安全。
如果我们在分支上开发了新功能但是产品不要这个新功能了这时候我们可以通过git branch -D 分支名来强制删除该分支。
4.4合并冲突
在我们合并分支的时候并不是想合并就能合并成功的有时候可能会遇到代码冲突的问题。 比如我们在主分支上的ReadMe文件内容为aaa on dev1我们创建并切换到新的分支上dev1将aaa on dev1变更为bbb on dev1,再换回到主分支上并将aaa on dev1改为ccc on dev1这时候想要将dev1分支合并到master主分支上就会产生合并冲突。
为了演示这个问题我们需要创建一个新的分支并切换到该分支上可以使用git checkout -b dev1命令一步完成创建分支并切换到该分支的操作。 接下来在dev1分支上将aaa on dev1变更为bbb on dev1,并add commit。 然后再切回到主分支上将aaa on dev1变更为bbb on dev1,并add commit。 此时仓库中的状态就如下图所示 如果想要将dev1分支合并到master分支上就会有以下合并冲突的提示 修改冲突内容并提交 此时合并冲突就修改了仓库的状态如下图所示我们也可以通过命令git log --graph --prettyoneline --abbrev-commit来查看仓库的状态
4.5 分支管理策略
通常合并分支时如果可能Git会采用Fast forward模式。那么形成的合并结果将如下图所示 在这种Fast forward模式下删除分支以后查看历史分支时会丢掉分支信息看不出来最新提交到底是merge进来的还是正常提交的。 但在合并冲突部分我们也看到通过解决冲突问题会再进行一次新的提交得到的最终状态为 那么这就不是Fast forward模式了这样的好处是从分支历史上就可以看出分支信息。比如我们现在已经删除了在合并冲突部分创建的dev分支但依旧能看到master其实是由其他分支合并得到的。
Git支持我们强制禁用Fast forward模式那么就会在merge时生成一个新的commit这样从分支历史上就可以看出分支信息。
下面是实战示例 首先创建新的分支dev并切换至新的分支 修改ReadMe文件并提交一个新的commit 切回master分支开始合并 --no-ff参数表示禁用Fast forward模式禁用Fast forward模式后合并会创建一个新的commit所以加上-m参数把描述写进去。 合并后查看分支历史 可以看到不使用Fast forward模式merge后就像下图状态
所以在合并分支时加上--no-ff参数就可以用普通模式合并合并后的历史有分支能看出来曾今做过合并而fast forwad合并就看不出来曾经做过合并。
分支策略
在实际开发中我们应该遵循几个基本原则来进行分支管理 master分支是非常稳定的也就是仅用来发布新版本平时不能在上面干活 而干活平时应该在dev分支上每个人都在dev分支上干活且每个人都有自己的分支时不时往dev分支上合并就可以了然后再把dev分支合并到master分支上 所以团队合作的分支看起来就像下图
4.6 bug分支
假如我们现在正在dev分支上进行开发开发到一半突然发现master分支上面有bug需要解决。在Git中每个bug都可以通过一个新的临时分支来修复修复后合并分支然后将临时分支删除。 如果我们现在在dev分支上开发了一部分还无法提交这时候需要使用git stash命令来将当前的工作区信息进行储藏只存储被git追踪的文件被储藏的内容可以在将来某个时刻恢复出来。 我们用git status命令查看工作区是干净的因此可以放心地创建分支来修复bug。 储藏dev分支的工作区以后由于我们要基于master分支修复bug所以需要切回master分支再新建临时分支来修复bug,示例如下 修复完成后切换到master分支并完成合并最后删除fix_bug分支。 这时我们已经完成了bug的修复要继续回到dev分支上进行开发切回dev分支使用git stash list可以看到我们存储的工作现场版本使用git stash pop命令恢复现场 然后我们可以继续开发开发完成后提交 此时git仓库的状态如下所示 master分支目前最新的提交是要领先于dev基于master分支时提交的我们最终想要让master分支合并dev分支但如果切回master分支直接合并有可能存在dev和fix_bug分支上的冲突而代码冲突需要我们手动解决(在master上解决)直接在master分支上变更是有一定风险的这时更好的做法时切回dev分支将master分支合并到dev分支上并在dev分支上解决代码冲突解决冲突以后再将dev分支合并到master分支上此时的状态为 实操如下
5.远程操作
5.1 分布式版本控制系统
我们之前所介绍到的所有内容(工作区、暂存区、版本库等等)都是在本地也就是在你的笔记本或者计算机上。而我们的Git其实是分布式版本控制系统。
可以简单理解为我们每个人的电脑上都是一个完整的版本库大家可以在多台电脑上进行修改然后可以把自己的修改推送到中央服务器上其他同学可以通过拉取中央服务器上的代码来获取到最新的修改中央服务器的作用就是方便“交换”大家的修改。
5.2 远程仓库
Git是分布式版本控制系统同一个Git仓库可以分布到不同的机器上有一台电脑充当服务器的角色每天24h开机其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上并且各自把各自的提交推送到服务器仓库里也从服务器仓库中拉取别人的提交。
网站GitHub或者gitee都是提供Git仓库托管服务的下面我们来使用一下gitee码云远程仓库。
新建远程仓库 创建成功 并且在刚创建好的仓库中有且只有一个默认分支master
克隆远程仓库
克隆/下载远端仓库到本地需要使用git clone命令后面跟上我们的远端仓库链接 SSH协议和HTTPS协议是Git最常使用的两种传输协议。SSH协议使用了公钥加密和公钥登录机制体现了其实用性和安全性使用此协议需要将我们的公钥放上服务器由Git服务器进行管理。使用HTTPS方式时没有要求可以直接克隆下来。
使用HTTPS方式 使用SSH方式 SSH方式直接使用git clone命令是不能够将远程仓库克隆到本地的需要我们将公钥添加到远端仓库中才能够将仓库克隆下来。
第一步创建SSH Key在用户主目录下看看有没有.ssh目录如果有再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件如果已经有了可以直接跳到下一步。如果没有需要创建SSH Key 注意此处要输入自己的邮箱然后一路回车使用默认值即可。 第二步添加自己的公钥到远端仓库
再次打开ssh目录查看公钥id_rsa.pub将公钥复制粘贴到gitee上。 然后再输入git clone命令就可以完成克隆操作了。
完成克隆以后仓库的状态如下图所示
向远程仓库推送
在向远程仓库推送时需要注意设置的name和Email需要和gitee上配置的用户名和邮箱保持一致否则会报错。
配置好以后我们就可以向远程仓库推送了 推送的命令格式如下
git push 远程主机名 本地分支名 远程分支名# 如果本地分支名与远程分支名相同则可以省略冒号后的内容
git push 远程主机名 本地分支名具体的推送操作如下
整个推送的流程如下图所示 拉取远程仓库
如果其他同学向远端仓库push内容那么远端仓库的代码是新于你本地的代码的所以就需要通过命令来拉取远程仓库上最新的代码代码格式如下
git pull 远程主机名 远程分支名:本地分支名# 如果远程分支是与当前分支合并则冒号后面的部分可以省略
git pull 远程主机名 远程分支名该命令会完成拉取并合并分支两步操作。
命令git pull后面不加其他内容可以完成两种类型的拉取一种是拉取对应分支下的内容【这种需要通过本地分支与远程分支建立连接】另一种是拉取仓库的内容【即拉取远程最新的分支情况】 通过以下两种方式可以将本地分支与远程分支建立连接 git checkout -b [branch-name] [origin/branch-name]【该方法在新建分支时建立连接】 git branch --set-upstream-toorigin/branch-name branch-name【该方法在建立好分支以后建立连接】 5.3 配置git
忽略特殊文件
在日常开发中我们有些文件不想或者不应该提交到远端比如说保存了数据库密码的配置文件就需要在Git工作区的根目录下创建一个特殊的.gitignore文件然后把要忽略的文件名填进去Git就会自动忽略这些文件了。
.gitignore文件可以在gitee创建仓库时默认勾选生成也可以由我们自己来创建效果相同 假如我们想要忽略以.so和.ini结尾的所有文件.gitignore的内容如下所示
# 忽略以.so和.ini结尾的所有文件*.so
*.ini如果某个以.so或者.ini结尾的文件又想要提交可以在.gitignore文件中添加文件名比如想要提交a.so那么.gitignore的内容如下所示
# 忽略以.so和.ini结尾的所有文件*.so
*.ini!a.so # 排除a.so文件如果.gitignore文件里维护的代码太多了而此时我们又新建了个文件比如文件d.so没有被git追踪管理我们可以通过命令git check-ignore -v d.so 来查看被忽略的原因。
最后配置好.gitignore文件以后记得把.gitignore文件也提交到远端就完成了。
给命令配置别名
在我们使用Git期间可以通过配置来将命令简化。
比如我们想要将git status命令简化为git st对应的命令为--global是全局参数 git config --global alias.st status
将git log --prettyoneline --abbrev-commit命令简化为git lpa对应的命令为 git config --global alias.lpa log --prettyoneline --abbrev-commit
使用效果如下所示
6.标签管理
标签tag可以简单的理解为是对某次commit的一个标识相当于起了一个别名。例如在项目发布某个版本的时候针对最后一次commit起一个v1.0这样的标签来标识里程碑的意义相较于难以记住的commit IDtag可以很好的解决这个问题因为其便于记忆且有意义所以当我们需要回退到某个重要版本是直接使用标签就能很快定位到。
6.1 操作标签
创建标签
git tag v1.0给最新的一次commit打标 git tag -a[name] -m xxx [commit_id] Git提供的带有说明的标签用-a指定标签名-m指定说明文字 如果想要给指定的commit打标签找到历史提交的commit id然后打标即可如下命令 git tag v0.9 a009936
git tag查看所有标签按时间排序 git show [tagname]查看标签信息 git tag -d [tagname]删除标签
6.2 推送标签
因为创建的标签都只保存在本地不会自动推送到远程如果想要推送某个标签到远程使用命令git push origin tagname
如果你本地有很多的标签也可以通过命令git push origin --tags将所有标签一次性的全部推送到远端。
如果标签已经推送到远程要删除远程标签就需要两步操作第一步先从本地删除第二步再从远程删除。 git tag -d [tagname] #删除本地标签 git push origin :[tagname] #删除远程标签
7.多人协作
7.1 场景一多人同一分支
现在我们有这样一个场景 目标在远程的master分支下的file.txt文件新增代码aaa、bbb 实现由开发者1新增aaa由开发者2新增bbb 条件:在一个分支下协作完成 为了模拟实现以上场景我们分别在linux和Windows上针对同项目进行协作开发。
目前我们的远程仓库中只有一个master主分支但在实际的项目开发中在任何情况下其实都是不允许直接在master分支上修改代码的这是为了保证主分支的稳定。所以在开发新功能是常常会新建其他分支供开发时进行迭代使用。
那么首先我们在gitee上新建dev远程分支供我们使用 然后分别在linux和windows上更新最新的分支及代码情况
将仓库克隆到本地以后分支情况如下图因为我们需要在本地分支上做修改所以需要在本地新建分支dev并与远程分支dev建立连接通过命令git checkout -b dev origin/dev来实现。 还可以通过命令git branch --set-upstream-toorigin/远程分支名 本地分支名来将本地分支与远程分支建立连接。 我们还可以通过git branch -vv命令来查看分支的连接情况通过将本地分支与远程分支建立连接在使用git push或者git pull命令时就不用在指定分支了直接就是两个连接分支之间的推送和拉取操作。 接下来我们在linux系统下完成新增aaa的操作并将新增操作推送到远程的仓库中。
然后再windows系统下完成新增bbb的操作 并将新增bbb的操作变更也推送到远程仓库中 但如果当我们输入git push命令推送时由于远程仓库中file.txt文件新增了aaa代码windows中的仓库并没有感知所以如果直接推送会产生代码冲突需要先通过git pull命令将远程仓库中的代码拉到本地解决冲突以后再进行推送
完成远程分支的推送后我们还需要将远程分支dev合并进远程分支master才算完成了整个链路。 一般在远程仓库中进行合并操作时需要在远程仓库中提交Pull Requests合并请求工单将远程的dev分支合并到master分支上工单会被审核员或者管理员审批审批通过才能完成合并这也是在公司经常用的合并提交代码的方式。 总结一下在同一分支下进行多人协作的工作模式通常是这样的
首先可以试图用git push 推送自己的修改如果推送失败则因为远程分支比你的本地更新需要先用git pull试图合并如果合并有冲突则解决冲突并在本地提交没有冲突或者解决掉冲突以后再用git push推送就能成功功能开发完毕将远程分支merge进master然后将临时分支删除
7.2 场景二多人不同分支
现有场景2 目标远程master分支下新增function1和function2文件 实现由开发者1新增function1由开发者2新增function2 条件在不同分支下协作完成各自让某一个功能私有某一个分支 基于以上场景的分支创建我们有两种方式来实现 1、在远程仓库基于master创建分支然后本地拉取该分支进行功能开发 这种方式比较建议因为基于远程的master分支创建新的分支得到的是最新的代码 2、基于本地分支创建新分支完成代码开发后进行git push操作 这种方式需要注意的是本地的master分支可能不是最新的代码需要先通过git pull操作拉取到最新的master分支然后再基于该分支创建新的分支进行开发。 下边我们用第二种方式来做演示
首先在linux系统下的仓库完成开发者1的工作 然后在windows系统下完成开发者2的工作 至此我们发现远程仓库的分支情况符合我们的预期新建了两个分支并新增了对应的功能 接下来就可以通过提交PR,来完成分支合并的请求了。
如果将临时分支合并到master分支上时产生了冲突就需要先将master分支合并到临时分支上在临时分支上解决了冲突再将临时分支合并到master分支上该场景就如下图所示【先完成了分支feature-2的合并然后在合并feature-1分支时产生了冲突】 本地解决完冲突并push以后可以接着提交PR来完成合并分支的请求及操作了。
7.3 处理远程已经删除的分支
如果我们已经在远程仓库中删除了某些分支但是我们通过git branch -a命令还是会看到这些被删除的分支 如果想处理掉这些在远程已经删除的分支可以通过命令git remote show origin来查看这些分支的详情并会提示你用git remote prune origin来删除这些在远程仓库中已经被删除的分支。
8.企业开发运用
当今企业经常使用的软件迭代开发、维护的工具是DevOps在Devops的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控由此可见DevOps的强大。
8.1系统开发环境
在系统开发中有以下几个环境需要我们必须了解 1、开发环境开发环境是开发者们专门用于日常开发的服务器。 2、测试环境一个程序在测试环境中是不稳定的该环境是开发环境到生产环境的过渡环境。 3、预发布环境该环境是为避免因测试环境和线上环境的差异带来的缺陷漏测而设立的一套环境。其配置等基本和生产环境一致目的是能让我们发正式环境时更有把握所以预发布环境是产品质量的最后一道防线因为下一步项目就要上线了要注意预发布环境服务器不在线上集成服务器范围之内为单独的一些机器。 4、生产环境是指正式提供对外服务的线上环境例如我们目前在移动端或PC端能访问到的APP都是生产环境。
这几个环境也可以说是系统开发的三个重要阶段开发–》测试–》上线。 8.2 Git分支管理规范
对于开发人员来说一般会针对不同的环境来设计不同的分支例如
分支名称适用环境master主分支生产环境release预发布分支预发布/测试环境develop开发分支开发环境feature需求开发分支本地hotfix紧急修复分支本地
master分支
master为主分支该分支为只读且唯一分支。用于部署到正式发布环境一般由合并release分支得到。主分支作为稳定的唯一代码库任何情况下不允许直接在master分支上修改代码。产品的功能全部实现以后最终在master分支对外发布另外所有在master分支的推送应该打标签(tag)做记录方便追溯。master分支不可删除
release分支
release为预发布分支基于本次上线所有的feature分支合并到develop分支以后基于develop分支创建。可以部署到测试或预发布集群。命名以release/开头建议命名的规则release/version_publishtimerelease分支主要用于提交给测试人员进行功能测试。发布提测阶段会以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分支并推送远程。一旦修复上线便将其删除。
用一张图来总结
8.3 DevOps开发实战
【Gitee企业版】
准备工作
创建项目 创建仓库 添加成员
实战演练
现有一个订单管理的新需求需要开发首先可以基于develop分支创建一个feature/ldj_order_20231024分支。 1.需求在feature/ldj_order_20231024分支开发完毕这时研发人员可以将代码合并到develop分支将其部署在开发环境的服务器中方便开发人员进行测试和调试。 a.开发者在feature分支下发起请求评审(PR) b.审核员审查代码 c.审查通过合并分支 d.合并通过查看结果
2.在develop下开发人员自测通过后先确定下develop不存在未测试完毕的需求然后研发人员可基于develop分支创建一个release/xxx分支出来可交由测试人员进行测试。
3.测试人员测试release通过后包含测试环境和预发布环境的测试就可将代码合并入master。 4.测试人员在master正式环境测试通过后便可删除feature/xxx分支。
修复bug
修复测试环境bug 在develop测试出现了Bug建议大家直接在feature分支上进行修复。修复后的提测上线流程与新需求加入的流程一致。
修改预发布环境Bug 在release测试出现了Bug首先要回归下develop分支是否同样存在这个问题。如果存在修复流程与修复测试环境Bug流程一致。 如果不存在这种可能性较少大部分时数据兼容问题环境配置问题等。
修改正式环境Bug 在master测试出现了Bug首先要回归下release和develop分支是否同样存在这个问题。 如果存在修复流程与修复测试环境Bug流程一致。 如果不存在这种可能性也比较少大部分是数据兼容问题环境配置问题等。
紧急修复正式环境Bug 需求在测试环节未测试出Bug上线运行一段时候出现了Bug需要紧急修复的。 可基于master创建hotfix/xxx分支修复完毕后发布到master验证验证完毕后将master代码合并到develop分支同时删除hotfix/xxx分支。
