Tag Archives: git

如何避免误删除代码带来的灾难

下午,一位同事急匆匆找我,说他在操作TotoriseGit时不小心点击了删除菜单,导致本地的项目整个被删,问我有没办法恢复。我看了看他的提交历史,最后一次提交居然是在几天前,基本上可以认为,这几天做的修改可能都要打水漂了。因为Git对代码版本控制的最小粒度是Commit,即一次提交。这几天下来积累的未提交代码没有被Git管理起来,一旦删除,将无法通过Git的手段来恢复。 发生这种灾难性的结果,不能只怪TotoriseGit没有做好删除确认这一步,更应该检讨自己没有养成良好的提交习惯。 关于良好的提交习惯,我在之前的文章中已有说明,其中一点就是控制好提交粒度,也就是提交的原子性,在此,我需要再补充一点,就是尽量使用小粒度的提交,用频繁的小粒度提交来代替较少的大粒度提交,即一天可以提交3次的话不可等三天再提交1次,因为累积的未提交代码越多越容易出问题: 误删除的灾难,正如这一次我同事遇到的意外一样,累积的未提交代码无法恢复,损失惨重。 提交粒度太大不方便回滚,一次提交里如果包含了登录、首页、甚至是用户管理等功能点,临时发现首页的修改有误,要恢复到上个版本时无法实现快速回滚,因为一回滚,登录和用户管理功能也随即回到了从前。 按理说啊,程序员同学们应该享受提交代码的乐趣才对,该提交时就提交,别太腼腆了啊! 所幸的是,该同事几天来做的修改大都是新增代码文件,没有加入版本管理,TotoriseGit删除文件的时候没有把这些文件一起删除,解决办法就是checkout一次HEAD的版本再把新文件加进去,补充少量丢失的修改,也算是不幸中的大幸吧。但建议不要因此而抱侥幸心理,以后继续累积几天下来再提交一次代码。这次的教训值得深省了!呵。 另,为防止同类事故继续发生,我另一位同事给出了不在TotoriseGit菜单里显示删除功能的设置方法: 使用windows git的GUI的同志请注意,由于delete命令没有确认窗口,为了防止手震点到导致误删除,请空白处右键菜单进入setting,选set Extend Menu Item,勾选上delete和delete(keep local)。就可以屏蔽菜单里的删除(需要用到这两项的时候按住shift然后点右键就可以看到他们出来了)。  

Posted in 技术, 软件 | Tagged , | Leave a comment

Git的推广心得

这两周已经开始在公司几个项目/产品里推广Git了,有一些心得,在此分享: 工具神马的都是浮云 实际上,工具神马的都是浮云! Git或HG之类的DVCS就是神器吗?不,充其量也只是另一个VCS或SCM,所谓的分布式、轻量级分支神马的在某些人看来或许是扯蛋的玩意,人家可能用SVN用得不知有多爽多出神入化呢。如果你仅仅是因为要推广一种新工具而去推广Git,那你一定会饱吃闭门羮。不信试试。 真正重要的,是驾驭在工具上面的灵魂(思想),有些人虽然用着Git,但只把Git当作备份工具用;有些人尽管还用着古老的抢占式的VSS,但提交的守则却是规规范范,标签打得清晰条理!前者不管用什么版本管理工具,都是YAST(Yet Another Scm Toolkit),而后者不管用什么管理工具,都能把代码版本管理得齐齐整整。 记住一点:不要把版本管理工具当作代码备份工具用!否则,你需要的只是dropbox。 既然工具是浮云,那我为什么还选择Git?嘿,当你的团队开始有了强有力的版本管理意识支持后,就会下意识地选择方便趁手的工具(好吧,我这里不说强大),Git实际就是这么一种工具,适合各种各样有洁癖的人、提交狂人等。 规范地使用SCM才是正经事 如果你的团队习惯把SCM当备份工具用,那么恭喜你,你有足够好的切入点推广Git了。如何判断一个团队是否把SCM当作备份工具了,有大概以下几个可供参考的现象: 一古脑儿的提交文件,有时1个文件,有时十几个文件,N个功能点一齐提交 备注的特征:“略”,“提交一些代码”,“fix一个Bug”,“今天的代码”等 从来不给代码打上版本号,程序从头到尾只有唯一一个版本,就是Now 遇见冲突就慌张,不懂处理 等等 我推广Git,目的不是为了Show up,说我懂得一个很潮的东西,你们也跟着用吧,而是要彻底改变团队把SCM当备份工具用的习惯,是为产品代码质量负责。 代码版本管理,最终目的是要实现代码版本的可控性,包括大至版本级的重取,包括功能级别的增减,甚至是小至commit级别的回滚。我用以达到这种可控性的是一些规范,而非Git本身(当然Git及它的扩展Git flow立功不小)。 我制定的规范大致有两个: 双分支代码结构 严格的代码提交规范 并有一个推荐的(非强制的)最佳实践: 使用git-flow轻松控制提交粒度 双分支代码结构 双分支指项目推进过程中总是保持使用两个主分支:开发分支(develop)、成品分支(master)。 1)开发分支(develop) 日常的开发工作都是围绕该分支进行。开发分支上的代码只有在封版的时候才会被合并到master分支。 本地的develop分支,开发人员在上面开发功能并提交,当完成一个完整的功能开发并通过测试时,才能把代码push到远程的develop分支。 远程的develop分支上的代码,要求在任何时候总是可以通过编译,所以每次队员把代码push到服务器上之前,需要确保自己的代码已通过编译并测试。远程的develop分支的代码会用于项目的自动构建。 2)成品分支(master) 该分支上面的代码总是稳定的,成品级的。只有在每次发布新版本的时候,才会从develop上面把上版本开始到现版本的修改移到master分支,master分支通过标签(tag)来区分不同的代码版本。产品的实施人员所面对的总是该分支。 代码提交规范 代码提交规范有三大点,必须严格遵守: 控制好提交粒度。每次的提交都必需具有独立性的原子性,建议是以一个功能点或Bug fix为单位;无直接关联的文件不能在同一次提交;除了初次提交,尽量不用commit -a。 认真对待提交备注,多花一分钟回想本次提交的代码所含的意义,清晰描述下来,很有可能以后看备注的人是你。 … Continue reading

Posted in 技术, 软件 | Tagged , , , , | 5 Comments

你为神马不用git-flow呢?

这是一篇译文(原文在此),当时我从这篇文章开始初识git-flow,经过一段时间的实践后,觉得git-flow非常棒,我决定在团队里面推行,我需要写一篇使用的教程,重新读这篇文章的时候,我认为,我只需要把它翻译成中文版,就是给队员们很好的教程了。遂。。拙译如下,个别地方可能不太靠原文,请看官明了: ================================ 今年的一月, @nvie 同学发表了博客 “一种有效的Git分支模型”, 文章讲解了他是如何让自己的Git仓库保持整洁,除此之外,他发布了git-flow; 一个可以轻松实现该模型的Git扩展。 有同学说从来没有听说过?对此,哥表示相当震精,所以,在这篇文章里我要告诉你,为什么它可以让你从早上傻笑到晚上。 安装完git-flow后,你可以在当前目录下创建一个全新的仓库或把一个现有的仓库转换成新的分支结构: $ git flow init 它会问你一系列的问题,蛋定!尽量使用它的默认值就好了: No branches exist yet. Base branches must be created now. Branch name for production releases: [master] Branch name for “next release” development: [develop] How to name your … Continue reading

Posted in 技术, 软件 | Tagged , | 9 Comments

开始实践git-flow

关于Git-flow,在前几次的珠三角技术小沙龙的现场就听过朋友们介绍了,最近才有时间看看相关的文章: 《a-successful-git-branching-model》及《why-arent-you-using-git-flow》,才真正了解到,这真算得上是使用Git的最佳实践啊。于是马上想在自己的项目里用上。 安装Git-flow: 安装完后,试一下git flow命令,得到帮助: 升级已有Git Repo 使用git flow init即可,但结果是杯具的出错了。 原来是我的源码还没commit(unstaged),我先git commit -a ,把原来的改动提交掉。再git flow init,这一次成功了,git flow 帮我创建了两个主要分支,Master与Develop,以及询问我四个辅助分支的命名: 开始使用git flow 现在我要开始工作,为某个功能编写单元测试代码,那么,我只需要告诉git flow我要开始一个新功能的开发,输入git flow feature start sampler_test: git flow 会为我创建一个feature/sampler_test的分支并切换到该分支下,这时用git branch命令查看一下分支的情况: 有三个分支,当前工作分支是feature/sampler_test,我接下来所写的代码都只会影响该分支,直到我确认完成该功能(通过git flow feature finish sampler_test命令),完成后,代码会被合并到Develope主分支上面。 阶段性小结 git flow屏蔽了git的底层命令,向用户提供更高一级的命令用于完成源码的版本管理,流程模型看上去很好很强大,理论上也比较适合团队协作,因为比较规范和简单。我先自己尝试一番,体验过后再说是啥味道吧!

Posted in 技术 | Tagged , , | 4 Comments