1

我有以下情况：

一个内部服务器（server1），主 repo 有 2 个分支master和dev，四个开发人员有 3 个 git 克隆，使用dev的分支

规则：

  1. 开发人员无法触及或合并 server1/master
  2. 每个开发人员在工作前和推送前都需要更新 server1/master 的版本

我考虑了这个过程：开发人员 1 必须做：在git clone和也许git pull之后，每天都会是这样的：

git checkout dev
git pull (for synch every modification from other developers)
git checkout -b myModification (for making a branch from dev)

修改后添加并提交：

git checkout dev
git merge --no-ff myModification
*git pull (for fetching  modification in dev made in the meanwhile from others developers)

在开发分支上测试后：

git push origin dev

我想知道

  1. 我的问题的最佳工作流程定义是什么
  2. 每个开发人员的 git 命令是什么
  3. 如果git pull是正确的或者最好有git rebase -i dev或者改变这个命令的位置

先感谢您

4

3 回答 3

0

对于第 1 点：对我来说，它看起来像是一个典型的主题分支工作流程，总的来说是一个非常好的主意。

对于第 2 点：开发人员需要了解并理解此工作流程的基本 git 命令集：branch、、、、。pull (--rebase)commitmerge

如果您更改工作流程以使开发人员在将他们的主题重新合并之前引入最新的更改集，dev那么您有可能rebase在常见情况下避免。唯一的例外是在此期间没有人推送新的更改dev，那么 agit pull --rebase就变得必要了。这应该解决第 3 点。

我还将通过以下方式修改规则：永远不要直接在dev. 您真正想在此分支上看到的唯一内容是合并。为什么？所以git log --first-parent dev给你一个很好的关于你的历史的高级概述。

于 2014-02-25T17:12:15.020 回答
0

对于小型商店来说，这不是一个糟糕的工作流程，您相信每个开发人员都会检查服务器上的 dev 分支。这基本上是我在家里做的。

一个更常见的工作流程是让开发人员将他们的更改推送回一个特殊的“review”分支：

git push --dry-run origin dev:refs/heads/falk/dev
(satisfied this won't make a mess)
git push dev:refs/heads/falk/dev

然后我会要求项目管理员将falk/dev分支合并到dev分支中。

如果你有足够多的开发人员，他们中的一些人可能会搞砸，项目管理员会设置权限，这样开发人员就不能直接推送给开发人员。

通过调整权限和 git 挂钩，您可以安排在完成合并之前需要一个正式的代码审查过程。

最后，这整个事情可以通过使用 Gerrit 来管理主存储库来自动化。不过，管理这些东西远远高于我的工资等级。

好的，回答您的具体问题：

1,2。您的工作流程应该按照您编写的方式工作，尽管我个人通常不会费心创建“myModification”功能分支，因为它只存在于本地工作区中，而且无论如何它都是临时的。您的开发人员可能会开发自己的风格。

所以我自己的工作流程看起来像：

# start work, pull in any remote changes first
git checkout dev
git pull
(work)
# sync up again, just in case
git pull
git push origin dev:refs/heads/falk/dev
(ask administrator to do the merge)

git pull是您要使用的命令。它可能会导致冲突，开发人员必须手动解决。

git rebase在推入或拉入其他存储库时可能会给您带来麻烦，因为它实际上会修改分支结构。您应该只在自己的本地工作区中使用git rebase 。将分支推送到另一个存储库后，您应该考虑将分支结构“锁定”并且不再对其进行修改。否则，你下次推送的时候会给服务器带来问题，而其他开发者尝试拉取的时候也会给服务器带来问题。

于 2014-02-25T16:58:11.710 回答
0

也许您应该四处寻找 git 工作流程的示例，例如Atlassian中的示例。Trenches 书中的git可能很有用，它讨论了一些与您的设置不太一样的虚构设置（以及它如何出错）的示例。并且不要忘记阅读git book。

git 的一大优点是创建和操作分支既便宜又容易。在一个分支上工作并将其合并到另一个分支上，或者将其嫁接在上面，几乎没有风险。切换分支很容易。一定要利用这一点。让开发人员随心所欲地工作（他们家用机器上的一个分支或十几个分支都没有关系，这是一个私人决定）。

坚持每次提交都是一个单一的逻辑更改（而不是“放弃一天的工作，明天继续”）。了解如何进行一系列更改（包括回溯、死胡同、不合逻辑的更改）并从中创建干净、结构化的提交历史记录。坚持清晰、有意义的提交信息。

我会采取一个不太重要的项目（也许是一些“很高兴拥有”）来进行一些实验。尤其是如果您习惯了另一个 VCS，那么使用 grok git 需要花费一些时间。学习如何创建分支和标签，了解git stash，你迟早会做错事，并且养成为我搞砸的情况设置后备的习惯已经救了我几次......

于 2014-02-25T17:57:29.377 回答