- 主题:git算不算典型的shit山项目？
有用的提交不给个分支名留着非要去reflog里翻，这哪天丢了也能怪git坑？
只能怪git功能太多，胡用也能撑这么久
【 在 hyperLee (醉里挑灯看剑) 的大作中提到: 】
: 这就是坑点所在。reflog默认不显示，用gui界面除非专门指定显示reflog，也不会显示。
: 要是什么时候忘了自己的reflog里边还有重要东西，按照提示git gc一下， 那叫一个酸爽。
: 我要是老板的话， 这个哥们可以准备找下家了。
: ...................
--
修改:cybereagle FROM 211.97.123.*
FROM 211.97.123.*
switch + restore 引入之后 checkout 就不是推荐的用法了
如果是老用户，不看这个列表也应该知道 co 怎么用
新用户就去看 switch 和 restore
这也没什么问题吧？
【 在 hyperLee (醉里挑灯看剑) 的大作中提到: 】
: 然后外星人说，你的说明书上只有r档。地球人窃喜，终于坑了一片人。
: 话说，直接打git，出现的短命令列表你自己不看吗？checkout在里边吗？reset有没有？
: 自己看看不就知道了。
: ...................
--
FROM 110.84.205.*
我是不大能理解没事 reset --hard 前后跑来跑去的用法
有效的 branch head 不应该随便扔掉
如果为了查看特定版本，detached head 有什么不能满足的吗？
【 在 pangwa (学门手艺，混口饭吃.) 的大作中提到: 】
: reflog应该有一个gc时间， 但一般情况下肯定够长了。。。
--
FROM 110.84.205.*
这就是 detached head 的场景啊
这种场景我会用
git checkout HEAD~5 看
然后
git checkout temp-branch 回去
这样 HEAD 是安全的
而且 detached head 很显眼
也避免发现有个地方要改随手一 commit 但是又忘记了当前不是最远位置的惨剧
【 在 pangwa (学门手艺，混口饭吃.) 的大作中提到: 】
: 这个看个人习惯吧， 我用reflog一般也是因为误操作找不到提交了， 只好通过reflog找， 也很少用。
: 开发的时候会用reset --hard的情况有， 比如想看一个旧的提交的状态，（gcb temp-branch && git reset --hard HEAD~5) 之类的， 如果本地branch和远端关联了，可以快速通过gup回到远端的最新状态。。。
--
FROM 110.84.205.*
是基于snapshot的吧……
【 在 hyperLee (醉里挑灯看剑) 的大作中提到: 】
: 我来回答你，git，mercurial 都是基于差分的系统，而空文件夹没法做差分。
: #发自zSMTH@RVL-AL09
--
FROM 211.97.123.*
真需要调整历史的时候 reset 合理
但是前面很多人不是
另外 rebase -i 完美解决你这问题
【 在 teleheart (teleheart) 的大作中提到: 】
: git reset还是比较常用的吧。比如希望把最后几个commit调换一下顺序就可以先git format出来，再reset然后重新打上去。或者直接就舍弃最后一两个debug的commit了。你不用的话一般怎么搞？
--
FROM 120.36.38.*
本地分支离发布还有好大一段距离呢
分布式VCS你不可能控制用户的操作
不提供修改历史他也可以干掉分支从头来过
把commit导出成一堆独立patch然后重新换个顺序导入你挡得住么？
与其让用户自己瞎搞还不如提供可靠的操作让用户可以安全地编辑历史
【 在 spadger (void*) 的大作中提到: 】
: 不允许修改历史更安全。设计冻结发布以后就不应该再改动。
--
FROM 120.36.38.*