Fatal编程技术网
  • git/
  • 如何在git中获得更有用的分支图？

如何在git中获得更有用的分支图？

git

如何在git中获得更有用的分支图？,git,Git,我有时很难了解git存储库的历史，即使使用像SourceTree这样的伟大工具，分支图也会令人困惑。对我来说，主要的问题是我不知道在哪些分支上进行了一些提交，并且随着并发分支的数量和处理分支的人员的增加和减少，单个分支上的提交字符串通常显示在不同的可视行上 我最初的想法是“如果git存储了提交时使用的分支名称，那么图生成器可以将这些提交分组在同一行上怎么办？”。这个问题：问同样的问题（但原因不同），在阅读了它和其他一些链接后，我意识到仅仅存储分支名称并不能解决我的问题。例如，当多人使用相同的分支

我有时很难了解git存储库的历史，即使使用像SourceTree这样的伟大工具，分支图也会令人困惑。对我来说，主要的问题是我不知道在哪些分支上进行了一些提交，并且随着并发分支的数量和处理分支的人员的增加和减少，单个分支上的提交字符串通常显示在不同的可视行上

我最初的想法是“如果git存储了提交时使用的分支名称，那么图生成器可以将这些提交分组在同一行上怎么办？”。这个问题：问同样的问题（但原因不同），在阅读了它和其他一些链接后，我意识到仅仅存储分支名称并不能解决我的问题。例如，当多人使用相同的分支名称在其本地分支上进行交替提交时，试图在同一行上显示这些内容在技术上是错误的

总之，我的问题是

  • 目前是否有一种方法可以推断出正确的历史分支结构，并生成一个漂亮的分支结构图——可能是寻找“merge master to branchX”样式的提交消息
  • git中是否有一个功能可以帮助保存一些工作流信息（即，在哪些环境下完成了工作），或者这已经是可能的，而我只是做错了
    • 关于问题2：我的想法可能类似于命名的“工作流”。创建分支时，您可以选择提供工作流名称（或从当前分支的工作流名称“继承”），切换分支时，当前工作流也会更改。因此，每次提交都将在工作流的上下文中进行，并且这些信息可以存储在提交中，也可以作为单独的元数据存储在git repo中。我真的不知道git的内部工作原理，所以可能有其他/更好的方法来实现这一点。然后，分支图可以做一些视觉上明显的事情（例如不同的背景颜色），以帮助查看提交链如何在不同的工作流之间流动

    请记住，git自诩为“愚蠢的内容跟踪器”。它不想变得比它需要的更聪明，因为这使它具有高度的灵活性，因此非常强大。提交本身只是文本文件，仅此而已。它们看起来就像这样：

    tree 68cd5b298858425fd8b5c2c0adfa62249b4eb650
parent c9ac0bb0d74d59b1ccb5aa8c498c33314b16948e
author aperson <aperson@somecompany.com> 1368010332 -0700
committer aperson <aperson@somecompany.com> 1368010332 -0700

Add test module for widget.py
    即使没有颜色的好处，也很容易看到发生了什么。开发分支是最近致力于的，因此它显示在顶部。如果沿着图左侧的直线向下，则这些是
    develope
    和
    origin/develope
    分支的主要提交。所有“合并到”分支都从右侧进入。
    develope
    分支有一个合并提交，其中
    master
    被合并。您可以沿着该合并的右侧进入主分支（
    667a668
    ），这也是一个合并提交，它引入了
    Layzie/master
    （
    06826d7
    ），显然是在
    afd0e42
    （显然是在
    master
    分支上）之上开发的（沿着直线向上看master的第一个父级提交包含它）-所有必要的上下文都在图中）。合并提交（
    667a668
    ）告诉您是哪个分支-它是Lazie/master，所以
    06826d7
    是来自
    Layzie
    远程repo的
    master
    分支

    这就是我建议的一个工作流习惯——在合并时，将关于合并内容的提交消息单独保留。这就是为什么您可以——而且在我看来也应该——知道哪些提交在哪些分支上（当前头是告知当前哪些提交在哪些分支上的机制）。合并说“在我的左边是我正在合并的分支的目标分支。在右边是我正在合并的分支。在我的提交消息中是我正在合并的分支在我合并它时被调用的名称”（这里暗示的要点是：您可以在工作时随意替换分支名称，我经常这样做）

    通过不将分支名称作为提交的一部分，您可以
    挑选
    和
    重设基础
    而无需对不断变化的提交位置进行任何解释，这太难了，也没有任何帮助。提交只是一个完整的树快照，其中包含一些元数据，说明是谁创建的、何时创建的以及在何处创建的相互关联的提交的数据集。这允许您从其他分支，甚至其他人的回购中提取提交。我使用此功能将完全不同的回购合并在一起，将提交交错在一起（与我在第一个示例中提到的相反）。我使用这种能力将某个特定文件的历史记录从另一个回购协议中拉到一个新的分支上，然后将其合并，这样我就可以在一个更合理的地方跟踪其发展。然后我扔掉了我不再想要的原始、垃圾填充的回购协议。你可以在这里看到一些例子，说明git的提交是多么流畅，以及你可以用它做多少正因为如此，他们才被解雇

    如果我在一个同事的“开发”分支提交时
    cherry pick
    ，我不在乎它是否在
    coworker/dev
    上。我只想在我当前的分支中完成这项工作。提交元数据将显示我在现在的位置提交了它，我的同事编写了它，以及我们每个人何时做了这些事情。现在只是在我的分支上进行了更改至少，你不会试图找出他们在我的分支上，而是曾经在他们的分支上。在这样一个灵活的系统中，试图跟踪这一点将是一个混乱，并且你可能会在一个试图变得如此智能的系统中得到错误的信息（可能不是，但这似乎是一个困难的问题）.我说让合并告诉您希望调用分支，让git为您将第一个父历史排序到左边。I c 
    * 4fb1af8 (origin/develop, develop) Update jumplist when moving cursor
*   fe9f404 Merge branch 'master' into develop
|\  
| *   667a668 (HEAD, tag: 1.3, origin/master, origin/HEAD, master) Merge pull request #34 from Layzie/master
| |\  
| | * 06826d7 fix EasyMotion#InitHL arguments
| |/  
| *   afd0e42 Merge branch 'release/1.3'
| |\  
* | \   44c6bfd Merge branch 'release/1.3' into develop
|\ \ \  
| | |/  
| |/|   
| * | c4863f8 Update vim docs
| * | 8dc93e6 Update README
|/ /  
* | c1f1926 Update default leader key to <Leader><Leader>
* | 6f0c9b9 Move most of the code to autoload/