这是一个创建于 3295 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题
Git 的各种宣传都高大上，无论是性能和设计都完爆同类版本控制工具。
那么这看似“完美”的教主的作品，又有什么缺点和不足呢？
 |
1
cqcn1991 2015-11-16 22:01:09 +08:00  1
缺乏一个官方支持的图形界面？
如果有的话，可能愿意使用的人，可以扩大到工程师以外的人 |
 |
4
skydiver 2015-11-16 22:13:22 +08:00 2
缺点是不支持部分(子目录)checkout ，只能 clone 。 clone 还不支持断点续传。
|
|
5
cqcn1991 2015-11-16 22:14:51 +08:00
@Mark24 就是需要第三方安装，这个对非工程师真的就挺不友好了。类似的还有 markdown 。 markdown 若是能自带 stackoverflow 那样的编辑器， adoption 就会大大增加。
|
 |
6
clino 2015-11-16 22:15:25 +08:00
@cqcn1991 git-gui 算不算官方的...
另外软件工程师以外的人哪能了解那么多什么分支 merge sha1,再好的 gui 也会歇菜 |
 |
7
jybox 2015-11-16 22:17:44 +08:00
只支持文本文件，虽然这让 Git 能够成为通用的版本控制系统，但也限制了它的能力。我希望有一个在编程语言级别进行版本控制的工具，能够以类（模块）和函数（或代码库块）为单位（而不是文件）来管理历史，可以在 diff 时忽略格式上的修改，可以让无法通过编译的代码无法提交到代码库，并基于具体的编程语言提供更好的合并建议。
|
 |
8
lightening 2015-11-16 22:21:43 +08:00
命令行参数毫无一致性
删除一个 branch git branch -d 删除一个 remote git remote remove |
 |
9
YuJianrong 2015-11-16 22:45:17 +08:00 1
* repo 记着所有历史的策略会使得 repo 在日积月累的使用中变得越来越大
* 不能应付源代码权限需要严格控制的场景， repo 能拉下来就意味着所有代码都能看到 * 大规模项目需要分成多个 repo ，这使得跨 repo 的单个提交变得非常麻烦，尤其是后面还有 CI 在检查每个提交的时候（相互依赖结果哪个都进不去） * 分多个项目的时候无论是 subtree 还是 submodoule 都不够好用方便 总之在使用了近两年后我觉得比起陈旧的 perforce 来说也并没有 life change 级别的改变，也就自建 branch 快很多这点不错。 |
 |
10
tang3w 2015-11-16 23:06:08 +08:00
@jybox 想法非常好。但是要为各个计算机语言做支持，而且要随时跟上语言的演变以及不同实现之间的差异，恐怕是个艰难的任务。而且只能做一些比较局限的静态分析，对动态能力很强的语言恐怕就有点力不从心了。
|
 |
11
seagoat 2015-11-17 00:01:16 +08:00
@YuJianrong 深有同感
|
 |
12
Felldeadbird 2015-11-17 00:06:29 +08:00
我觉得最大不足就是，没有便捷的权限管理机制。第三方的管理软件可以实现权限管理，但安装麻烦。
尽管团队开发可以协定某些分支不能合并。但总会有新人犯错。如果能够让分支实现天生的权限管理，就想到好了。 |
 |
13
wellsc 2015-11-17 00:56:07 +08:00
如果能够支持大文件，多媒体文件的话就能用来写小说，当网盘，影视编辑等等。
|
 |
14
zonghua 2015-11-17 00:59:48 +08:00 via iPhone
最大的缺点是太复杂不会用
|
 |
15
leomikezee 2015-11-17 02:12:33 +08:00 via iPhone
@jybox 王垠的 ydiff ？
|
 |
16
wsy2220 2015-11-17 02:19:30 +08:00
很多缺点都是为了实现分布式系统，不得不这样做。为了分布式的好处，我愿意忍受这些缺点。
|
 |
17
yyfearth 2015-11-17 07:04:53 +08:00
@YuJianrong 对于开源环境的优点 在企业环境下可能就是缺点了
很多实现对 实现分布式系统 进行了妥协 而对企业环境下的集中管理系统 就造成了一定的不利 比如默认要同步整个项目历史 不能直接划分子项目 而且多项目管理十分麻烦 Git 的最大优势就是 Branch 非常灵活好用 当然也会造成管理困难 如果你用 P4 SVN 根本不会愿意随便开 Branch 麻烦死了 P4 我最讨厌的就是会 Lock 文件 导致编辑的时候很麻烦 以及很多 build 的时候因为权限问题报错 另外就是没有一个好的 ignore 机制 但是管理功能确实很强大 而且多文件时候性能也不错 |
 |
18
Mark24 OP 学习了，实践出真知啊，看书根本考虑不到那么多的情况
|
 |
19
wohenyingyu01 2015-11-17 09:20:07 +08:00
clone 无法断点续传！！！！老子下了整整一周！！！好几次都 90%了又要从头再来！！！
|
 |
20
caixiexin 2015-11-17 09:22:13 +08:00
有些命令有点不知所谓，光看名字不看文档都不知道干嘛用的。有的还找不到规律，就像 @lightening 说的- -
想起当初学 git 时看到的一个笑话： git 可以不用联网做本地分支是很好啊，可是你们用 git 时候不用联网查命令，不用查 cheat sheet 吗 23333 |
 |
22
Mrun 2015-11-17 10:24:14 +08:00
没有像 SVN 一样的权限控制
|
 |
24
mengzhuo 2015-11-17 13:02:59 +08:00
|
|
25
wohenyingyu01 2015-11-17 14:56:56 +08:00
@mengzhuo 我 clone 从来都是--depth=1
|
 |
26
msg7086 2015-11-17 15:44:25 +08:00 via Android
@caixiexin 果断 gui 走起。现在已经完全被惯坏了，除了 rebase -i 以外都不用命令行了。
|
 |
27
robot9 2015-11-17 15:54:21 +08:00
git can't handle really big repos...
|
|
28
YuJianrong 2015-11-17 20:42:00 +08:00
@yyfearth
其实 P4/SVN 熟的话开 branch 也还好不算麻烦，麻烦的是 merge （而且其实真的很多人不好好学怎么用 p4/svn 的，当然我相信这类人用 git 也不会好好学）。 git 的 merge/rebase 确实要强大不少。而且 branch 一定是服务器上开，自己临时本地开一个做不到也比较遗憾…… 至于 p4 lock 文件，其实是可以设置的……文件设置成不要 lock 直接改的模式就和 svn 一样了， ignore 机制那么基础的东西当然也有（虽然我忘了怎么搞了）。 我们现在 git 用法和 svn 差不多（ gerrit 作为提交监控），这样就更加缩小了 git 优点，感觉和 p4/svn 也差不太多了。 |
|
29
clino 2015-11-17 23:28:22 +08:00 1
@Felldeadbird gerrit
|
|
30
yyfearth 2015-11-18 03:10:41 +08:00
@YuJianrong 怎么设置成不自动 readonly ？目前我的 IDE 都会自动处理倒是没问题
只是远程修改文件的时候没办法自动处理 很麻烦 而且远程自动 build 和 test 的时候 有时候会尝试自动修改文件 但是由于 readonly 失败 ignore 是有 需要设置 P4IGNORE 到 p4env 而不是自动到每个目录下面找 因此一个 workspace 只能指定一个 P4IGNORE 文件 这样多项目的时候就很有问题 |
|
31
YuJianrong 2015-11-18 23:23:00 +08:00
@yyfearth 有段时间没用 p4 了我都忘了……隐约记得好像是对文件的设置。我们也是遇到某些文件一定得是可写状态要不软件打不开的问题就干脆全部设置成可写了。但详细哪里设置我已经忘了……
P4IGNORE 是这个行为啊……我们是单项目超多文件夹的所以没感觉到…… |
 |
32
1000copy 2016-03-23 20:38:58 +08:00
一般流程涉及的命令还好，到需要撤销操作的时候，就有点乱。所以，没有人提到 git reset HEAD -- file.ext 这个幽灵般的子命令吗？
使用此命令，可以把 file.ext 移除暂存区。可是为什么不是 git unstage file.ext 呢。 命名应该体现语义， unstage 就是体现了语义的，在 pro git 一书中也建议通过自定义命令的方法，定义一个 unstage ，替代 reset 在此场景下的使用。 git reset HEAD -- file.ext 则是体现了它的实现。你要明白 reset 子命令是从 HEAD 之内取出 file.ext,使用此文件复写暂存区文件，从而达成把已经暂存的文件恢复成前一个版本的效果。为此，你就需要弄明白三个树的存储结构。等到钻入这个黑洞。我明白时，我已经把 tree 的三种存储搞清楚了。我就是这样任性的向偶像致敬的。 OMG ，为了连接 SQL ,你得弄明白关系数据库的存储——就是这个意思。 仿佛还不够复杂，于是还有： 1. git reset --hard HEAD 2. git reset --soft HEAD 3. git reset --mixed HEAD 可是在偶像目前，我不敢乱讲话的。所以，你不妨看看： git reset http://stackoverflow.com/questions/4114095/revert-git-repo-to-a-previous-commit?lq=1 原来并非我不懂。我不是一个人在战斗。 pro git 的作者也说，第一版本我没有说 reset ，是因为，我也不懂。妈蛋，把 git 这么个命令行版本工具写的和 c++ primer 差不多厚的人说我其实写完了一本书也不懂 reset 的。 另外， git add 是有多含义的，对于未跟踪的文件，可以用 add 把它变成已跟踪并且加入暂存区。对于修改的文件，可以用 add 加入暂存区。不同的场景功能是不同的。那么如何把一个未跟踪文件变成（仅仅变成已跟踪呢？我没有看到。 unix 的哲学是单一功能的命令，组合使用。一个多功能的命令未必合适。 我的意思：我对 CLi 的设计略有微词。也许我有些地方没有弄明白，请明白人指正。内部存储、暂存、分支、合并、 rebase 都很好的。 |
 |
33
flyhelan 2021-02-23 15:54:22 +08:00
没人想重新发开一个新的版本控制系统吗？
|
Select Language