2. Git 分支

[Tinellie]

由于多人协助的情况下，每个人都分别制作不同的功能；
又有时候一个功能尚未稳定，不确定是否加入最终版本；
由于存在这些情况，所以需要分支的存在。

我们把新做的功能提交到不同的 「分支」 上，在完善后，再合并到 「主分支」上。

如图，这是一些 Git 的分支模型图，作为一个业余开发者，我个人习惯是开 master，develop，feat，三个分支。

master

主分支，一般是稳定的，可以部署到生产环境中的代码。
不应该直接提交到 master 分支上，应该在 develop / feat 分支提交更改，然后合并到 master 上。

develop

开发分支，用来集成测试新功能。
除了修bug，一般也不会直接提交 develop 分支上。

feat-xxx

开发某个功能的分支，一般是每个人在做自己负责的部分时，从 develop 分支中，创建一个新的 feat-xxx 分支。
之后的更改都提交到这个 feat-xxx 分支上，功能完成后，再合并回 develop。

[Tinellie]

记录 Log

git log

log 命令会调出历史提交记录

如图所示，输入命令后展示出了 3 次 commit的记录

一些参数：

• --oneline：只展示第一行提交信息
• --all：展示所有分支的提交信息（默认只会展示属于这个分支的节点）
• --graph：用线段表示提交的关系

[Tinellie]

分支 Branch

查看分支

git branch

查看已有的分支（绿色带星号的是当前分支）

创建分支

git branch [分支名]        //创建新分支
git checkout [分支名]        //切换到新分支

git checkout -b [分支名]

上下两种做法是等价的

[Tinellie]

合并 Merge

往往项目会由多个人同时开发，不同人完成不同的部分。

通常每个部分会分一个分支去完成，完成后，需要合并到主分支上。

示例

//This is a Test Text File

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace Test
{
    internal class Test
    {

        public void Method()
        {
            Console.WriteLine("ABC");
            Console.WriteLine("This is the version 3 of Test.vs");   //版本是 3
        }

    }
}

比如现在位于 develop 分支，有这么一个文件 「Test.cs」

        public void Method()
        {
            Console.WriteLine("ABC");
            Console.WriteLine("This is the version 4A of Test.vs");   //将版本修改为 4A

            int no1 = 2;
            int no2 = 3;
            Console.WriteLine(no1 + no2);    //添加了这个输出 no1 + no2 的代码
        }

然后我拉出了一个新分支 feat-A，然后对 Test.cs 文件作了上面的的更改，提交

        public void Method()
        {
            string input = Console.ReadLine();  //读取用户的一行输入，
            Console.WriteLine(input);           //然后输出同样的内容

            Console.WriteLine("ABC");
            Console.WriteLine("This is the version 4B of Test.vs");  //将版本修改为 4B
        }

之后我又切回 develop 拉出了一个新分支 feat-B，然后作了一些别的更改，提交

可以看到已经有两个分支了

[Tinellie]

Fast-Forward 合并

然后我切回 develop 分支，把 feat-A 合并回去

git checkout develop
git merge feat-A

由于 develop 是 feat-A 的祖先节点，所以可以直接采用 「Fast-Forward」合并，

即直接将 develop 指针移动到 feat-A 的位置。

[Tinellie]

三方合并（发生冲突时的合并）

可以看到，刚才合并 feat-A 后， develop 就不是 feat-B 的祖先节点了，

A 和 B 都对同一个文件做出了更改，那不就是冲突了吗？这种情况怎么合并呢？

这种情况下，git会做出一个三方合并，
参考祖先节点，和两个分支的节点，自动将更改合并起来。

如果有无法自动合并的冲突，git 会把新文件调出到 Working Directory 和 Stage，进入「合并状态」
用户手动解决冲突后，然后再 commit

冲突的部分会标记成这样

//This is a Test Text File

using System; 
using System.Collections.Generic;        //原本 develop 的代码
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace Test
{
    internal class Test
    {

        public void Method()
        {
            string input = Console.ReadLine();     //develop 已经自动合并好的代码
            Console.WriteLine(input);          //注意此时 develop 分支已经将 feat-A 合并进去了

            Console.WriteLine("ABC");
<<<<<<< HEAD   //被合并的分支
            Console.WriteLine("This is the version 4A of Test.vs");       //develop发生冲突的代码

            int no1 = 2;
            int no2 = 3;
            Console.WriteLine(no1 + no2);
=======   //分隔符
            Console.WriteLine("This is the version 4B of Test.vs");        //feat-B发生冲突的代码
>>>>>>> feat-B   //合并进去的分支
        }

    }
}

手动修改了冲突的内容后，提交即可

        public void Method()
        {
            string input = Console.ReadLine();  //读取用户的一行输入，
            Console.WriteLine(input);           //然后输出同样的内容

            Console.WriteLine("ABC");        //将<<< === >>>之类的分隔符删除
            Console.WriteLine("This is the merged version 5 of Test.vs");        //将冲突的内容合并起来，修改好

            int no1 = 2;
            int no2 = 3;
            Console.WriteLine(no1 + no2);

        }

冲突之后，需要另外提交一次，可以看见上面的 「MERGING」，表示处于「合并状态」

合并好了

VSC 这种编辑器有这种便捷的操作方式，当然你也可以手动修改文本

[Tinellie]

--no-ff 不用 Fast-Forward

git merge [分支名] --no-ff

加了 --no-ff 参数之后，就不会用 Fast-Forward 合并模式，而是像三方合并一样，会进入「合并状态」，需要另外提交合并信息。

一般推荐使用 --no-ff 合并，虽然 FF 似乎很方便，但这样会丢失掉分支的信息，而且这样就不会有 merge commit 这样一个节点记录下合并的信息。
（像前面的例子，merge feat-B 进入 develop 的时候提交了合并信息，但 merge feat-A 的时候直接 FF 了，就没有提交）

如下图所示

[Tinellie]

3. 远程仓库 → #5