branch_branch cut - CSDN
精华内容
参与话题
  • Git:git-branch的用法总结

    千次阅读 2019-07-12 10:50:28
    Git:git-branch命令的使用。 前言 git branch的用法。这个命令使用频度很高,还有一些没有搞明白,在这里总结梳理一下。 之前的文章题目命名都用空格,以前一直不理解git的官网为什么多加一个“-”,现在明白...

    概要

    Git:git-branch的用法总结

    博客

    原帖收藏于IT老兵博客

    前言

    git-branch的用法。这个命令使用频度很高,还有一些没有搞明白,在这里总结梳理一下。

    PS:之前的文章题目命名都用空格,以前一直不理解git的官网为什么多加一个“-”,现在明白了,为了用作文章名和题目比较方便,解了一个惑。

    感觉之前的内容总结得还不是很到位,每次在这个地方遇到问题时,还是应该进来再看看,再看看官网,参考参考别的帖子,看看哪里没有整理总结明白,再补充补充。

    正文

    用法

    git branch [--color[=<when>] | --no-color] [-r | -a] [--list] [-v [--abbrev=<length> | --no-abbrev]]
    	[--column[=<options>] | --no-column] [--sort=<key>]
    	[(--merged | --no-merged) [<commit>]]
    	[--contains [<commit]] [--no-contains [<commit>]]
    	[--points-at <object>] [--format=<format>] [<pattern>…​] // 列出分支(这个用法有点复杂)
    	
    git branch [--track | --no-track] [-l] [-f] <branchname> [<start-point>] // 设置分支本地和远程的关系(上流)
    git branch (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>] // 设置分支上流
    git branch --unset-upstream [<branchname>] // 取消分支上流的设置
    git branch (-m | -M) [<oldbranch>] <newbranch> // 重命名分支
    git branch (-c | -C) [<oldbranch>] <newbranch> // 拷贝分支
    git branch (-d | -D) [-r] <branchname>…​ // 删除分支
    git branch --edit-description [<branchname>] //修改分支描述
    

    git branch有以上这么多种用法,原本我看了几遍,也感觉云山雾绕,所以在上面加了一些备注。

    常用实例

    实例: 展示分支
    最简单的形式:

    $ git branch
    * master
    

    较为详细的形式:

    $ git branch -v
    * master cac453c 从版本库中移除项目配置文件和日志配置文件
    

    可以看到,加了-v,显示出了提交号和提交的信息。

    更为详细的形式:

    $ git branch -vv
    * master cac453c [origin/master] 从版本库中移除项目配置文件和日志配置文件
    

    可以看到,加两个v,除了显示出了提交号,还显示出了上流分支(upstream)的名称。。

    实例: 查看所有分支(包括远程的)

    $ git branch -a
    * master
      remotes/origin/HEAD -> origin/master
      remotes/origin/dev
      remotes/origin/f_1123
      remotes/origin/f_1268
      remotes/origin/f_1316
      remotes/origin/f_1317
      remotes/origin/f_1346
      remotes/origin/f_1347
      remotes/origin/f_1490
      remotes/origin/f_english
      remotes/origin/master
    

    -a就是-all的意思,显示所有。

    实例: 查看远程分支

    $ git branch -r
      origin/HEAD -> origin/master
      origin/dev
      origin/f_1123
      origin/f_1268
      origin/f_1316
      origin/f_1317
      origin/f_1346
      origin/f_1347
      origin/f_1490
      origin/f_english
      origin/master
    

    比上面那个指令少了一项master
    -r的意思是remote,显示远程的分支情况。

    实例: 修改分支名
    master分支名称修改成dev,这里仅仅是举一个例子,正常工作中一般是不应该发生这样的修改,这里只是修改了本地的分支名。

     git branch -m master dev
    

    实例: 删除分支
    删除dev分支,-d是删除,-D是强制删除,这里只是删除本地的分支,并不是删除远程的分支。

     git branch -d dev
     git branch -D dev
    

    删除远程分支的命令如下,需要push到远程,这里涉及到了git-push这个指令:

    git push <remote_name> --delete <branch_name>
    $ git push <remote_name> :<branch_name>
    

    实例: 仅显示分支列表,区别于-v参数

    chaiyudeMacBook-Pro:wzu_sports_android_full chaiyu$ git branch --list
      hotfix
      master
    * t_1546
    

    参考

    https://git-scm.com/docs/git-branch。

    展开全文
  • Git中的分支(branch)概述

    千次阅读 2016-10-09 14:46:07
    Git中的一个分支branch,就是一个带名字的引用,该引用指向一次提交后的状态。 1.本地分支local branch 每次对本地库的提交,只是中本地库中创建了一个commit对象。但是本地库的状态的改变,可能因自本地提交、或者...

    Git中的一个分支branch,就是一个带名字的引用,该引用指向一次提交后的状态。

    1.本地分支local branch

    每次对本地库的提交,只是在本地库中创建了一个commit对象。但是本地库的状态的改变,可能因自本地提交、或者远程库的同步、或者切换到其他提交等等。

    这一个个的commit对象之间是离散的,如何能够追踪本地库的状态呢,本地分支的作用就在于给出本地库的当前commit对象,默认名称为HEAD。

    在通过clone或fetch远程库以创建本地库完成之后,建议首先基于本地库中的remote tracking branch创建一个local branch。

    另外,还可以为本地分支设置upstream configuration,以便于本地库与远程库的同步操作,如git push upstream。upstream configuration是本地分支的一些配置属性,用以给出关联的远程库的必要信息。

    2.远程追踪分支remote tracking branch

    远程追踪分支位于本地库中,是在clone或fetch远程库以创建本地库的时候,自动在本地库中创建的,默认名称为orign/master。
    在本地库中的远程追踪分支,总是与远程库中的一个分支相对应,两者指向同一次提交(即执行clone或fetch时候的提交)。
    远程追踪分支还可用于为本地分支自动创建upstream configuration。
    展开全文
  • Git三大特色之Branch(分支)

    千次阅读 多人点赞 2019-01-11 21:15:01
    我习惯每篇博客都有个开篇 还记得 Git 系列第一篇 Git 自我介绍的话吗?其中有 Git 自己都赞同的三大特色 cheap local branching, ...其中因为有分支的存在,才构成了多工作流的特色,所以 Branch 不愧为 Git ...

    我习惯每篇博客都有个开篇

    还记得 Git 系列第一篇 Git 自我介绍的话吗?其中有 Git 自己都赞同的三大特色

    cheap local branching, convenient staging areas, and multiple workflows

    轻量的本地分支, 方便的暂存,以及多工作流。其中因为有分支的存在,才构成了多工作流的特色,所以 Branch 不愧为 Git 的王牌特色。这篇博客,主要和大家一起学习一下轻若鸿毛,帅到炸裂的分支儿。

    Branch 的概念

    分支的概念,在我看来,分两个版本:

    从使用场景上解释,是这么个概念

    Git 的分支,就是开发过程中,要选择的一条路,你可以选择和其他小伙伴一起走同一条路,也可以自己走一条路,路与路之间相互没有影响,作为路的主人,你也随时可以让两条路合并。

    简笔画 Git 分支

    深入一点的话,是这么个概念

    Git 的分支,其实本质上仅仅是指向提交对象的可变指针,这个可变指针,指向路的终点。同时,还有一个比较特别的 HEAD 指针,用于记录当前工作的位置,借用上面的例子,这个 HEAD 指针等于在路上走的你自己,你在哪,指针就在哪,你在哪个分支,HEAD 指针就指向哪个分支的指针。
    深层次的分支概念图

    实际上,当我们使用 Git 的时候,我们就使用了分支,因为 Git 的默认分支名字是 master,如果你有心的话,会发现执行 git init后,命令行的输出头部已经默认在 master 分支了。 但是这个时候,还并未创建 master 分支,只有当有一个提交的时候,才会创建 master 分支。原因在于,分支的指针要指向提交的呀,突然明白了,当初看 Android Studio 的教程,为什么每个都让有一个初步提交了呢。

    无图无真相,不信的看下面:

    git 默认分支 master

    玩转 Branch 必备技能

    有关分支的命令不多,无非是换着花样的增删改查,掌握好以下基本的命令,以后就可以在 Branch 的草原上策马奔腾潇潇洒洒啦

    创建分支

     git branch <name>
    

    这个命令看起来,似乎简单到你只需要想个分支的名字就好了。
    但是在创建分支的时候,要想下,是否要从当前分支的内容基础上去开辟一条新分支。

    查看分支

    三个命令,让你想看什么分支就看什么分支,就是这么方便

     git branch //查看本地分支
     git branch -r //查看远程分支
     git branch -a //查看本地和远程的所有分支
    

    删除分支

    当本地分支删除后,推动到远程仓库后,远程仓库并不能自动删除远程分支(原因,下回分解)。所以,分支的完全删除是分两个部分的,一个是本地,一个是远程。

    本地删除操作需要加上 -d或者 -D 参数,参数的名称来自英语 delete的缩写,Remember it so easy!

    两者的区别在于-D-d要粗暴一点。当被删除分支有新内容没有被合并的时候,使用-D,会直接删除, 使用-d,会提示该分支有新内容没有被合并,不执行删除。删除需谨慎,建议非特殊情况下,使用温柔的-d要好一点,以免小手一抖,眼泪长流。

     git branch -d <name>
     git branch -D <name> //强制删除
    
    

    删除远程分支需要 push 操作。

    git push origin :<name>
    

    重命名分支

    其实,这是个伪命题。

    但是有很多人,包括我,都有过对分支名称不满意想该修改一下的想法,所以,就有了这个伪命题的存在。

    事实上,分支不存在重命名,没有 rename 的这个命令。如果你起的名字不满意,想重新起的话,那只要创建一个和要修改分支内容一样的分支,起上你喜欢的名字,然后再把之前的给删掉。

    检出分支

    这个检出分支的“检出”二字,算是个关于 Git 分支的专业术语了,你可以理解为切换当前分支。
    本质上, checkout 操作是移动 HEAD 指针,将 HEAD 指针指向要切换的分支的指针处。

    使用场景有两个:

    1. 已经存在的分支,现在要切换过去。
     git checkout <name>
    
    1. 创建一个新分支,并切换到新分支,这个一步到位的话需要 -b 参数。

      以当前分支为基础,创建一个新分支

      git checkout -b <branch name>
      

      以指定的某一个提交,创建一个新分支

      git checkout -b <branch name> <SHA1>
      

    合并分支

    以上,是分支的增删改查独立操作,但是 Git 创造这个分支,并不只是为了让它们自个儿和自个儿玩的,还需要它们之间的相互协作和配合。 就像写项目的时候,分好开发任务,你和你的小伙伴新建了两个分支,你写你的 Anglela,他写他的 baby,到开发完成之后,肯定要合在一起,才能成就 Anglelababy。合的这个动作,就涉及到了分支合并的概念。

    分支合并使用到的命令是

    git merge <branch name>
    

    分支合并相对分支的其他操作,是相对要复杂一点的,怎么说也是多分支操作,至少要对得起它一听就比较高端的名字吧,于是我决定把分支的合并作为一个大标题。

    Branch 合并是大事

    git 的两种合并模式

    分支的合并是非常智能的,目前有两种模式,两种模式的选择,不需要我们参与,而是 Git 根据分支情况不同,自行判断选择的。在我使用 Git 的过程中,执行分支合并,有时需要输入提交信息,有时不需要,作为小白的我懵的不知所以然,后来才知道是因为合并模式的问题。

    两种模式是:

    1. Fast-Forward(快进式)(PS:这个名字是官方的)
    2. Recursive Strategy Merge(策略合并式)(PS:这个名字非官方,我自己起的,有时也叫三方合并式)
    • Fast-Forward(快进式)

    如图,有两个分支,master 分支和 feature 分支。当这两个分支处于上面的关系时,当进行合并操作时,就会出现 fast-forward。

    原因是;由于当前 master 分支所指向的提交是 feature 分支的直接上游,所以 Git 只是简单的将指针向前移动。 换句话说,当你试图合并两个分支时,如果顺着一个分支走下去能够到达另一个分支,那么 Git 在合并两者的时候,只会简单的将指针向前推进(指针右移),因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进(fast-forward)”。

    合并后的分支指针位置如下:

    • Recursive Strategy Merge(策略合并式)

    这个合并方式,是为补充 fast-forward 而出现的,因为你知道,在项目开发过程中,很多人开发的情况下,出现 fast-forward 的情况并不是很多,很多是类似下面这种。提交历史是分叉的,无法满足执行 fast-forward 的条件:

    因为,master 分支所在提交并不是 feature 分支所在提交的直接祖先,Git 不得不做一些额外的工作。 出现这种情况的时候,Git 会使用两个分支的末端所指的快照(C4 和 C5)以及这两个分支的工作祖先(C3),做一个简单的三方合并,生成一个新的提交(C6)。

    实战演练一下

    说起来就是一堆理论,我自己都记不住,找个例子演示一下:

    //创建一个文件夹,并初始化 Git
    mkdir GitDemo
    git init
    
    //初次提交,创建 master 分支
    touch master.txt
    git add.
    git commit -m '添加master文件'
    
    //从master分支末尾,创建并切换 featureA 分支,并创建一个提交
    git checkout -b featureA
    touch A.txt
    git add.
    git commit -m '添加A文件'
    
    //从master分支末尾,创建并切换 featureB 分支,并创建一个提交
    git checkout master
    git checkout -b featureB
    touch B.txt
    git add.
    git commit -m '添加B文件'
    
    //切换 master 分支
    git checkout master
    
    //master 合并 featureA 分支
    git merge featureA
    
    //master 合并featureA 后再合并 featureB 分支
    git merge featureB
    
    

    博主不想给你说话,并向你投掷了一大串命令,快去敲敲看啊,会看到两种合并模式的!

    master 分支合并 featureA 时,是快进式合并:

    master 分支合并 featureA 后, 再合并 featureB 时,已经不满足快进式条件了,此时合并会触发一个三方合并,产生一个新的提交。所以,执行合并命令,会跳到下面的页面,让我们编辑这个新提交的提交信息,默认提交信息是“Merge branch ‘branch name’”. 按 i编辑提交信息, :wq!保存并退出页面。

    合并成功后的提示信息:

    画出上面小例子的分支合并,示意图,如下:

    master 合并 featureA

    master 合并 featureB

    和平解决 Branch 合并冲突

    有人在的地方就有江湖,有分支在的地方,就有冲突。

    有时候合并操作不会如此顺利。 如果你在两个不同的分支中,对同一个文件的同一个部分进行了不同的修改,Git 就没法干净的合并它们,于是就会发生冲突。

    如下,分别在 master 和 featureA ,在master.txt 文件第一行添加一句话,然后两个分支合并,就会发生冲突。

    冲突提示信息中,指明冲突文件为 master.txt。同时,也可以通过 git status 命令,查看冲突的详细信息

    需要说明的是,如果遇到冲突的话,git 就无法自动合并了,接下来要靠我们自己手动解决冲突,方法是:

    1. 查看造成冲突的文件,修改冲突部分
    2. 对修改后冲突文件,执行 git add操作
    3. 创建一个修改冲突的提交。

    先知道一下思路,有个简单的概念在脑子里,接下来,一步一步仔细看~

    第一步:查看造成冲突的文件,修改冲突部分

    冲突文件 master.txt 如下,git 虽然无法解决冲突, 但是已经帮我们帮到最后了,使用简单的三个符号,标明了冲突的地方,以及冲突的两个分支在该地方发生冲突内容。

    符号 意义
    ======= 分隔符
    <<<<<<< HEAD 至 ======= master 分支中该地方的内容
    ======= 至 >>>>>>> featureA featureA 分支中该地方为内容

    接下来编辑 master.txt 文件,完成合并,确认之后,把 git 冲突标识符号给删除掉即可。

    第二步 & 第三步:修改后冲突文件,add && commit

    分支回滚, 有后悔路可以走

    现实中,难免有些时候,你会有后悔的念头。例如每天我迟到的时候,都会后悔为什么第一遍闹钟响的时候没有起床,但是这个世界,没有后悔路可以走,我只能努力做到明天早起。

    但是,Git 中有!,因为神奇的 reset 和 revert 命令~,两个命令都可以达到回滚的效果,两者之间的区别以后会专门说,这里我们使用 reset 。

    提前声明:回滚之前,不要忘记做好备份,有备无患呐。

    本地分支回滚:

    确定回滚到哪个提交,找到该提交的 commit id,执行以下命令,就好了

    git reset --hard commit id
    

    远程分支回滚

    依旧是个伪命题。远程分支不存在什么回滚,要想达到回滚的效果,就是删除之前的远程分支,然后把本地回滚好的本地分支,push 到远程。

    git reset --hard commit id //本地分支回滚
    git push origin :<name> //删除远程分支
    git push origin <name> //用回滚后的本地分支重新建立远程分支
    

    我习惯每篇博客都有个结束语

    这篇博客用了我不少洪荒之力,希望对大家理解 Git 分支有所帮助,不对之处还请指出。
    最近 Git 系列走起,下篇博客见!

    欢迎订阅我的Git系列文章


    欢迎关注博主的微信公众号,快快加入哦,期待与你一起成长! qrcode_130.png
    展开全文
  • Git仓库分支(Branch)和标签(Tag)

    万次阅读 多人点赞 2016-12-30 16:03:28
    Git 仓库分支(Branch)和标签(Tag)规范仓库的分支(Branch)规范,影响到每个团队的工作流的一致性;标签(Tag)便于开发团队、测 试团队和其他团队识别每个项目的版本,特别是在协同处理线上问题的时候,大家可以非常...

    仓库的分支(Branch)规范,影响到每个团队的工作流的一致性;标签(Tag)便于开发团队、测
    试团队和其他团队识别每个项目的版本,特别是在协同处理线上问题的时候,大家可以非常清楚
    地知道线上运行版本和代码库的对应关系。因此我们在制作的时候,主要考虑几个因素:

    • 一是要有一定的规则,方便持续集成CI(自动化构建、测试、分布等)
    • 二是要有一定的自由度,以适应不同团队的内部协作灵活性
    • 要清晰规整,不要参差不齐难以识别

    基于我们当前团队的协作能力和提交代码的质量水平,并考虑方便持续集成CI(自动化构建、
    测试、发布),我们约定下列常驻Branch:

    • develop 分支:顾名思义即持续开发的分支,我们希望每个开发组都在这个分支上保
      持线性的持续小步迭代,正常的CodeReview WorkFlow和开发级的自动CI也在这里进行。
      当开发完一个迭代(Sprint),开发小组有信心转测时,就将代码合并到 release 分支,
      并要求打一个alpha级的Tag(如5.2.0-alpha)
    • release 分支:顾名思义即用于发布过程的分支,包括开发转测(实际上我们认为这里的测试集成测试)、测试和BugFix以及发布上线的过程,当发布成功时要打一个发布beta Tag(如
      5.2.1-beta),并将代码合并到 master 分支
    • master 分支:即有质量保证的、可安全运行的分支,禁止直接代码提交,避免被污染,仅用
      于代码合并和归集,在这个分支上的代码应该永远是可用的、稳定的。当需要拉一个特别的开发分时,
      应该基于 master

    当需要fix线上的一个问题是,应该基于上线时的那个beta Tag做hotfix。当出现线上Bug需要hotfix时,我们需要在上次上线的Tag处拉一个临时的 hotfix 分支进行
    修正,或者在未被其他开发迭代污染的release分支上直接hotfix上线并合并到master和
    develop,然后打一个新的Tag(如5.2.2-beta)

    这个分支体系是我们期望长期持续迭代的分支规划,其它临时分支的删除、创建、命名,都由团队自己
    决定,保持一定的灵活性。但每个团队都应该努力避免对上述常规情况造成破坏的情况发生,如果有特
    殊情况(如有两个并行的开发分支同步进行),需要由各组Leader和QA团队协商提供临时方案,这会
    影响到团队协同中的转测、CI基准分支等。

    关于打 Tag 的规则

    鼓励开发和QA团队共同对勤于打Tag,这便于真正的版本管理,避免有rollback需要或者需要查看和
    对比历史版本的时候的混乱和低效局面。但同时也要求一定的规范性,让人一看便知。

    Tag格式为: MajorVersion.MinorVersion.FixVersion-TypeLabel,其中TypeLabel
    alphabetadevel。具体参见下图举例,其中devel是留给开发过程中
    使用的。

    分工上,开发团队负责打 tag-alpha,测试团队负责打 tag-beta

    但是,自己决定并不意味着胡乱命名,大家仍然要以 语义明(白)(准)确 的原则
    来管理自己的分支和标签名,因为所有这些都是为了提高协作效率。

    这是一个参考示意图:
    这里写图片描述

    事实上,上图和常用的 Git 分支实践是比较相似的,只是为了方便自动化工作,我们将 release 分支常驻并配合 tag 管理了,其他工作的 workflow 基本相似,如下图:

    这里写图片描述

    必读经典:A successful Git branching model

    参考文章:GIT分支管理是一门艺术

    展开全文
  • 一、查看分支 git branch [-r | -a]: 1.git branch查看本地所有分支 2.git branch -r查看远程所有分支 3.git branch -a查看本地和远程所有分支 如图,一般当前本地分支前带有“*”号且为绿色,远程分支为...
  • git branch 分支

    万次阅读 2018-01-23 12:06:12
    Git自学之路(四)- git branch 分支 几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响开发主线。 在很多版本控制系统中,这是一个略微低效的过程...
  • git中branch有三种类型

    千次阅读 2018-07-05 14:26:28
    git中branch有三种类型:local branch本地分支,就是我们平常操作的分支,git中默认是master分支创建分支: git branch b1切换分支: git checkout b1remote branch它实际上是指向远端服务器的某个分支,用来跟踪...
  • 错误: 解决办法: 按照提示在Androidstudio的Terminal中输入git branch --set-upstream-to origin即可;
  • 解决方法: 按照提示在IDEA的Terminal中输入git branch --set-upstream-to origin即可。
  • 有时候通过git push命令时会提示不成功,错误...fatal: The upstream branch of your current branch does not match the name of your current branch. To push to the upstream branch on the remote, use gi...
  • git本地仓库push远程仓库的时候,报了
  • 今天在进行本地开发,进行push时,出现以下错误,这是因为,没有与远程分支建立连接。 解决方法 git push origin dev -u 这个意思是把本地dev push到origin的dev -u表示同时建立关联,以后再推送到远程只需git...
  • Git master branch has no upstream branch的解决

    万次阅读 多人点赞 2018-09-28 10:10:17
    Git master branch has no upstream branch的解决 在push代码时,出现“git master branch has no upstream branch”问题的原因是没有将本地的分支与远程仓库的分支进行关联。如下图所示: 具体原因:出现这种...
  • 输入以下命令:git branch --set-upstream master origin/master来设置分支主机以跟踪远程分支主机试着更新一下,结果如下: 接着输入以下命令·:git branch --set-upstream-to origin/dev dev 再试着更新一下,...
  • git 分支管理 推送本地分支到远程分支等

    万次阅读 多人点赞 2015-12-30 15:48:41
    1、创建本地分支 local_branch  git branch local_branch 2、创建本地分支local_branch 并切换到local_branch分支  git checkout -b local_branch 3、切换到分支local_branch  git checkout local_branch 4...
  • 【IDEA】 Can't Update No tracked branch configured for branch master or the branch doesn't exist. To make your branch track a remote branch call, for example, git branch --set-upstream-to orig...
  • 如题,问题详情如下图 ... There is no tracking information for the current branch. 解决方案 解决如上的问题很简单.在问题图片中已经有了解决方案: 方案 1 检查远程分支是否存在 使用git pull ...
  • Can't update: no tracked branch No tracked branch configured for branch master. To make your branch track a remote branch call, for example, git branch --set-upstream master origin/master 解决...
  • [已解决]Can't update: no tracked branch

    万次阅读 2016-05-30 11:18:58
    报错:Can't update: no tracked branch 我们之前的分支是drome,然后删除了这个分支,换到了另一个分支上面去了,所以出现了这个问题。 解决办法: 0:点击VCS->Git->Rebase 1:然后选择相应的分支...
  • Git在本地新建分支后,必须要做远程分支关联。关联目的是如果在本地分支下进行git pull 和 git push操作时 ,不需要指定在命令行指定远程的分支. 推送到远程分支时,没有关联的情况下而且没有指定, git pull 的...
1 2 3 4 5 ... 20
收藏数 166,954
精华内容 66,781
关键字:

branch