代码之家  ›  专栏  ›  技术社区  ›  vrish88

哪些是最佳的SCM实践?

  •  5
  • vrish88  · 技术社区  · 16 年前

    我已经用Git管理自己的个人项目一段时间了。我真的没想过怎么用它。每当有一个里程碑没有真正思考时,我通常都会提交所有的变更。

    但是看完A blog post 上面提到了您应该如何纠正提交消息,我意识到我真的不知道如何正确地使用SCM。

    因此,我想知道您是否对以下方面有任何建议:

    • 你应该什么时候改变
    • 如何编写提交消息
    • 如何使用存储库与其他人协作
    • 别的。。。

    谢谢!

    9 回复  |  直到 16 年前
        1
  •  5
  •   obecalp    16 年前

    既然您使用的是Git,下面是我的一些做法,可能对您有用,也可能不适用:

    1. 总是在具有描述性名称的本地分支中工作,比如工作/特性名称(使用Git的Awesome Bash完成来帮助您键入)
    2. 在本地分支机构中,尽可能频繁地提交简短的评论(以记录提醒自己的意图),这样您就有了完整的原始思想/发展历史,可以返回。
    3. 在推送/发布提交/修补程序之前,从您的工作分支创建一个pu(建议的更新)分支(git checkout-b pu/feature_name),并使用git rebase-i进行完美的提交,即与组相关的小提交(和/或拆分大提交)到逻辑提交中,并编写有意义的描述(为他人和您自己),确保每个逻辑提交都符合逻辑提交生成并通过回归。
    4. 发布你的pu/feature_名称(或者让人们拉或者直接推到一个公共服务器,比如github)。
    5. 如果您有一个代码审查过程,那么您可能需要重复3和4几次。

    这听起来很复杂,但练习(至少对我来说)真的是一种乐趣,因为Git的速度非常快,而且在所有这些步骤中都感觉非常正确。

        2
  •  3
  •   Norman Ramsey    16 年前

    我知道有两种正当且常用的承诺权使用:

    • 细粒度提交,在早期提交的地方,经常提交,并以小块形式提交。系统在每次提交时可能不处于良好状态。这种做法的主要好处是,通过类似这样的系统,您可以非常清楚地了解发生了什么变化以及何时发生了什么变化。 darcs 或者像这样的命令 git-rebase 你有机会在“樱桃采摘”承诺你的兴趣。

    • 可靠提交,即只有当系统处于固态时才提交,例如,它不仅构建而且通过回归测试。

    在一个大型的团队项目中,一些可靠的方案是必要的,尽管您仍然可以在本地执行细粒度提交,并且只有在固态状态下才能将其公开。

    多年后,我一直观察到,大多数学生和其他初学者都害怕承诺,而且不经常承诺。对于我自己的项目,我倾向于使用细粒度方法,对于较大的项目,我通常至少有两个分支,对一个分支执行可靠的系统提交,对其他分支执行细粒度提交。

        3
  •  3
  •   janneb    16 年前

    其他答案很适合与多人使用的中央存储库一起使用。当我使用git时,我通常会为我正在处理的内容建立自己的私有分支,并且我倾向于做出很多小的承诺。在开发时,我发现这很有用,因为当我意识到我应该做些不同的事情时,我可以快速回溯,而且我还拥有一个关于我所做事情的相对详细的日志。

    然后,当我准备好向上游推进(即测试、记录等)时,我会作为一个提交进行推进,避免在中央回购中出现混乱。两全其美。

        4
  •  2
  •   Hank Gay    16 年前

    退房 Source Control HOWTO 来自埃里克·辛克。上次我看的时候,它主要集中在集中的风投上,但是里面仍然有很多好东西。

        5
  •  2
  •   htanata    16 年前
    • 尽早承诺,经常承诺。
    • 保持小承诺。如果提交量很大,请尝试在有意义的地方将其分解。
    • 不要破坏代码。每次提交都应该使代码保持工作状态。
    • 尝试在提交消息中包含意图,而不仅仅是“什么”。
    • 不要注释代码。改为移除它们。
    • 使用分支进行实验性或潜在的代码破坏更改。
    • 标记您的发货版本。
        6
  •  1
  •   Kyle Walsh    16 年前

    我通常在添加新特性后提交,或者在文档化的bug修复完成后提交。基本上,一次一件事。这使得回滚更改更容易。

    至于提交消息,我将列出为新功能添加的功能。对于bug修复,我从bug数据库中包含bug的ID。

        7
  •  1
  •   Brimstedt    16 年前

    在处理一个小的个人项目时,可能不那么重要,因为你知道你的代码,你记得你做了什么,大概什么时候做了等等——至少我知道。

    但是对于拥有许多开发人员的大型项目,IMO必须

    • 始终指定问题编号(可使用任何好的SCM强制执行)
    • 减少提交次数
    • 只提交工作代码
    • 只提交比以前更好的代码
    • 提交干净的代码(即不要留下测试代码、旧的注释代码等)
    • 不仅要写“固定问题X”作为注释,还要说明关于错误/更改的更多信息,例如“固定问题X,面板将扩展到窗口大小之外”。

    当您查看已更改文件的历史记录,并试图找出某个特定问题出现的时间时,好的注释将帮助您更快地找到正确的提交。

    通过减少提交次数,检查与新功能相关的更改、恢复“功能”或将其合并到其他树中也会更容易。

    /B

        8
  •  0
  •   Gordon Thompson    16 年前

    当您提交一个变更时,请确保代码是构建的,并且基本上是功能性的。提交破坏构建的代码是不好的形式。如果您在团队环境中工作,没有什么比签出最新的代码来发现它破坏了应用程序甚至不编译更糟糕的了。

    关于注释,请对代码的作用和理想的实现原因作一个粗略的描述。这使您能够在不必读取代码的情况下了解签入的功能。

        9
  •  0
  •   Richard Slater    16 年前

    对于个人项目,我倾向于尽可能频繁地提交,一个小时可以提交几次,因为这样当我意识到自己走错了路时,我就可以及时返回到以前的“快照”。

    对于多用户项目,这将取决于规则,在达到这些目标之前,您不能提交一些东西。就我个人而言,当我可以沿着“修复此票据”或“实现此功能”的行写评论时,我倾向于提交。

    至于评论,我放了一个更改摘要,或者一个通知单或wiki参考。代码和差异应该有足够的文档记录以提供详细信息。

    推荐文章