这是一个创建于 3440 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司最开始决定是使用GIT作为版本控制 , 也都使用了4,5个月了 , 开发人员也都是20多岁年轻力壮的年轻人 , 每个组的组长也一直在做git使用的培训 , 即使是这样 , 还是遇到了非常大的阻碍 , 主要是如下几点 :
1.代码合并导致代码丢失
2.很多人对代码commit到本地后还要push到remote表示很不解
3.个别同事经常反馈commit的记录丢失
因为很多同事都遇到这3个问题 , 所以普偏反馈建议改为SVN作为版本控制 , 特别是接连好几次有同事反馈了第三个问题 , 我和运维都表示很吃惊 , 表示绝对不会出现丢失的情况 ; 但是公司的领导看到这样的反馈 , 还是建议采纳开发的建议 , 改为SVN , 然后运维就将GIT 改为了SVN
个人的一点看法:
对于第一点 , 我觉得完全是开发人员自己的问题造成的 , 如果开发人员不找到自己的原因 , SVN也会出现合并造成代码丢失的问题
第3点问题 , 当时有人说这样的问题 , 我表示也是非常的诧异的 , 我自己也是刚用git , 但是也觉得并不会出现这样的问题 , 之道有一次自己做了这样一个操作 , 在一个branch上checkout了一个commit,然后在这个commit的基础上做了一下修改,然后commit了,最后checkout 原有branch时发现 , 这个commit在branch的log上是不存在的 , 由此我猜测是不是当时那位遇到commit丢失的同事是否也是像我这样操作了 ;
总之用了一个多月的git , 觉得git在需要频繁修改bug的场景下 , 发挥巨大优势的branch比svn还是要好用很多的 ; 发表这个帖子并不是想说git 比svn好用 (LZ在一个公司使用过2年的Microsoft sourcesafe , 那种恶心的版本控制简直不想再提) , 而是提一下自己以及同事在使用git确实会遇到一些影响开发的问题 .
1.代码合并导致代码丢失
2.很多人对代码commit到本地后还要push到remote表示很不解
3.个别同事经常反馈commit的记录丢失
因为很多同事都遇到这3个问题 , 所以普偏反馈建议改为SVN作为版本控制 , 特别是接连好几次有同事反馈了第三个问题 , 我和运维都表示很吃惊 , 表示绝对不会出现丢失的情况 ; 但是公司的领导看到这样的反馈 , 还是建议采纳开发的建议 , 改为SVN , 然后运维就将GIT 改为了SVN
个人的一点看法:
对于第一点 , 我觉得完全是开发人员自己的问题造成的 , 如果开发人员不找到自己的原因 , SVN也会出现合并造成代码丢失的问题
第3点问题 , 当时有人说这样的问题 , 我表示也是非常的诧异的 , 我自己也是刚用git , 但是也觉得并不会出现这样的问题 , 之道有一次自己做了这样一个操作 , 在一个branch上checkout了一个commit,然后在这个commit的基础上做了一下修改,然后commit了,最后checkout 原有branch时发现 , 这个commit在branch的log上是不存在的 , 由此我猜测是不是当时那位遇到commit丢失的同事是否也是像我这样操作了 ;
总之用了一个多月的git , 觉得git在需要频繁修改bug的场景下 , 发挥巨大优势的branch比svn还是要好用很多的 ; 发表这个帖子并不是想说git 比svn好用 (LZ在一个公司使用过2年的Microsoft sourcesafe , 那种恶心的版本控制简直不想再提) , 而是提一下自己以及同事在使用git确实会遇到一些影响开发的问题 .
第 1 条附言 · 2015-07-28 14:02:21 +08:00
看了大家的回复 , 统一回复几点 :
1. 我指的提交丢失并不是物理上的丢失 , 也不是git的问题 , 而是在checkout某个版本之后基于这个版本做了修改然后提交 , 回到master之后在log中找不到这个历史版本上提交的版本了 , 根据刚才的回复我试了一下 , 再次checkout之前修改的版本 , 可以看到HEAD detached at xxx的提示 , 我没有注意到这点是我的疏忽
2.根据回复中提到的强制提交造成提交丢失 , 我觉得是有这种可能的 , 但是当时公司也没有人站出来查证这个问题 , 在出现过几次这个问题之后没有解决领导才决定切换到svn
3.在这里我们不是讨论svn和git谁好用 , 只是讨论一下实践中遇到的一些问题 , 那些说用不好git的同事应该开除 , 我并不这样认为 , 我认为不论是svn还是git , 那些合并不好代码导致其他人代码丢失的同事才是有问题的 , 他们有他们的不足 , 但是并不在我们的讨论范围之内 , 因为我们没有那么多理想的环境 , 那些大公司的混子 , 我也不是没见过
4.那些说我git基础知识差的我也认了, 但是各位 : 作为一个版本控制系统 , 做的最多的不就是提交,合并,更新吗?有多少人会为了这几个基本的操作去系统的研究学习gitpro ? 作为初学者 , 我也不信你有那么强的学习能力把git pro中的每一种场景都结合到日常的操作之中 , 就像开始回复的那些朋友 , 一口咬定git绝对不会丢失提交的占多数 , 能说出强制提交确实会造成提交丢失的也就只有那几个人 , 开始回复的那些朋友 , 你们精通git吗?
5.git确实有git的优点 , 但是那些把svn说的一文不值的人 , 还抨击使用svn的用户 , 你们未免太自大了 ? 请记住 : 存在即为合理 ;
1. 我指的提交丢失并不是物理上的丢失 , 也不是git的问题 , 而是在checkout某个版本之后基于这个版本做了修改然后提交 , 回到master之后在log中找不到这个历史版本上提交的版本了 , 根据刚才的回复我试了一下 , 再次checkout之前修改的版本 , 可以看到HEAD detached at xxx的提示 , 我没有注意到这点是我的疏忽
2.根据回复中提到的强制提交造成提交丢失 , 我觉得是有这种可能的 , 但是当时公司也没有人站出来查证这个问题 , 在出现过几次这个问题之后没有解决领导才决定切换到svn
3.在这里我们不是讨论svn和git谁好用 , 只是讨论一下实践中遇到的一些问题 , 那些说用不好git的同事应该开除 , 我并不这样认为 , 我认为不论是svn还是git , 那些合并不好代码导致其他人代码丢失的同事才是有问题的 , 他们有他们的不足 , 但是并不在我们的讨论范围之内 , 因为我们没有那么多理想的环境 , 那些大公司的混子 , 我也不是没见过
4.那些说我git基础知识差的我也认了, 但是各位 : 作为一个版本控制系统 , 做的最多的不就是提交,合并,更新吗?有多少人会为了这几个基本的操作去系统的研究学习gitpro ? 作为初学者 , 我也不信你有那么强的学习能力把git pro中的每一种场景都结合到日常的操作之中 , 就像开始回复的那些朋友 , 一口咬定git绝对不会丢失提交的占多数 , 能说出强制提交确实会造成提交丢失的也就只有那几个人 , 开始回复的那些朋友 , 你们精通git吗?
5.git确实有git的优点 , 但是那些把svn说的一文不值的人 , 还抨击使用svn的用户 , 你们未免太自大了 ? 请记住 : 存在即为合理 ;
第 2 条附言 · 2015-07-28 18:22:10 +08:00
我觉得你们真没意思 , 都说了并不是在争论GIT SVN谁比谁更好 , 而是讨论团队中使用git的现状 ;
我相信大多数团队都在git的推广过程中都踩过坑 , 就如同@realpg 一样 , 作为git砖家的他也不敢在项目中首选git .
你们有经验就分享经验 , 我作为初学者来学习你们 , 其他初学者也能学到很多东西 ; 但是回复就是一个结论 : svn垃圾 ; git屌炸天 ; 这样真的有意思吗 ?
我相信大多数团队都在git的推广过程中都踩过坑 , 就如同@realpg 一样 , 作为git砖家的他也不敢在项目中首选git .
你们有经验就分享经验 , 我作为初学者来学习你们 , 其他初学者也能学到很多东西 ; 但是回复就是一个结论 : svn垃圾 ; git屌炸天 ; 这样真的有意思吗 ?
 |
1
mahone3297 2015-07-28 11:45:16 +08:00
会丢commit？那么多人用，要丢，早丢的不成样子了吧。。。github估计都要倒了吧。。。
应该是用的人的问题吧。。。没学会git，然后在用git。。。 然后要走老路，用老的东西（抱歉，我就是认为git比svn好）。虽然都是20多岁年轻人，但是思想还是很懒，不愿做创新，改变，学习。 |
 |
2
visonme 2015-07-28 11:46:16 +08:00
用git还是svg其实并不是什么很重要的问题
关键还是看团队成员对那个更加认可，那就用那个呗，对于某个工具在某个场景下的优势其实在很多团队中这都是可以被忽略的。 |
 |
3
xudongz 2015-07-28 11:46:45 +08:00  1
很多人不熟悉git最起码开小会的时候顺便做个培训吧，特别是一些影响大的误操作要强调一下啊，不是每一个码代码的都天生会用这些版本控制的东西，特别是现在好多半路出家的野生码农，以前都是单打独斗的多。
你们领导换回svn是对的，任你有多少理由，给开发造成了障碍就该换。 |
 |
4
crabRunning 2015-07-28 11:47:23 +08:00
什么年代了还用svn
|
 |
5
mingzhi 2015-07-28 11:47:24 +08:00
叫他们先用git的gui 工具先。。。
|
 |
6
vietor 2015-07-28 11:49:49 +08:00 via Android
落伍的人，最不想改变
|
 |
7
chmlai 2015-07-28 11:52:33 +08:00
lz 什么类型的公司?
|
 |
9
benjiam 2015-07-28 11:55:54 +08:00
你们应该用gerrit 帮你们做提交，这样就知道问题了。
|
 |
10
Navee OP @mahone3297
我刚按照我之前的操作测试了一下: 1.在master创建a文件 , 提交一版a001 2.修改a文件提交一版a002 3.checkout a001 , 修改a文件提交一版a003 4.checkout master 查看log ,只有a001 ,a002 5.checkout a001 , 查看log只有a001 丢失并不是针对于正常的操作流程 , 而是针对于我说的这种操作 , 而且这样操作git并不会报错 |
 |
12
raptor 2015-07-28 11:59:50 +08:00
所以说，还是HG大法好，操作命令兼容SVN，功能兼容GIT。
|
 |
13
tigerz 2015-07-28 11:59:52 +08:00
连 git 都学不会的人，不要再做开发害人了，谢谢。
|
 |
14
sortbylist 2015-07-28 12:00:21 +08:00
就知道学习，就知道改变，就知道BB。如果SVN能够解决问题，能够胜任工作，为什么要学git。而且使用中还会丢记录，难道学习没有成本？丢记录不会导致工作问题？你不丢记录你很happy是吧？你学的好你就不管学不好的是吧？没什么争的，哪个好用用哪个，这个好用包括会不会用。
|
 |
15
EPr2hh6LADQWqRVH 2015-07-28 12:00:40 +08:00
会svn懒得学git的 vs. 会git懒得学svn的 vs. 都不会懒得学任何cvs就是喜欢打包用qq传的
|
|
17
EPr2hh6LADQWqRVH 2015-07-28 12:01:13 +08:00
vcs
|
|
18
chmlai 2015-07-28 12:01:21 +08:00
试试 git-flow 呗
|
 |
19
yoa1q7y 2015-07-28 12:02:12 +08:00
我也在公司培训了无数次了，但是还是有很大一部分人不会使用，不能理解（不愿意去研究）
每培训一次，就像一次低能人口普查 |
 |
20
adjusted 2015-07-28 12:02:34 +08:00
git 能丢失东西也是不容易啊... 哪有这么容易玩坏
|
|
21
Navee OP @xudongz 最初并不是由我决定用git的 , 而是几个组的负责人决定的 , 原有开发团队使用了几个月并没有发生过任何问题 , 问题是出现在最近团队扩充了一些新人 (我也是新人) , 新员工有做git使用的培训的. 领导决定换到svn , 是因为项目负责人在新员工反馈问题后再次做了git使用培训, 依旧有反馈问题 , 并且影响了项目的开发 (主要是代码合并问题), 才决定换回svn的
|
 |
22
Catstyle 2015-07-28 12:02:52 +08:00
少年，你都checkout了，你还想看到什么东西？
建议好好看看progit这本书，搞git的应该人手一本，起码过一遍 |
 |
24
tracyone 2015-07-28 12:04:14 +08:00
git其实比svn容易多了，对个人而言，不需要搭建什么服务器....一个git init，然后git add ...然后你就可以开始修改...不断git add然后git commit.
|
 |
25
tabris17 2015-07-28 12:05:19 +08:00
既然平台存在就没必要迁移，各用各得不就好了么
|
 |
26
jarlyyn 2015-07-28 12:05:38 +08:00
git绝对不是必须的。
但连git最基本基本的操作都不能理解的话，似乎有点不太是和做程序员了？ |
|
27
yoa1q7y 2015-07-28 12:05:52 +08:00 1
@Navee 大哥！！！你的表述完全是git的正常表现啊亲
你有没有理解checkout,rebase,HEAD,commit这几个概念啊。。。。原来这就是你所说的提交丢失。。 这完全就是你不会用，或者概念根本没理解 简直无语 |
|
28
Navee OP @sortbylist 我发帖并不是想下个结论svn 和git中哪个更加好用 , 而是想描述一下svn和git在项目开发中使用的问题 , 让那些还在争论项目中是使用svn还是git的同学看看
|
 |
29
2code 2015-07-28 12:07:45 +08:00
我们这边设计师都会用git，那些说会丢commit的人，好意思说自己是做开发的？
|
 |
30
feilaoda 2015-07-28 12:08:48 +08:00 1
赶紧把那些人开了，git都不愿意学，也指望那些人去学一些更深更难的东西。你让他学其他，也会瞎bb。
git带来的好处，只会svn的人能懂？ |
|
31
yoa1q7y 2015-07-28 12:09:07 +08:00
@sortbylist 用了这么多年git，头一次听说有丢失记录的情况
全世界都在用git，请不要把你不会用，不愿研究，理解能力差推卸到git身上 |
 |
32
metrue 2015-07-28 12:09:58 +08:00 via iPhone
我们用perforce，也挺不错的，有专门的integration team 来做大规模merge。
|
 |
33
Andiry 2015-07-28 12:10:00 +08:00 1
@Navee 你所说的这第三步 3.checkout a001 , 修改a文件提交一版a003 根本就不成立，git会提示
You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name 用checkout -b根本不会丢东西 |
|
34
Andiry 2015-07-28 12:11:43 +08:00
不过git也是有缺陷的，如果文件系统挂了还在做修改，很可能reboot之后整个git就挂了，需要手动修正head。这个我还真碰到过。
|
|
35
Navee OP @yoa1q7y
我知道造成commit丢失肯定是我操作上的问题 , 但是你不能否认的是 , 在以一个成功的操作下 , 产生了一些奇怪的问题 , 对使用者( 特别是那些刚刚使用git的用户)来说是多么大的困惑 如@sortbylist 所说 , 你用的没有问题 , 并不能代表别人使用的没问题 . 我只是就自己遇到的问题做了一个操作还原而已 , 你说我操作有问题 , 然而你也并没有说出问题出在哪里, 而是搬出一大堆唬人的概念:checkout,rebase,HEAD,commit , 是不是我再问你你就让我补git 基础知识去? |
|
36
sortbylist 2015-07-28 12:19:16 +08:00
@yoa1q7y 全世界都在用git，吹牛皮也先打下草稿。你怎么不说全世界都在用linux，全世界都在用vim。所以不会用，不会研究，理解能力差就怪公司员工咯，这么牛逼把他们都辞了，招聘简章里写必须会用git，因为我们公司不提供svn，来了也不能开发，快滚。我就呵呵了。
公司领导决定使用git，并且使用了四五个月，就说明是在研究，是在理解，最终无法代替svn，让所有人都能很好的开发，就说明git没有svn好。懒得跟你扯别的。要么辞了那些不会用git的人，要么就转回svn。你选个吧。还不研究，理解能力差。都这么牛逼，windows直接滚蛋。 |
|
37
Navee OP @feilaoda 我确实是不想和那几个天天吐槽git不好用的同事共事的 , 和他们一起工作给人的感觉就是:遇到问题都是找别人的原因
|
 |
38
gengzhengtao 2015-07-28 12:20:22 +08:00
大型项目的分布式开发的确很适合使用 GIT 来进行管理，但是如果你们公司的项目更倾向于集中化代码管理，开发人员无法将代码带出公司，也不需要离线开发，分布式开发，那用 SVN 并没有什么错，而且对于开发人员来说理解起来也简单，误操作也少，反而更好。没有什么是最好的，只有最合适的。
|
 |
39
jdlau 2015-07-28 12:20:34 +08:00 2
丢了代码就说是工具的问题，这人你放心？
|
|
40
yoa1q7y 2015-07-28 12:22:28 +08:00
@Navee 是的，我就是要告诉你把基础知识看一遍
http://git-scm.com/book/zh/v1 我说的这些概念是使用git必须要理解的，请问有什么问题吗？ 你的问题出在你没理解这些概念，请问有什么不对吗？ |
 |
41
kxxoling 2015-07-28 12:24:58 +08:00
丢 commit 是 git log 都没有吗？还是说只是代码变动没出来？前者可能是谁误用了 reset、rebase，或者误删了未完全合并的分支（可能性比较小），后者可能是别人解决冲突的时候覆盖了找个图形化工具看看是哪次合并消失的。
PS：在这里冷嘲热讽真的没意义。 |
 |
42
soli 2015-07-28 12:25:22 +08:00 1
如果是觉得 svn 好用而换到 svn ，没啥可说的。
如果是觉得新人搞不定 git 才换到 svn，这不是逃避问题么？这样的新人毫无挑战精神，连简单的工具都学不会，要来何用？ |
 |
44
ttma1046 2015-07-28 12:26:55 +08:00
找一些好的培训材料培训
1。代码合并必须不能依靠git的自动合并，很多时候我都用kdiff3自己合并，kdiff3是我用过最好的合并工具没有之一。 2。对commit到本地不解这个只能说思想上的定式，没有开放包容一切的头脑，那基本就可以换一个职业了。。 3。这个跟2可能有点关系，我以前经常发生过某些白痴commit了，忘记push就回家了，因为他脑子里一直是commit就是push， 第二天来以为自己昨天已经都push了，就pull了一把，时间一久就从来没有把commit的东西push. |
|
45
Navee OP @Andiry
我这里写的a001 002 指的不是branch 而是commit之后的返回hash 我刚测试了一下 我checkout a001之后修改文件并commit , git 返回 HEAD detached at a003 我co master之后 a003 这次提交在master的log中并找不到 我指的commit 丢失并不是commit在物理上丢失了 , 我知道这次commit a003 一定在某个地方在 , 但是在master或者某个branch上并不能查看到这个commit 我从描述到现在没有说这是git 的问题或者是git 的缺陷 , 只是表示在这种操作场景下会造成commit找不到,会给开发人员造成困惑 那些推荐人手一本gitpro , 推荐阅读gitpro的我觉得也是没有必要的. |
 |
46
revlis7 2015-07-28 12:30:18 +08:00
你们需要一个老手好好带带你们，或者自己先静下心来补一补git的基础知识，把原有的svn的习惯全部抛在脑后。用惯了svn会把一些概念错误的套用在git上，checkout命令就是一个典型。
|
 |
47
zts1993 2015-07-28 12:34:04 +08:00 via iPhone
我就是觉得团队使用svn好。打我啊。
|
 |
48
ll0xff 2015-07-28 12:34:42 +08:00
我觉得加个gerrit之类的review工具才是当务之急。
|
 |
49
bk201 2015-07-28 12:34:57 +08:00
工具而已，大多数人觉得svn顺手就svn，有那么纠结么，推广新工具可以做为培训，然后让他们私下里用用，等都觉得好用时再推不迟。
|
|
50
Andiry 2015-07-28 12:34:58 +08:00
@Navee 没错啊，git已经给出提示了
你checkout a001之后并不在任何一个branch上，当然也不在master上，处于detach状态 你提交了a003也没有任何意义，因为并没有任何一个branch让你提交 等你回到master上自然a003就不见了 我不认为这会造成任何困惑，因为git已经用那么多提示信息明明白白的告诉你了。 |
|
51
soli 2015-07-28 12:35:10 +08:00 1
@Andiry 这个问题不正是 git 的优势所在么？
如果 svn 服务器文件系统坏了。代码历史就真没了。 git 的话，如果一个 git 仓库所在的文件系统挂了，还可以用其他的仓库恢复，并且不丢历史。 正所谓，分布式版本控制。 |
|
52
yoa1q7y 2015-07-28 12:38:43 +08:00
@Navee 简直无法理解lz的做法，都跟你说了你的困惑、你的操作问题完全是没理解，为什么不去补习一下？
就好比你对别人说，我肚子有点饿，别人对你说，你需要吃点东西，结果你却说，我觉得吃东西是没有必要的。。。 |
 |
53
newtonisaac 2015-07-28 12:39:24 +08:00
svn的公司领导不懂技术，我只能说到这了。
|
 |
54
zongwan 2015-07-28 12:39:30 +08:00
IDE项目文件 git很麻烦啊
xcode默认git 项目view 2个人同时改了结构 提交就会冲突 一堆新加 文件 + 删除老文件 不同MD5在 xcode自己的配置文件里乱七八糟的 借地求问 如何解决? 涉及IDE内部自动生成文件(甚至可能有 二进制配置文件) 只能几个人分开时间段 pull了 再修改 push提交吗? |
 |
55
how2code 2015-07-28 12:42:02 +08:00
git reset --hard HEAD~3
git push -f 你执行下看看什么情况、(别在主分支上这样搞，会丢commit的) commit丢失肯定是人为操作错误。 |
|
56
revlis7 2015-07-28 12:42:13 +08:00
@Navee
先不谈什么svn还是git，我们来说说LZ遇到的实际问题。印象中我平时使用git的checkout命令一般都是用于切换分支而已。 按LZ的描述“我checkout a001之后修改文件并commit”，首先checkout到一个commit hash这样的操作一般是不常用到的。因为在git里面这样做意味着使你的当前工作目录脱离了任何一个分支，所以你会看到类似detached的提示，也就导致了你后面的提交也不属于任何一个分支。那么“在master或者某个branch上并不能查看到这个commit”也就不足为奇了。 另外由于git存在本地和远程的概念，所以当本地和远程分支出现分歧时，会有比较复杂的情况需要处理，所以弄清本地和远程分支的概念也很重要。 |
 |
57
zkd8907 2015-07-28 12:42:56 +08:00
又要开战了，围观中。
|
 |
58
est 2015-07-28 12:43:00 +08:00 8
git checkout -f
git reset --hard git push -f 老板，git 要丢数据，赶紧换svn。 |
 |
59
chengzhoukun 2015-07-28 12:43:38 +08:00
@sortbylist 负能量真重，大家都觉得能提高效率的工具为什么不去学
|
 |
61
viator42 2015-07-28 12:43:45 +08:00
你没有把修改的这个commit给merge过去当然不会有了. 用git流程很重要,至少有一个主分支保证所有的commit都合并到这个上面.不然合并来合并去就成一锅面条了.
|
 |
62
mulog 2015-07-28 12:44:33 +08:00
天哪就不能用一两个小时读读 tutorial 吗。。。
printf 都没学会就不要讨论哪个语言是最好的语言了。。 |
 |
63
yueyoum 2015-07-28 12:45:23 +08:00
@zongwan 我没用过 xcode，但是你说的 IDE自动生成的东西，不是应该要 gitignore 吗？
进入仓库的只有 代码，项目配置， IDE配置 这些大家都一样的东西。 如果上面的东西一样了， IDE自动生成的东西 也不会出错吧。 |
 |
64
chocotan 2015-07-28 12:46:29 +08:00
checkout之前的commit的时候，会提示：
You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name |
 |
65
pythoner 2015-07-28 12:48:31 +08:00
你们的逻辑很奇怪
明显是使用工具的方法有问题，却把问题归结与工具本身 |
 |
66
networm 2015-07-28 12:49:39 +08:00 via iPhone
我认为很重要的一点在于 ProGit 第一版较老，毕竟是五年前写的，而 ProGit 第二版很新，其中讲解了大量的以前版本没有的知识，特别是关于如何恢复内容，正确的工作流程。
ProGit 第二版中文版 内容已全部翻译完毕，但是还未完整的审校，整个项目大概只有几个活跃的审校人员，在此希望大家能为中文版的发布贡献一份力量。 ProGit 2nd 中文版 审校协作计划 - V2EX https://v2ex.com/t/202180 |
 |
67
xuyuheng0905 2015-07-28 12:50:06 +08:00
git push --force 必然丢数据，楼主下次出现这样的问题之后，马上用git log --online --decorate --graph --all看一下你本地的分支情况，如果发现你正在改的分支已经不是跟踪的远端分支，那么估计是有人遇到冲突，直接强推服务器，导致服务端提交丢失了。
|
|
68
zongwan 2015-07-28 12:51:15 +08:00
|
|
69
xuyuheng0905 2015-07-28 12:51:56 +08:00
然后看远端分支和本地分支不同的第一个提交，然后找到提交那个人，就是他把数据弄丢了。
|
 |
70
qinglangee 2015-07-28 12:52:41 +08:00
@sortbylist 公司决定用git且用了4,5个月了,还有人把会丢记录的那些操作当作是正确操作. 要不就是真是智力有限学了不了 git, 要不就是根本没拿出哪怕一两个小时来学一下. 这样的程序员辞掉我觉得真没什么问题. 只不过楼主他们公司这种人太多, 辞掉不辞掉都够受的
|
|
71
xuyuheng0905 2015-07-28 12:52:48 +08:00 1
@zongwan 不可以
|
|
72
zongwan 2015-07-28 12:53:46 +08:00
Nib/Xib文件的产生，编译和运行本质 - Ian的日志 - 网易博客
http://heidianfeng.blog.163.com/blog/static/6184345620107311175472/ ``` 另外建议工程里面全部使用xib，如果是nib3.0，也赶紧转换吧。因为nib2.0/3.0编译后nib中包含的界面信息不会被去除，程序发布出去后别人可以打开你的nib进行编辑查看的。 xib编译后生成二进制的nib文件，这个是不可打开编辑的，所以不会暴露你的接口什么的信息，而且如果包含二进制文件的话，你的代码管理系统是不能merge or diff的。 ``` ----- 目前找到的信息 是无解 只能分开时间动这个文件相关的功能 |
|
73
chocotan 2015-07-28 12:53:49 +08:00
楼主根本不是在master分支提交的： 修改a文件提交一版a003
master分支怎么可能会有 |
 |
74
happypy1 2015-07-28 12:55:00 +08:00
|
 |
75
zythum 2015-07-28 12:55:50 +08:00
首先git并不傻瓜。并且命令多。做同一件事情可以用很多方法完成。学习成本比较大。
svn比git简单。基本上命令对于事务是1对1的。学习成本比较小。 git之所以现在流行是因为git在一个合适的时间进入了大家的视野。然后又有一些合适人推波逐流了。 git没有对于svn的绝对优势。上面说svn服务器文件系统挂了。我不能做个备份么。对于svn来说，公司对于代码的管理力度还更大呢。svn还能规定某个账号只能改某个文件目录呢。 所谓工具。用的顺手的，满足自己需求的就是好工具。没有绝对的好工具。就好比Mac osx 和window 哪个操作系统好一样的。 |
 |
76
ieiayaobb 2015-07-28 12:56:32 +08:00
肯定是有人强制提交了啊，揪出来暴打
|
|
77
zongwan 2015-07-28 12:57:03 +08:00
针对楼主这种情况
我建议 走pull request方式 教学下 这样不会丢文件 开发在自己分支 玩坏了自己的分支 求教导下就好了 最后合并到 产品分支的时候 可以处女座下 用git diff 的patch 来合并,去掉重复修改的记录. 比如 文件名更换 , 文件名 又换回来这种记录 方便code review |
 |
78
andyhuzhill 2015-07-28 12:58:34 +08:00
@Navee 我照着你这样用 git会有报警啊 分离的头指针。
我想你还是没有理解git到底是怎么回事 还是再看看 progit吧 |
|
79
zongwan 2015-07-28 12:59:02 +08:00
|
|
80
andyhuzhill 2015-07-28 13:00:34 +08:00
@Andiry 想请教一下 什么情况下会遇到文件系统挂掉？
|
|
82
networm 2015-07-28 13:03:02 +08:00 via iPhone
我说一个可能丢提交的真实例子吧：合并的时候出现冲突，因为对 Git 不熟悉，使用 git reset --hard HEAD 重置后，又 git revert 了一次提交，结果这次提交变成了一次 合并的revert，丢失了合并的另一侧的所有提交。
从根本上来说，要理解每一个操作背后的原理。 在此，强烈推荐阅读 ProGit 第二版，有意愿的欢迎帮助审校中文版！ ProGit 2nd 中文版 审校协作计划 - V2EX https://v2ex.com/t/202180 |
 |
83
yuankui 2015-07-28 13:07:13 +08:00
人自己的问题,但是处于自我保护意识,又不敢承认
另外由于人都有惰性,学了svn,为什么还要我学git? 因此当出现一点问题,就将所有的问题都推到工具身上,实际上是人的问题. 另外公司领导,绝不应该干涉技术,如果他不懂技术的话... |
 |
84
Biwood 2015-07-28 13:08:51 +08:00
以前的公司用 SVN ，新公司用 git ，我觉得 git 比 SVN 好太多了啊，你所说的冲突，我在 SVN 上遇到冲突的情况比 git 上多得多，而且绝大部分是跟开发人员本身的素质相关的，只要操作得当，基本不会出问题。
|
|
85
mahone3297 2015-07-28 13:09:35 +08:00 1
@Navee checkout这样说，也说不清楚。不如，你把所有操作的command，全都记录下来，大家一看便知，哪里有问题。
有些操作，是不能做的。这不是设计的问题，这是思想，是哲学的问题。 比如，linux下面，root用户，你执行 `rm -fr /` 可以执行吗？可以执行。因为linux的哲学是，认为你知道你自己在干什么。git也一样。你想怎样，都可以，我们认为你知道你在干什么。 我的理解就是，你们那边的一批人，不去理解git，也不愿意学习，然后就乱用，最终导致了这样的结果。 |
|
86
Andiry 2015-07-28 13:11:07 +08:00
@andyhuzhill 比如我自己做内核开发，跑测试的时候
|
 |
87
mongodb 2015-07-28 13:13:01 +08:00
好的好的你们用git的都好人，我们用svn的都该死，我们用svn我们的公司明天就倒闭，你们用git你们明天就上市，个个都是CEO，ok？
|
 |
88
ooh 2015-07-28 13:14:25 +08:00
事在人为,说commit丢失的你就该让他多练练姿势
|
 |
90
superbear 2015-07-28 13:25:19 +08:00
用git会出现第二个问题，那是因为他是分布式的。。
|
 |
91
cxe2v 2015-07-28 13:28:34 +08:00
啧啧啧，哪里都缺不了靠工具秀优越的人
|
 |
92
xieweizhi007 2015-07-28 13:35:48 +08:00
commit还会丢失?
|
 |
93
proudzhu 2015-07-28 13:40:02 +08:00 via Android
初略看了下，LZ 公司提交不要 code review ？
|
 |
94
Felldeadbird 2015-07-28 13:43:17 +08:00
明显是自己操作失误导致丢失commit的。让那些人好好回去学GIT吧。估计他们也不打算学。
|
 |
95
newghost 2015-07-28 13:47:29 +08:00
个人认为对于团队而言Git没有SVN好用；
首先Git要比svn复杂的。 Git强调差异化，强调版本分化，进而导至commit和merge比较复杂，对于大型团队而言反而会降低工作效率，增加工作量。 SVN强调版本统一，不同发行版分branch，比较适合团队使用。 还有我们用perfoce，一个类SVN的东东。 |
 |
96
hyzjshwo 2015-07-28 13:51:22 +08:00
本地 自己用git呗，提交用svn呗？
|
 |
97
Mark24 2015-07-28 13:52:48 +08:00
表示一张图搭配Source Tree客户端
使用Git简直是15分钟内学会的事情 从此可以在家写代码了 |
 |
98
imzshh 2015-07-28 13:56:11 +08:00
很有可能是 git push --forse 了。
我待过的几个团队，都是用issue-number作为分支名的，然后code review/测试通过后由专人合并到develop或者其它分支，从来没有遇到过commit丢失的情况。 |
 |
99
swolf119 2015-07-28 13:56:29 +08:00
那些都是很好很好的，可是我偏不喜欢
再漂亮的女人，我不喜欢，你什么都不是 适合的才是最好的！ |
 |
100
realpg 2015-07-28 13:58:55 +08:00 6
我是坚定的git党。
无论我多喜欢git，我都会在我公司的项目首选用svn，除非几个高级程序员自己搞的东西，在所有人都确认非常精通git的情况下才会使用git作为案例的版本控制工具。 1.svn的模型简单粗暴，对于入门培训只需要1分钟，基本日常开发就需要update，commit，任何人给讲3分钟就明白svn是怎么回事儿，不犯错，不出类似楼主这种的问题，对公司来说就是最大的节约成本 2.svn的线性追溯容易。数字化的版本号，一般的IDE集成/GUI内都可使用版本号和时间点来简单描述，对于尤其是团队内有比较一般的普通程序员的时候使用起来问题更少 等等等等。反正一句话，项目用git可以，我要确认所有参与项目的人都已经精通git，且基本预测项目不会引入更多的人，才会拍板。 我从0到精通svn自用了一个小时，我从0到精通git用了小半年。我自认为在技术领域学习能力比较强，还有很多不强的人让他们折腾git就是浪费公司时间 |
Select Language