我有时很难尝试查看git存储库历史中发生的事情,即使使用像SourceTree这样的强大工具,分支图也可能令人困惑.对我来说,主要的问题是我无法分辨哪些分支的某些提交,并且单个分支上的提交字符串通常显示在不同的视觉行上,因为并发分支和在分支上工作的人数增加和减少.
我最初的想法是"如果git存储了提交的分支名称怎么办？那么图表生成器可以将这些提交分组在同一行上".这个问题:为什么Git不将分支名称存储为提交的一部分？问同样的事情(但由于不同的原因),在阅读它和其他一些链接之后,我意识到简单地存储分支名称无论如何也无法解决我的问题.例如,当多个人在其本地分支上使用相同的分支名进行交替提交时,尝试在同一行上显示这些提交在技术上是错误的.
无论如何,等我的问题......
关于问题2:我想的可能是一个名为"工作流"的东西.创建分支时,您可以选择提供工作流名称(或从当前分支的工作流名称"继承"),并且在切换分支时,当前工作流也会发生变化.因此,每个提交都将在工作流的上下文中进行,并且该信息可以存储在提交中,也可以作为单独的元数据存储在git仓库中.我真的不知道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
tree指向列出项目文件夹内容的散列文本文件,此列表可以包含其他树,递归和blobs,它们是文件的散列内容.parent只是另一个提交的哈希 - 这也是另一个像这样的文本文件.作者和提交者行也有Unix时间戳和GMT偏移量.文件的其余部分是提交消息.提交 - 文本文件 - 回答关于自身的5个元问题:谁(作者/提交者),什么(指向树的指针),何时(时间戳),何处(父提交)以及为什么(提交消息) .tree和parent(父可以多于一行的父表示合并提交)是指针.他们说"那棵树描述了这个提交的快照","那个提交/那些提交是它来自哪里."
理论上你可以保留分支名称,但分支也只是指针.如果您在主分支上,则会有一个名为masterin 的文本文件,.git/refs/heads其中包含用于命名您当前所在提交的哈希值(即40位数字).您在该分支上的事实(也称为"头部")只是.git/HEAD文本文件中的一行- 也是一个指针 - 读取ref: refs/heads/master,它只指向master文件heads夹下的文件名refs.它只是指针,但更重要的是,它都非常流畅.
Git希望对于分支来说太愚蠢了.最初创建的提交的分支并不是真正有用 - 或者更好的放置,试图使其有用的东西太不稳定 - 因为您可以随意移动提交.我经常这样做是为了得到我想要的东西.
我意识到我在项目分支上来回进行一般性和特定于项目的提交 - 让我们称之为mixedbranch- 并且项目的东西应该是它自己的分支,所以我交互式地重新引导它们解压缩它们.即我做git branch projectname了添加第二个分支头指向同一个mixedbranch指向(但没有切换到它)的提交,然后做了git rebase -i <commit before I started mixing things>.然后在弹出的文本编辑器中,我删除了所有项目特定的提交行,保存并退出.这在当前名称下重建了分支,但是没有基于项目的提交(最好保持提交的粒度足以容易地实现这一点,这有几个原因除此之外).
然后我做git checkout projectname了切换到新的分支头,它仍然在所有混合提交的尖端保持位置,我反过来做了同样的事情 - git rebase -i <that same old commit before the mixing occurred>但这次删除了非项目特定的行.这使用原始分支提交重建了新分支,没有进行非项目提交,并指向projectname新重定位的头部.现在,无论是分支指向原来的,交织的提交的,他们都从视野中消失,它看起来像a-a-b-b-a-b-b-a-b-a<--mixed已简单地变成a-a-a-a<--nonmixed和b-b-b-b-b<--project.存储最初创建的分支内容现在将变得一团糟.它太"聪明",值得信赖,所以git - "愚蠢的内容跟踪器" - 甚至都没有尝试过.
在跟踪分支上的提交跟踪方面,所有这些都是向后完成的,因为提交 - 那些文本文件 - 只是存储对其父级的引用.你只能弄清楚过去的血统.合并时,您将创建一个新提交,它只是整个合并树的快照.您当前所在的分支(或以其他方式合并)被视为第一个父分支,而合并分支则是第二个分支.如果还有其他分支被合并,它们将是第三个,第四个,等等.通过这种方式,git可以轻松地跟踪主要提交,以跟踪 - 并在视觉上指示 - 哪些提交是,例如,主分公司.当你切换到一个分支并进行提交,然后做一个git log --oneline --graph --decorate --all,你看到这样的东西(来自Vim easymotion插件):
* 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/
即使没有颜色的好处,也很容易看出发生了什么.开发分支是最近承诺的,因此它显示在顶部.如果您按照图表左侧的行,那些是develop和origin/develop分支的主要提交.所有'合并'分支都来自右边.该develop分支有一个合并提交,其中master已合并.您可以将该合并的右侧跟随到主分支(667a668),这也是一个合并提交,其中拉入Layzie/master(06826d7),这是明显开发的afd0e42(这是清楚地在master分支上(直接跟随直线看到master的第一个父提交包含它) - 所有必要的上下文都在图中).那个merge commit(667a668)告诉你那是什么分支 - 它是Lazie/master,远程repo 06826d7的master分支也是如此Layzie.
这是我建议工作流习惯的地方 - 在合并时留下关于单独合并的内容的提交消息.这就是你怎么可以-而且应该IMO -知道什么提交了关于其分支(当前头是告诉这些承诺目前的机制是在其分支).合并说"我左边是我正在合并的分支的目标分支.右边是我正在合并的分支.在我的提交消息中,我正在合并的分支的名称是在我合并它的时间"(重要的一点暗示:你可以在工作时随意更换分支名称,我经常这样做).
通过不将分支名称作为提交的一部分,你可以cherry-pick和rebase周围没有任何东西试图推断不断变化的提交位置,这太难了,而且没有帮助.提交只是一个完整的树快照,包含一些关于谁创建它的元数据,何时以及它在何处适合互连提交的dag.这使您可以从其他分支,甚至其他人的回购中提取提交.我已经使用这个功能将完全不同的repos合并在一起,将提交交错在一起(与我在第一个例子中提到的相反).我已经使用这种能力将特定文件的历史记录从另一个仓库引入新分支,然后将其合并,因此我可以在更合理的位置跟踪其开发.然后我扔出了原本的,垃圾填充的回购,我不再需要了.你可以在这里看到一些关于液体git提交方式的例子,以及你可以用它做多少.
如果我是cherry-pick在同事的'dev'分支的提交中,我并不关心它是否已经开启coworker/dev.我只想在我目前的分支中工作.提交元数据将显示我将它提交到现在的位置,并且我的同事创作了它,当我们每个人都做了这些事情.现在它只是我的分支上的变化,并没有试图弄清楚它们在我的分支上,但过去常常在他们的分支上.试图在这样一个灵活的系统中跟踪它会是一团糟,而你可能最终得到的信息不正确,系统试图变得那么聪明(也许不是,但这似乎是一个难题).我说让合并告诉你想要分支被调用,让git为你排序第一父历史.我可以说,我一直没有任何问题跟着历史甚至几十个分支机构(我们在使用这么多并行分支时,我们已经有了可怕的回购,它们不适合宽屏显示器).
| 归档时间： |
|
| 查看次数： |
985 次 |
| 最近记录： |