2019做网站赚钱么,什么网站流量大,儿童网站开发方面外文文献,用织梦后台修改网站logoAnd if forever lasts till now Alright 为什么要有git#xff1f; 想象一下#xff0c;现如今你的老师同时叫你和张三#xff0c;各自写一份下半年的学习计划交给他。 可是你的老师是一个极其较真的人#xff0c;发现你俩写的学习计划太水And if forever lasts till now Alright 为什么要有git 想象一下现如今你的老师同时叫你和张三各自写一份下半年的学习计划交给他。 可是你的老师是一个极其较真的人发现你俩写的学习计划太水了根本没上心因此将你俩的计划又打发回去给你们了叫你们再重写一份。 老师一看你这俩人第二次写的比第一次还烂赶快拿回去重写。于是乎你俩的计划又被打了回去。 此时你暗自窃喜因为你做了第一次更改的备份那么直接把plan1发给老师任务即可完成了。可是到了张三这里就让他叫苦连连经过多次在原计划上的修改早就忘了第一次的计划是什么版本了。 所以上述的你其实就在做版本管理。为了方便”版本回溯我们只得不停地在做复制拷贝产出的⽂件就越来越多可是⽂件多不是问题问题是: “随着版本数量的不断增多你还记得这些版本各⾃都是修改了什么吗?” 因此为了能够更⽅便我们管理这些不同版本的⽂件便有了 版本控制器。所谓的版本控制器就是能让你了解到⼀个⽂件的历史以及它的发展过程的系统。 ⽬前最主流的版本控制器就是Git。Git可以控制电脑上所有格式的⽂件例如doc、excel、dwg、dgn、rvt等等。对于我们开发⼈员来说Git最重要的就是可以帮助我们管理软件开发项⽬中的源代码⽂件
——前言 一、Git安装
(1) Windows 我们可以打开: git官网。 点击Downloads,选择自己机器适配的环境。 下载完成后根据默认指示安装即可。 (2) Centos 7.x环境下 # 安装git
sudo yum install -y git git下载完成之后通过: git --version查看。 二、git的基本操作
(1) 初始化仓库 创建本地仓库:
# 创建一个目录
mkdir gitcode
# 创建仓库
git init此时我们就会发现在该路径下多了一个隐藏文件.git,.git目录是Git用来跟踪管理仓库的因此万不可手动修改里面的内容导致Git仓库无法管理。当然.git文件里都有些什么呢在之后会细讲。 配置Git身份: 当安装Git后⾸先要做的事情是设置你的⽤⼾名称和e-mail地址这是⾮常重要的。
配指命令:
# [--global]:意为全局配置
git config [--global] user.name Your Name
git config [--global] user.email emailexample.com
# 把 Your Name 改成你的昵称
# 把 emailexample.com 改成邮箱的格式只要格式正确即可 因为在一台机器上也许存在多个Git本地仓库其中 --global 是⼀个可选项如果使⽤了该选项表⽰这台机器上所有的Git仓库都会使⽤这个配置。如果你希望在不同仓库中使⽤不同的 name 或 e-mail 可以不要 --global 选项但要注意的是执⾏命令时必须要在仓库⾥。
查看配置信息: 上述演示的是配置到本地仓库中的例子。我们可以通过以下命令查看当前Git配置的用户信息。
命令作用 git config --system --list 查看系统configgit config --global--list当前全局configgit confit --local --list当前仓库config 删除用户:
# 删除[全局]本地用户配置
git config [--global] --unset user.name
git config [--global] --unset user.email global配置: 我们全局配置的信息会存放在/home/xxx/.gitconfig里 (2) 认识⼯作区、暂存区、版本库 当我们在使用 git init 后我们会发现当前的目录会新增一个隐藏文件.git,这个隐藏文件是什么呢 ● 工作区: 是在电脑上你要写代码或⽂件的⽬录。 ● 暂存区(叫stage、index)。⼀般存放在 .git ⽬录下的index⽂件.git/index中我们把暂存区有时也叫作索引(index)。 ● 版本库⼜名仓库(repository) 。⼯作区有⼀个隐藏⽬录 .git 它不算⼯作区⽽是Git的版本库。这个版本库⾥⾯的所有⽂件都可以被Git管理起来每个⽂件的修改、删除Git都能跟踪以便任何时刻都可以追踪历史或者在将来某个时刻可以“还原”。 下面一个图展示了这三个区域的关系: • 图中左侧为⼯作区也就是当前目录。右侧为版本库在.git文件下。Git的版本库⾥存了很多东西其中最重要的就是暂存区(因为这是一个新的Git仓库没有任何历史信息所以不存在暂存区)。 如何理解三个区的关系(为什么需要git三板斧) 在创建Git仓库时Git会为我们默认创建一个唯一的master分支以及指向master的一个指针HEAD。(关于什么是分支之后会细讲)。 当对工作区修改的文件(增删文件修改文件内容……)执行 “git add”命令时暂存区的目录的文件索引会被更新。 当执⾏提交命令“git commit”时master分⽀会做相应的更新可以简单理解为暂存区的⽬录 树才会被真正写到版本库中。 由上述例子我们得知:新建或粘贴进⽬录的⽂件并不能称之为向仓库中新增⽂件⽽只是在⼯作区新增了⽂件。必须要通过使⽤git add和git commit命令才能将⽂件添加到仓库中进⾏管理 (3) 使用Git添加文件
添加文件场景一: 在之前我们已经添加了Readme文件了现在我们再继续在工作区创建几个文件一并进行添加到暂存区。
# 添加⼀个或多个⽂件到暂存区
git add [file1] [file2] ...
# 添加指定目录到暂存区
git add [dir]
# 添加当前⽬录下的所有⽂件改动到暂存区
git add . 再使用git commit 命令将暂存区内容添加到本地仓库中:
# 提交暂存区全部内容到本地仓库中
git commit -m message
# 提交暂存区的指定⽂件到仓库区
git commit [file1] [file2] ... -m message
注: git commit 携带-m,类似于一种备注。这一步是由用户自己完成这部分内容绝对不能省略,并要好好描述是⽤来记录你的提交细节是给我们⼈看的。 我们可以看到自己所添加的文件通通被add到暂存区中然后⼀次性commit暂存区的所有修改。 Git管理日志查看: 截止目前位置我们成功将本地代码提交到了本地仓库并且能被Git管理起来。也许你会说诶你说的都不对啊我咋没看到提交的地方在哪里呢?。我们可以使用日志命令查看历史的提交记录:
# 显⽰从最近到最远的提交⽇志并且可以看到我们commit时的⽇志消息
git log
# 美化版git log
git log --prettyoneline 需要说明的是4c35dfd627241ff...、“a1806786780b1e0...”这样的很长的字符串是每次我们进行“git commit”提交到本地仓库后生成的commit id(版本号)。(当然这是它们内部计算生成出来的数字自然不是本篇的探讨范畴)。 再谈.git文件:
① HEAD指针到底指向的是什么 我们完成了上述添加文件的操作后再次来查看一下.git文件: 我们再通过git log日志查看: 我们发现refs/head/master里保存的就是最新进行 git commit操作的 commit id。 ② objects对象是什么 objects为Git的对象库⾥⾯包含了创建的各种版本库对象及内容。当执⾏git add命令时暂存区的⽬录树被更新同时⼯作区修改或新增的⽂件内容被写⼊到对象库中的⼀个新的对象中。我们通过tree命令查看 objects时它将commit id分成了两个部分其前2位是⽂件夹名称后38位是⽂件名称。 如果我们直接使用cat 这个commit id去查看里面的内容是不行的因为该类⽂件是经过算法加密过的。
# 查看objects的内容
git cat-file -p(pretty) commit_id 其中还有一行 tree 15a37e9ef171cca4a5d985fccd1fcf9414b2c7cf,我们使用同样的方法打开并且继续分别打开ReadM和file1。 这是我们对ReadMe做的修改并且被Git记录了下来。 小结一下: 在本地的git仓库中有⼏个⽂件或者⽬录很特殊: • index:暂存区,git add后会更新该内容。 • HEAD:默认指向master分⽀的⼀个指针。 • refs/heads/master:⽂件⾥保存当前 master 分⽀的最新 commit id 。 • objects:包含了创建的各种版本库对象及内容可以简单理解为放了git维护的所有修改。 (4) 使用Git修改文件 Git⽐其他版本控制系统设计得优秀因为Git跟踪并管理的是修改⽽⾮⽂件。如何理解修改呢你在一个文件内新增一行“减少一行”“更改了某个字符”…… 现在我们对ReadMe文件进行修改:
查看工作区操作状态: 那么此时咱们工作区中的ReadMe文件和仓库中的ReadMe文件一定是不同的。我们怎么知道呢因为这是我自己修改的更改的那么我肯定知道。但是你总不能保证哪一天一个懵懂的二五仔跑来你的本地仓库中更改了某个文件而你不知道。 我们可以使用 git status命令⽤于查看在你上次提交之后是否有对⽂件进⾏再次修改。 上面的结果告诉我们ReadMe是被修改的但是还没有被add 和 commit。
查看不同区的文件差异: 可是我们仅仅是知道哪个文件被修改就为止了嘛当然不是是的你通过 git status查到了自己的哪个文件被动过了可是动的哪里增加了那里删除了哪里你是一概不知的。也许你维护着一个文件几行代码唔凭借你超强的记忆力能够分析出现如今的内容哪些地方给动过了。然而如果是一分上百行上千行的代码呢如果你发现不仅仅一个文件通过 git status查到被修改过了呢很显然你压根只能摇摇头双手一摊爱莫能助……
# ⽤来显⽰工作区和暂存区⽂件的差异
git diff [file]# ⽤来显⽰⼯作区和版本库⽂件的差异
git diff HEAD -- [file] # ⽤来显⽰暂存区和版本库⽂件的差异
git diff --cached
git diff输出的内容:
diff --git a/ReadMe b/ReadMe #8d0e412..d4eeb06表示两个文件的哈希值 || 100:表示普通文件 644:表示文件权限
index 8d0e412..d4eeb06 100644 # --- a/ReadMe 表示修改前的文件|| b/ReadMe 修改后的文件
--- a/ReadMeb/ReadMe# -表示修改前,1表示第一行开始
# 表示修改后,1,5表示第一行开始至第五行
# 这里 表示这一行增加了什么...-1 1,5 hello git
(空行)
hello world
hello c
I am coding... 知道了对ReadMe做了什么修改后再把它提交到本地仓库就放⼼多了。 (5) 使用Git版本回退 不知道你是否还记得前言的例子那则小故事说明了版本管理的重要性。Git能够管理⽂件的历史版本这也是版本控制器重要的能⼒。如果哪天你发现需要回退到某个历史版本,重新来过这个时候就需要版本回退的功能了。 值得注意的是回退的本质其实只是着眼于将版本库中的文件内容进行回退至于工作区或者暂存区是否也能进行回退那取决于命令参数。
# 执行版本库中的回退
git reset
参数作用--mixed为默认选项使⽤时可以不⽤带该参数。该参数将 暂存区”的内容退回为指定提交版本内容,“⼯作区” ⽂件保持不变。--soft参数对于⼯作区和暂存区的内容都不变只是将版本库回退到某个指定版本。--hard参数将 暂存区 与 ⼯作区 都退回到指定版本。切记⼯作区有未提交的代码时不要⽤这个命令因为⼯作区会回滚你没有提交的代码就再也找不回了所以使⽤该参数前⼀定要慎重。HEAD ◦ 可直接写成commitid表⽰指定退回的版本 ◦ HEAD表⽰当前版本 ◦ HEAD^上⼀个版本 ◦ HEAD^^上上⼀个版本 ... 可以使⽤〜数字表⽰ ◦ HEAD~0表⽰当前版本 ◦ HEAD~1上⼀个版本 ◦ HEAD^2上上⼀个版本 ... 我想以这样的形式你一定难以理解这个版本究竟是怎样进行回退的这些参数是怎样运作的。所以为了方便测试回退功能我们先做⼀些准备⼯作: 更新3个版本的ReadMe并分别进⾏3次提交。 现如今我们发现版本3有问题想回到版本2想基于版本2重新进行代码编写。由于我们这里是想要让工作区的ReadMe文件回到版本2因此携带的参数必须是 --hard。 版本回退之后我们再次使用git log查看日志这时候我们会惊奇地发现发现 HEAD 指向了版本2。 但此时我又发现版本3毕竟花费了我几十秒钟的心血现在我又想把版本回退到3上去。但此时用git log查只能查到版本2的commit id也就意味着版本3的commit id已经弄丢了。(不过在我们这一台机器上其实在回退之前是记录到了版本3的commit id的按照回退版本2的方式也就可以回退到版本3了)。为此Git还提供了一个命令用于补救这种情况。
# 该命令⽤来记录本地的每⼀次命令
git reflog 这个5aa601c是个啥显然是一个commit id但是是它的一部分而已。是的Git在版本回退的时候也可以使用部分commit id来代表目标版本。 这样我们的版本3也就回来了。 事实上reflog并不是任何场景都下都能找到你丢失的commit id如果开发时间够长导致commit id早就丢失了此时又想退回到该版本其实是不可能的。 小结一下: 我想到了现在恐怕你对Git中版本回退的操作有了一定的理解。这个图能很到位地解释各个参数的功能以及回退后的内容是什么。 如何理解版本回退 当然上面费那么多口舌是针对Git如何进行版本回退。那么Git的内部是如何实现版本你回退的呢 Git的版本回退速度⾮常快 因为Git在内部有个指向当前分⽀(这里就指master)的HEAD指针 refs/heads/master ⽂件⾥保存当前分⽀的最新操作的commit id。当我们进行版本回退的时候可以简单的理解为Git仅仅是给 refs/heads/master 中存储⼀个特定的version。像这样: (6) 使用Git撤销修改 现在我们正在工作区在长时间高压下把代码写得越来越烂想恢复到上一个版本。这时候我们该怎么做呢
情况一: 对于工作区代码还没有进行add操作 对于这种情况采取的最好方式删除你增加的代码即可。 唔这显然只能针对你几天只敲了那可怜的几行代码如果你连续干了三天写了上千行代码呢你怎么知道该删哪些保留哪些噢 之前不是有个 git diff命令用来查看不同版本的文件内容的差异嘛emm这个好。于是乎你盯着那个 git diff 的输出在那里仔细比对啊仔细删啊可不能删除问题啊毕竟改完代码后反而多出来个bug又是一个费时间的活路…… Git为我们提供了更好的方式我们可以使⽤:
# 让⼯作区的⽂件回到最近⼀次ad或commit时的状态
git checkout -- [file]
切记: 不能省略--,否则就是另一个命令。 情况二: 已经add了但还没有commit 当我们把工作区的文件”add”后还是保存到了暂存区呢怎么撤销呢 让我们来回忆一下git reset的其中一个参数--mixed,可以将暂存区的内容退回到指定版本的内容并且保证工作区的内容不变。所以接下来我们只需要让暂存区的内容回退即可。 此时我们就会发现现在的暂存区的干净的只是工作区需要修改。还记得工作区如何进行撤销修改吗 这不就是场景一嘛(这里不做过多演示了)。 情况三: 已经add已经commit了 此刻的文件已经存放在版本库里了该咋办 emm这时候你还是老大老实地按照版本回退的方式吧。可是我怎么知道它的上一个版本呢这不用怕每一个objects对象内都会有一个parent指针指向该版本的上一个版本是谁。 我们需要让工作区、暂存区、版本库都回到上一个版本:
git reset --hard HEAD^ ReadMe 当然这么放肆、张狂地使用 --hard的唯一条件前提是你还没有将你本地仓库的代码推送到远端仓库(也就是git三板斧的最后一步 git push)。否则你总会吸取教训为你的无知、轻狂付出代价。 (7) 使用GIt删除文件 在Git中删除也是⼀个修改操作,在这里我们删除一个已经commit了的文件。 你会发现你这样删除其实是没有卵用的git status 命令会⽴刻告诉你哪些⽂件被删除了。 此时⼯作区和版本库就不⼀致了要删⽂件⽬前除了要删⼯作区的⽂件还要清除版本库的⽂件这样才能保证一致性。
如果是误删: 使用之前提到过的命令 git checkout -- file恢复删除的文件。 如果就是要删除该文件: 因为这样做只是删除了工作区的部分还需要将该文件从暂存区、版本库中移除并且 commit。 这样这个文件也算是成功删除了。 三、分支管理 本章开始介绍Git的杀⼿级功能之⼀:分支。 (1)如何理解分支 此时你会发现同样是三个月的准备时间你同另外一个也想参与这场大赛的张三一样做着相同的准备工作。 直到有一天你觉醒了拥有分身的技能。 由此在正式参与该大赛之前你可以习得比张三多出来的一个技能增加赢得比赛的可能性。 我们在回到版本回退那里因为每一次Git提交就会保存每一次操作的comit id方便回退查找。于是乎这条由Git管理的时间线上会出现多个版本目录。截止目前为止没有出现创建其他分支的情况所以这一条时间线里在Git里这一条分支叫主分支即master分支。 所以HEAD指针压根不是指向的提交的最新版本而是指向的当前分支,当前分支也就是master而真正指向最新一次提交的才是master。每次提交master分⽀都会向前移动⼀步这样随着你不断提交master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀。
(2) 创建分支 Git支持我们查看或创建分支下面我们来创建分支。
# 查看分支状态
git branch
# 创建分支
git branch [branch_name] 在我们创建完分支后Git会在 .git/refs/heads 中新增一个指针dev“*”表示当前正在使用的分支也就是HEAD指向的分支(master)。 另外我们查看dev分支结构时发现dev 和 master指向同⼀个修改。 因此可以这样理解一个分支dev的创建:
(3) 切换分支 创建分支不是让它来走秀场的我们应该如何使用分支在分支环境下进行开发呢
# 切换分支
git checkout [branch_name] -- ! git checkout -- file_name(这是撤销修改)
# 切换分支创建
git checkout -b [branch_name] 现如今我们的HEAD指针指向了当前分支“dev”。 分支上的新增文件: 我们现在开始在dev修改 ReadMe文件并且进行添加、提交操作。 我们现在回退到master分支上再来查看Readme文件我们会发现之前更新修改的ReadMe文件还是原先的样子可是dev上的ReadMe文件已经是被修改了的。 那么能给出解释的唯一理由就是现在这两个ReadMe文件一定不是同一个对象 看到这⾥就能明⽩了因为我们是在dev分⽀上提交的⽽master分⽀此刻的提交点并没有变此时的状态如图如下所⽰。 当切换到master分⽀之时HEAD就指向了master当然看不到提交了 (4) 合并分支 紧跟上一个问题现如今我的master分支看不到dev提交的新版本而我们需要做的就是将“dev”分支合并到“master”分支上。
# 命令⽤于合并指定分⽀到当前分⽀
git merge [branch_name]# 非快进模式
git merge --no-ff [branch_name] ● Fast-forward代表“快进模式”也就是直接把master指向dev的当前提交所以合并速度⾮常快。当然也不是每次合并都能Fast-forward。 (5) 删除分支 在分支和主分支合并完成后对我们来说dev分支其实就没啥用了。那么dev分支就应该没删除掉。
注:如果当前正处于某分⽀下就不能删除当前分⽀
# 删除分支
git branch -d [branch_name]
# 强制删除分支(没有merge的分支)
git branch -D [branch_name] 此时的状态如图如下所⽰。 因为创建、合并和删除分⽀⾮常快所以Git⿎励你使⽤分⽀完成某个任务合并后再删掉分⽀这和直接在master分⽀上⼯作效果是⼀样的但过程更安全。
(6) 合并冲突 有时候并不是你想合并就能合并成功的有时候可能会遇到代码冲突的问题。我们现在先创建并切换到新分支dev1上去。 在 dev1 分⽀下修改 ReadMe ⽂件更改⽂件内容如下并进⾏⼀次提交: 之后我们切换到master分支上很显然我知道该ReadMe文件仍然是不会受到dev1修改的影响的。并且我们会在master分支上对ReadMe文件进行修改,并进行提交。 现在 master 分⽀和 dev1 分⽀各⾃都分别有新的提交变成了这样: 这种情况下Git只能试图把各⾃的修改合并起来但这种合并就可能会有冲突: 当文件发生冲突时查看⽂件内容时Git会⽤来标记出不同分⽀的冲突内容,内容如下: 此时我们必须要⼿动调整冲突代码并需要再次提交修正后的结果(再次提交很重要切勿忘记)。 当然这里的手动删除是保留两个版本commit的其中一个。到这⾥冲突就解决完成此时的状态变成了。
git log查看分支:
# 看到分⽀的合并情况
git log --graph --prettyoneline --abbrev-commit 最后不要忘记dev1分⽀使⽤完毕后就可以删除了。 (7) 分支管理策略 通常合并分⽀时如果可能Git会采⽤ Fast forward 模式。还记得如果我们采⽤ Fast forward 模式之后形成的合并结果是什么呢回顾⼀下。 在这种 Fast forward 模式下删除分⽀后查看分⽀历史时会丢掉分⽀信息看不出来最新提交到底是merge进来的还是正常提交的。 但在合并冲突部分我们也看到通过解决冲突问题会再进⾏⼀次新的提交得到的最终状态为: 那么这就不是 Fast forward 模式了这样的好处是从分⽀历史上就可以看出分⽀信息。 例如我们现在已经删除了在合并冲突部分创建的 dev1 分⽀但依旧能看到master其实是由其他分⽀合并得到。 使用--no-ff参数合并分支: Git⽀持我们强制禁⽤ Fast forward 模式那么就会在merge时⽣成⼀个新的 commit 这样从分⽀历史上就可以看出分⽀信息。 我们需要先创建一个分支的dev2并切换⾄新的分⽀: 修改 ReadMe ⽂件并提交⼀个新的 commit: 切回到master分支进行合并: 可以看到不使⽤ Fast forward 模式merge后就像这样: 所以在合并分⽀时加上”--no-ff“”参数就可以⽤普通模式合并合并后的历史有分⽀能看出来曾经做过合并⽽ fast forward 合并就看不出来曾经做过合并。 分支策略: 在实际开发中我们应该按照⼏个基本原则进⾏分⽀管理 ⾸先master分⽀应该是⾮常稳定的也就是仅⽤来发布新版本平时不能在上⾯⼲活 那在哪⼲活呢⼲活都在dev分⽀上也就是说dev分⽀是不稳定的到某个时候再把dev分⽀合并到master上。 所以一个团队合作的分⽀看起来就像这样 (8) bug与临时分支 假设目前你正处于dev2分支上进行开发开发到一半时突然发现master分支上存在严重的bug需要被解决。在Git中每个bug都可以通过⼀个 新的临时分⽀ 来修复修复后合并分⽀然后将临时分⽀删除。
场景一: 仅仅修改在工作区没有提交:
# 可以将当前的⼯作区信息进⾏储藏,被储藏的内容可以在将来某个时间恢复出来
git stash # 查看历史上 Git把stash内容存放记录
git stash list# 恢复储存的内容并且会在list中删除掉
git stash pop# 恢复后stash内容并不删除
git stash apply # 删除 stash内容
git stash drop使用git stash apply stash{0}指定恢复内容 Git提供了”git stash”命令可以将当前的⼯作区信息进⾏储藏被储藏的内容可以在将来某个时间恢复出来。 因为bug出现在master分支上所以我们得切换回master分支上新建立修复bug的分支。 把fix_bug分支上修复的代码合并到master分支,最后并删除fix_bug分支 ⾄此bug的修复⼯作已经做完了我们还要继续回到 dev2 分⽀进⾏开发⼯作区是⼲净的刚才的⼯作现场存到哪去了 ⽤ git stash list 命令查看: ⼯作现场还在Git把stash内容存在某个地⽅了但是需要恢复⼀下如何恢复现场呢我们可以使⽤ git stash pop 命令恢复的同时会把stash也删了。 恢复完成后我们就可以继续开发代码到后面又添加、提交: 不过呢我们也可以看到在dev2查看ReadMe文件时是看不到修复好bug的新文件是什么此时的状态图该为: Master 分⽀⽬前最新的提交是要领先于新建 dev2 时基于的 master 分⽀的提交的所以我们在 dev2 中当然看不⻅修复bug的相关代码。而我们最终的目的是让master分支合并到dev2分支上去于是乎正常情况下我们现在是会切回 master 分⽀直接合并即可。 但这样其实是有⼀定⻛险的因为在合并分⽀时可能会有冲突⽽代码冲突需要我们⼿动解决(手动解决)。可是现在解决代码冲突的问题是回到了master分支上并且我们无法保证一次性就能解决掉冲突内容面对实际中的几百行、甚至几千行代码时解决的过程中难免⼿误出错导致错误的代码被合并到 master上。 ⼀个好的建议就是:在⾃⼰的分⽀上合并下master,再让master去合并dev。这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试⽽不影响master。 我们可以查看一下日志信息: 上述的日志信息可以转化为以下两步: 删除临时分支:
# 删除还未合并的分支
git branch -D [branc_name] 软件开发中总有⽆穷⽆尽的新的功能要不断添加进来。 添加⼀个新功能时你肯定不希望因为⼀些实验性质的代码把主分⽀搞乱了所以每添加⼀个新功能最好新建⼀个分⽀我们可以将其称之为feature分⽀在上⾯开发完成后合并最后删除该feature分⽀ 但天有不测风云常在河边走哪有不湿鞋的。你亲爱的产品经理告诉你某个已经开发到一半的feature分支功能叫停了虽然你的辛苦白费了但是这个 feature分支理应要被删除的、销毁的。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的。 复制粘贴即可。 小结一下: 所以分支到底有什么用呢假设你准备开发⼀个新功能但是你还没有完全开发完成如果⽴刻提交由于代码还没写完不完整的代码库会导致别⼈不能⼲活了。如果等代码全部写完再⼀次提交⼜存在丢失每天进度的巨⼤⻛险。 现在有了分⽀就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀别⼈看不到还继续在原来的分⽀上正常⼯作⽽你在⾃⼰的分⽀上⼲活想提交就提交直到开发完毕后再⼀次性合并到原来的分⽀上这样既安全⼜不影响别⼈⼯作。 并且Git提供高效的分支创建、切换和删除帮助我们提高开发效率。 本篇到此结束感谢你的阅读。
祝你好运向阳而生~
