GIT 合并 --no-ff
GIT merge --no-ff
在此 post 中，我将请专家 git 尝试解释 git merge --no-ff 如何帮助我们。我在这里 http://nvie.com/posts/a-successful-git-branching-model/（我个人认为这是一个非常好的 post）阅读 git merge --no-ff: "This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature"。所以我发现它真的很有用并做了一些实验。
问题是关于我们如何从git日志信息中知道哪些提交属于每个功能。为此，我做了下一个实验。假设两个用户正在一个软件项目上开发两个不同且独立的功能（以避免合并冲突）。从上一个稳定版本开始，我们将继续这样做：
git init
touch AAA.txt
git add AAA.txt
git commit -m "My stable software version"
//this will simulate our project repository
因此，从此时起，两个用户（名称为 Alice 和 Bob）创建了两个不同的分支并开始处理这些功能：
git branch feature1_Alice
git branch feature2_Bob
现在 Alice 和 Bob 开始同时工作和提交。我们可以模拟他为：
git checkout feature1_Alice
touch f1_A1.txt
git add f1_A2.txt
git commit -m "Solving little bug on feature 1"
Bob 在 Alice 完成这一次之后按照时间线做了两次提交：
git checkout feature2_Bob
touch f2_B1.txt
git add f2_B1.txt
git commit -m "Starting feature 2"
touch f2_B2.txt
git add f2_B2.txt
git commit -m "feature 2: implementing new functionality"
然后 Alice 完成特征：
git checkout feature1_Alice
touch f2_A3.txt
git add f2_A3.txt
git commit -m "Feature 1 finished"
然后 Bob 完成 feature2:
git checkout feature2_Bob
touch f1_A3.txt
git add f1_A3.txt
git commit -m "Feature 2 finished"
现在我们将新功能合并到主分支：
git checkout master
git log
输出：
提交 c58dd35054f83c089292d090781438f37feeffa3
作者：娟
日期：4 月 25 日星期二 10:30:01 2017 +0200
My stable software version
git merge --no-ff feature1_Alice
//We put a message on the created commit
现在 git 日志输出：
提交 50c5d1570fe0c047f72200bd57ef6cef6fa9077e
合并：c58dd35 c136a23
作者：娟
日期：2017 年 4 月 25 日星期二 10:48:12 +0200
Merging feature 1 to main
Merge branch 'feature1_Alice'
提交 c136a23c49c546e5f48d9d0634e9bc51d67370cd
作者：娟
日期：2017 年 4 月 25 日星期二 10:41:49 +0200
Feature 1 finished
提交 c9dbb1b49444555fca528f562d3a38143fd521e9
作者：娟
日期：2017 年 4 月 25 日星期二 10:35:24 +0200
Solving little buf on feature 1
提交 58afad2b46565e614a99d94d1e1aa1c8520f9f2b
作者：娟
日期：2017 年 4 月 25 日星期二 10:35:01 +0200
Starting feature 1
提交 c58dd35054f83c089292d090781438f37feeffa3
作者：娟
日期：2017 年 4 月 25 日星期二 10:30:01 +0200
My stable software version
最后合并特征 2：
git merge --no-ff feature2_Bob
git log
提交 3f27f78fefb30080ace629e561a242a4f8dbca56
合并：50c5d15 2eee0c1
作者：娟
日期：2017 年 4 月 25 日星期二 10:54:20 +0200
Merging feature 2 to master
Merge branch 'feature2_Bob'
提交 50c5d1570fe0c047f72200bd57ef6cef6fa9077e
合并：c58dd35 c136a23
作者：娟
日期：2017 年 4 月 25 日星期二 10:48:12 +0200
Merging feature 1 to main
Merge branch 'feature1_Alice'
提交 2eee0c1bb732443ae7d6f4893d651abfd558d55a
作者：娟
日期：2017 年 4 月 25 日星期二 10:43:14 +0200
Feature 2 finished
提交 c136a23c49c546e5f48d9d0634e9bc51d67370cd
作者：娟
日期：2017 年 4 月 25 日星期二 10:41:49 +0200
Feature 1 finished
提交 cd3bee2906e02df22866ba710891d21eaebb8013
作者：娟
日期：2017 年 4 月 25 日星期二 10:40:12 +0200
feature 2: implementing new functionality
提交 c6fdf092b2645f7d4088f9f439e820a9a820b891
作者：娟
日期：2017 年 4 月 25 日星期二 10:37:39 +0200
Starting feature 2
提交 c9dbb1b49444555fca528f562d3a38143fd521e9
作者：娟
日期：2017 年 4 月 25 日星期二 10:35:24 +0200
Solving little buf on feature 1
提交 58afad2b46565e614a99d94d1e1aa1c8520f9f2b
作者：娟
日期：2017 年 4 月 25 日星期二 10:35:01 +0200
Starting feature 1
提交 c58dd35054f83c089292d090781438f37feeffa3
作者：娟
日期：2017 年 4 月 25 日星期二 10:30:01 +0200
My stable software version
谁能告诉我如何从提交历史和合并提交中看出哪些提交影响了每个功能？当我们及时插入来自不同功能（或来自功能和主控）的替代提交时，我看不到该网络中评论的优势。
使用 --no-ff 的唯一区别是合并提交有哪些提交已被合并的信息，但这对于跟踪提交历史是无用的。
提前致谢。
您可以使用 git log --graph --oneline --decorate --all 查看您的存储库图表，或者只需调用 gitk 来可视化您的历史记录。简单git log提供的线性文本版本不会显示您要查找的信息。
在查看图形表示时，合并提交可确保您可以看到两个分支相交的位置，而快进合并会导致不同的分支显示为线性，尽管它们是并行开发的。
在此 post 中，我将请专家 git 尝试解释 git merge --no-ff 如何帮助我们。我在这里 http://nvie.com/posts/a-successful-git-branching-model/（我个人认为这是一个非常好的 post）阅读 git merge --no-ff: "This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature"。所以我发现它真的很有用并做了一些实验。
问题是关于我们如何从git日志信息中知道哪些提交属于每个功能。为此，我做了下一个实验。假设两个用户正在一个软件项目上开发两个不同且独立的功能（以避免合并冲突）。从上一个稳定版本开始，我们将继续这样做：
git init
touch AAA.txt
git add AAA.txt
git commit -m "My stable software version"
//this will simulate our project repository
因此，从此时起，两个用户（名称为 Alice 和 Bob）创建了两个不同的分支并开始处理这些功能：
git branch feature1_Alice
git branch feature2_Bob
现在 Alice 和 Bob 开始同时工作和提交。我们可以模拟他为：
git checkout feature1_Alice
touch f1_A1.txt
git add f1_A2.txt
git commit -m "Solving little bug on feature 1"
Bob 在 Alice 完成这一次之后按照时间线做了两次提交：
git checkout feature2_Bob
touch f2_B1.txt
git add f2_B1.txt
git commit -m "Starting feature 2"
touch f2_B2.txt
git add f2_B2.txt
git commit -m "feature 2: implementing new functionality"
然后 Alice 完成特征：
git checkout feature1_Alice
touch f2_A3.txt
git add f2_A3.txt
git commit -m "Feature 1 finished"
然后 Bob 完成 feature2:
git checkout feature2_Bob
touch f1_A3.txt
git add f1_A3.txt
git commit -m "Feature 2 finished"
现在我们将新功能合并到主分支：
git checkout master
git log
输出：
提交 c58dd35054f83c089292d090781438f37feeffa3
作者：娟
日期：4 月 25 日星期二 10:30:01 2017 +0200
My stable software version
git merge --no-ff feature1_Alice
//We put a message on the created commit
现在 git 日志输出：
提交 50c5d1570fe0c047f72200bd57ef6cef6fa9077e 合并：c58dd35 c136a23 作者：娟 日期：2017 年 4 月 25 日星期二 10:48:12 +0200
Merging feature 1 to main
Merge branch 'feature1_Alice'
提交 c136a23c49c546e5f48d9d0634e9bc51d67370cd 作者：娟 日期：2017 年 4 月 25 日星期二 10:41:49 +0200
Feature 1 finished
提交 c9dbb1b49444555fca528f562d3a38143fd521e9 作者：娟 日期：2017 年 4 月 25 日星期二 10:35:24 +0200
Solving little buf on feature 1
提交 58afad2b46565e614a99d94d1e1aa1c8520f9f2b 作者：娟 日期：2017 年 4 月 25 日星期二 10:35:01 +0200
Starting feature 1
提交 c58dd35054f83c089292d090781438f37feeffa3 作者：娟 日期：2017 年 4 月 25 日星期二 10:30:01 +0200
My stable software version
最后合并特征 2：
git merge --no-ff feature2_Bob
git log
提交 3f27f78fefb30080ace629e561a242a4f8dbca56
合并：50c5d15 2eee0c1
作者：娟
日期：2017 年 4 月 25 日星期二 10:54:20 +0200
Merging feature 2 to master
Merge branch 'feature2_Bob'
提交 50c5d1570fe0c047f72200bd57ef6cef6fa9077e 合并：c58dd35 c136a23 作者：娟 日期：2017 年 4 月 25 日星期二 10:48:12 +0200
Merging feature 1 to main
Merge branch 'feature1_Alice'
提交 2eee0c1bb732443ae7d6f4893d651abfd558d55a 作者：娟 日期：2017 年 4 月 25 日星期二 10:43:14 +0200
Feature 2 finished
提交 c136a23c49c546e5f48d9d0634e9bc51d67370cd 作者：娟 日期：2017 年 4 月 25 日星期二 10:41:49 +0200
Feature 1 finished
提交 cd3bee2906e02df22866ba710891d21eaebb8013 作者：娟 日期：2017 年 4 月 25 日星期二 10:40:12 +0200
feature 2: implementing new functionality
提交 c6fdf092b2645f7d4088f9f439e820a9a820b891 作者：娟 日期：2017 年 4 月 25 日星期二 10:37:39 +0200
Starting feature 2
提交 c9dbb1b49444555fca528f562d3a38143fd521e9 作者：娟 日期：2017 年 4 月 25 日星期二 10:35:24 +0200
Solving little buf on feature 1
提交 58afad2b46565e614a99d94d1e1aa1c8520f9f2b 作者：娟 日期：2017 年 4 月 25 日星期二 10:35:01 +0200
Starting feature 1
提交 c58dd35054f83c089292d090781438f37feeffa3 作者：娟 日期：2017 年 4 月 25 日星期二 10:30:01 +0200
My stable software version
谁能告诉我如何从提交历史和合并提交中看出哪些提交影响了每个功能？当我们及时插入来自不同功能（或来自功能和主控）的替代提交时，我看不到该网络中评论的优势。
使用 --no-ff 的唯一区别是合并提交有哪些提交已被合并的信息，但这对于跟踪提交历史是无用的。
提前致谢。
您可以使用 git log --graph --oneline --decorate --all 查看您的存储库图表，或者只需调用 gitk 来可视化您的历史记录。简单git log提供的线性文本版本不会显示您要查找的信息。
在查看图形表示时，合并提交可确保您可以看到两个分支相交的位置，而快进合并会导致不同的分支显示为线性，尽管它们是并行开发的。