Jam*_*ier 15 git commit rebase
我想知道git存储库可以处理的提交数量是否有上限.
在我正在进行的一个独立项目中,我一直在本地编写代码,提交/推送git中的更改,然后在我的开发服务器上进行更改.
我认为这是在本地工作和通过FTP上传更改的更简单的替代方案...幸运/遗憾的是,这是一个如此简单的工作流程,我有时会在编码时经历许多编辑/提交/推/拉/浏览器刷新周期.
我想知道这是否会转过来让我陷入困境.如果它可能是一个问题,我想知道如何避免这种麻烦...看起来像是一个转折可能是要走的路,特别是因为我不必担心冲突的分支等.
joh*_*nny 15
那么"上限"可能是发生SHA1碰撞的点,但由于SHA是40个十六进制数字长(16 ^ 40~1.4x10 ^ 48种可能性),所以它几乎没有可能性甚至不好笑.因此,至少在接下来的几千年里,你几乎有百分之百的机会遇到任何问题.
双曲线示例(只是为了好玩):1次提交/分钟(只更改一个文件 - >使用三个新的SHA(文件,提交,树)= 3个新shas使用/分钟= ... = 1.6M shas used/year = 1.6亿万/千年= 1x10 ^ -37 %使用每个千年......(1000档/每分钟/分钟,它仍然是3.6x10 ^ -35%)
话虽这么说,如果你想要清理你的历史,用rebase压扁它们可能是你最好的选择.如果您公开分享回购,请确保您了解其含义.
您可能还希望在重新定位后进行垃圾收集以释放一些空间(确保首先使用rebase工作正常,并且您可能需要告诉它收集所有内容,否则默认情况下不会收集任何超过两周的内容旧).
我认为 git 可以处理的提交数量没有很强的限制，只有你个人可以消化的。对于更大的项目和多个开发人员，您会看到比您自己生成的活动更多的活动。
如果你愿意，你可以保留一个每周合并的二级分支，但 git 永远不会关心你有多少提交。只要你能理解你在做什么，就去疯狂吧。您始终可以将多个提交回溯或使用 bisect 之类的工具来找出历史问题。
我很确定你根本不必担心:)
Git使用SHA-1哈希来检查文件,哈希冲突的概率接近于零.所以玩得开心!!
我个人每天做大约30次提交没有问题.
但是避免版本化二进制文件:)它真的很重要.
| 归档时间： |
|
| 查看次数： |
4238 次 |
| 最近记录： |