• git 学习记录


    (一)多人协作模式

    https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013760174128707b935b0be6fc4fc6ace66c4f15618f8d000 多人协作

    但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?

    • master分支是主分支,因此要时刻与远程同步;

    • dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;

    • bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;

    • feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。


    我:目前master与dev共存,且同时保持远程同步,前者生产作业,后者开发作业,不使用bug与feature分支


    多人协作时,大家都会往masterdev分支上推送各自的修改。(我:前者共同修复bug或紧急需求,后者共同日常开发)




    接下去是一个日常团队协作场景:

    你的小伙伴已经向origin/dev分支推送了他的提交,而碰巧你也对同样的文件作了修改,并试图推送:

    $ git add hello.py 
    $ git commit -m "add coding: utf-8"
    [dev bd6ae48] add coding: utf-8
     1 file changed, 1 insertion(+)
    $ git push origin dev
    To git@github.com:michaelliao/learngit.git
     ! [rejected]        dev -> dev (non-fast-forward)
    error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
    hint: Updates were rejected because the tip of your current branch is behind
    hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
    hint: before pushing again.
    hint: See the 'Note about fast-forwards' in 'git push --help' for details.
    

    推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突,解决办法也很简单,Git已经提示我们,先用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突,再推送:

    $ git pull
    remote: Counting objects: 5, done.
    remote: Compressing objects: 100% (2/2), done.
    remote: Total 3 (delta 0), reused 3 (delta 0)
    Unpacking objects: 100% (3/3), done.
    From github.com:michaelliao/learngit
       fc38031..291bea8  dev        -> origin/dev
    There is no tracking information for the current branch.
    Please specify which branch you want to merge with.
    See git-pull(1) for details
    
        git pull <remote> <branch>
    
    If you wish to set tracking information for this branch you can do so with:
    
        git branch --set-upstream dev origin/<branch>
    

    git pull也失败了,原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置devorigin/dev的链接:

    $ git branch --set-upstream dev origin/dev
    Branch dev set up to track remote branch dev from origin.
    

    再pull:

    $ git pull
    Auto-merging hello.py
    CONFLICT (content): Merge conflict in hello.py
    Automatic merge failed; fix conflicts and then commit the result.
    

    这回git pull成功,但是合并有冲突,需要手动解决,解决的方法和分支管理中的解决冲突完全一样(第四条)。解决后,提交,再push:

    $ git commit -m "merge & fix hello.py"
    [dev adca45d] merge & fix hello.py
    $ git push origin dev
    Counting objects: 10, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (5/5), done.
    Writing objects: 100% (6/6), 747 bytes, done.
    Total 6 (delta 0), reused 0 (delta 0)
    To git@github.com:michaelliao/learngit.git
       291bea8..adca45d  dev -> dev

    因此,多人协作的工作模式通常是这样:

    1. 首先,可以试图用git push origin branch-name推送自己的修改;

    2. 如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;

    3. 如果合并有冲突,则解决冲突,并在本地提交;

    4. 没有冲突或者解决掉冲突后,再用git push origin branch-name推送就能成功!

    如果git pull提示“no tracking information”,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream branch-name origin/branch-name

    这就是多人协作的工作模式,一旦熟悉了,就非常简单。

    小结

    • 查看远程库信息,使用git remote -v

    • 本地新建的分支如果不推送到远程,对其他人就是不可见的;

    • 从本地推送分支,使用git push origin branch-name,如果推送失败,先用git pull抓取远程的新提交;

    • 在本地创建和远程分支对应的分支,使用git checkout -b branch-name origin/branch-name,本地和远程分支的名称最好一致;

    • 建立本地分支和远程分支的关联,使用git branch --set-upstream branch-name origin/branch-name

    • 从远程抓取分支,使用git pull,如果有冲突,要先处理冲突。





    (二)分支定义、提炼逻辑过程
    http://www.cnblogs.com/JoannaQ/p/3978252.html


    • 每天工程师都需要git pull origin develop来更新develop分支,然后将develop分支合并到你正在开发得feature/xxxxx分支上来保持代码最新
    • 切记不能直接在develop上进行开发

    不知道什么意思
    10.30知道了,就是保持develop分支的纯净

    我:项目组较小,实施改为

    • 每天工程师都需要git pull origin develop来更新develop分支,保持代码最新


    分支定义:

    • master分支对应线上版本,上线都使用master;      (ok)
    • develop是开发分支,用于生成提测分支release,始终保持最新;     (ok)
    • hotfix是紧急分支,从master生成,bug修正后自动合并到master和develop并且生成tag;     (这里直接操作master分支)
    • feature是私有分支,用于开发新需求和需要较长时间的BUG修改          (不使用,直接在dev分支上日常开发)
    • release是提测分支也即常规分支,测试并且bug修改结束后生成该版本tag,后续可以使用git show tagname来查看版本信息或者回滚(不使用,直接在dev上生成release)
    5个分支简化为2个,
    master+hotfix-》master   生产,生产修复,紧急需求
    feature+dev+release-》dev     日常开发,提炼release





    (三)另一个更具体的多人协作生动场景
    基本遵循程序:git push , git pull , 处理冲突 , git add .  , git commit/push
    http://www.cnblogs.com/onelikeone/p/6857910.html


    甲收工,准备下班了。在下班之前,需要将最新版本推送到git服务器。

    开始使用命令,执行如下:

    结果出错了,why

    之所以会出错,原因在于:其他程序员已经将最新的一个版本提交到git服务器上,但是你在提交之前,已经不是最新的。

    在这种情况下,甲,需要先从服务器拉取最新的版本。

    (5).从远程服务器拉取版本(git pull

    在多人协助开发时,每个开发人员在推送自己的最新版本时,都需要确保当前版本是最新的,所以就需要先获取最新版本,也就是说需要从服务器拉取最新版本到本地。

    需要使用 git pull命令

     

    如此一来,甲当前就是最新的版本。

    然后再次使用 git push 命令推送至服务器。

     

    接下来需要分两种情况:

    如果有新的开发人员加入进来,重复2~5过程。

    如果不是新的开发人员,重复3~5过程。

    比如,对于乙而言,其实它现在已经不是最新的版本了,所以需要使用 git pull 拉取最新版本。

     

    所以,对很多开发人员而言,一打开电脑,马上先git pull,拉取最新的。然后进行常规开发,

    开发完毕之后,在git push之前,还需要使用git pull再拉取一遍。

    没有提到冲突




    (四)冲突

    https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001375840202368c74be33fbd884e71b570f2cc3c0d1dcf000 解决冲突



    下面是解决冲突:

    merge 非快速时的冲突(与pull origin 冲突一样,
    self  merge other
    self  pull origin self ( equel other )
    )前提  :a的改动和b或origin的改动在同一个地方

    人生不如意之事十之八九,合并分支往往也不是一帆风顺的。

    准备新的feature1分支,继续我们的新分支开发:

    $ git checkout -b feature1
    Switched to a new branch 'feature1'
    

    修改readme.txt最后一行,改为:

    Creating a new branch is quick AND simple.
    

    feature1分支上提交:

    $ git add readme.txt 
    $ git commit -m "AND simple"
    [feature1 75a857c] AND simple
     1 file changed, 1 insertion(+), 1 deletion(-)
    

    切换到master分支:(注:checkout时 ,本分支必须提前commit 或 stash)

    $ git checkout master
    Switched to branch 'master'
    Your branch is ahead of 'origin/master' by 1 commit.
    

    Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。(这里我有异议,feature 的 commit 不会自动合并到master)

    master分支上把readme.txt文件的最后一行改为:

    Creating a new branch is quick & simple.
    

    提交:

    $ git add readme.txt 
    $ git commit -m "& simple"
    [master 400b400] & simple
     1 file changed, 1 insertion(+), 1 deletion(-)
    

    现在,master分支和feature1分支各自都分别有新的提交,变成了这样:

    git-br-feature1

    这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突,我们试试看:

    $ git merge feature1
    Auto-merging readme.txt
    CONFLICT (content): Merge conflict in readme.txt
    Automatic merge failed; fix conflicts and then commit the result.
    

    果然冲突了!Git告诉我们,readme.txt文件存在冲突,必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件:

    $ git status
    # On branch master
    # Your branch is ahead of 'origin/master' by 2 commits.
    #
    # Unmerged paths:
    #   (use "git add/rm <file>..." as appropriate to mark resolution)
    #
    #       both modified:      readme.txt
    #
    no changes added to commit (use "git add" and/or "git commit -a")
    

    我们可以直接查看readme.txt的内容:

    Git is a distributed version control system.
    Git is free software distributed under the GPL.
    Git has a mutable index called stage.
    Git tracks changes of files.
    <<<<<<< HEAD
    Creating a new branch is quick & simple.
    =======
    Creating a new branch is quick AND simple.
    >>>>>>> feature1
    

    Git用<<<<<<<=======>>>>>>>标记出不同分支的内容,我们修改如下后保存:

    Creating a new branch is quick and simple.
    

    再提交:

    $ git add readme.txt 
    $ git commit -m "conflict fixed"
    [master 59bc1cb] conflict fixed
    

    现在,master分支和feature1分支变成了下图所示:

    git-br-conflict-merged

    用带参数的git log也可以看到分支的合并情况:

    $ git log --graph --pretty=oneline --abbrev-commit
    *   59bc1cb conflict fixed
    |
    | * 75a857c AND simple
    * | 400b400 & simple
    |/
    * fec145a branch test
    ...
    

    最后,删除feature1分支:

    $ git branch -d feature1
    Deleted branch feature1 (was 75a857c).
    

    工作完成。


    注:

    远程的master和dev分支合并时一般不会冲突
    dev 日常开发 —— dev test release ——测试—— checkout master —— merge dev 
    master分支不提交,只等到test release测试完毕后merge dev分支

    一般情况下是快速合并,也可用--no--ff 加强commit 的显式
    git branch
    *dev
    git commit -am "release"
    git push origin dev
    git checkout master
    git merge --no-ff -m "merge with no-ff" dev
    git push origin master

    (除了直接在master上修复bug或紧急需求后,合并到dev使其最新的过程中,两个分支修改了同一处)







    完。2017.12.13 最后批注

  • 相关阅读:
    android开发环境搭建日记和嵌入式Android开发环境初探
    QT210 android2.3 和android4.0 烧写编译日记
    RAM,SRAM,DRAM,SDRAM,DDR RAM,ROM,PROM,EPROM,EEPROM,NAND FLASH,NOR FLASH的区别
    如何修改终端用户名颜色修改为红色(可以自由定制)
    FPGA机器学习之stanford机器学习第三堂2
    FPGA机器学习之stanford机器学习第三堂1
    FPGA机器学习之stanford机器学习第二堂2
    FPGA机器学习之stanford机器学习第二堂1
    FPGA机器学习之stanford机器学习第一堂
    FPGA片外存储器ddr2之DQSn引脚的分析
  • 原文地址:https://www.cnblogs.com/silyvin/p/9106773.html
Copyright © 2020-2023  润新知