标签: git-workflow

我正在向我的高层阶段出售git.无论如何,他们正在听我们谈论它.有一点我不确定,我想看看人们如何处理这件事.基本上我的问题来自于基本的理解,即允许一对分支越远,它们就越难合并.

我正在考虑提出这个相当简单的工作流程:假设我有一个主(发布)分支,一个开发分支,以及主题分支.不同的开发人员正在研究他们各自的主题分支,将这些主题分支拉到中央仓库并将其推送到中央仓库,因为他们认为自己有工作代码.定期,当开发人员要求这样做时,维护者(在我们的组织中,该人员具有"技术主管"头衔)从他们的功能分支合并到开发分支中,将其放在登台服务器上并进行测试,并且一旦功能完成测试完成后,它与master合并并推向生产.

这是我的问题.开发者应该定期合并他们的主题分支吗？这样做可以确保他们所有人都可以相当干净地合并回dev(或者至少在他们失控之前抓住冲突).我知道我的经理唯一不喜欢的就是,他们必须做的工作是安抚他们的工具,而不是努力为项目提供代码.思考？

我正在与一个刚接触git的开发人员合作,我想设置一个git工作流,让我审核这个开发人员的提交(并可能拒绝他们)而不强迫他改变他的工作(这很容易出错)对于新用户).

这是场景:

• 该master分支仅包含经过审核的代码
• devel分支是由分支master分支创建的
• 开发人员正在devel分支机构上工作并推送他的代码供我审核
• 我发现他的代码存在一些问题,所以我请他在devel分支上做更多的提交以解决问题
• 一旦我对代码感到满意,我会挑选(或合并壁球)开发人员在master分支上提交,添加我自己的注释并将提交标记为开发人员编写的
• 开发人员将master分支合并回他的devel分支

以下是此方案的直观说明:

在这个序列之后,如果开发人员在其他一些提交之后再次推送他的分支,我怎么能100%确定开发人员在"犯错/重做"序列期间犯的错误不会再出现devel？

最好的解决方案是让开发人员devel反对他的分支master,但这对新git用户来说是一项艰巨的任务.

如果这个工作流程有任何错误,请建议我另一个我可以在将它们合并到主分支之前审核提交的地方.

编辑

一位朋友向我建议了一个看起来很有希望的方向:提交时的--fixup选项.

--fixup=<commit>

构造一个用于的提交消息rebase --autosquash.提交消息将是指定提交的主题行,前缀为"fixup!".有关详细信息,请参阅git-rebase.

开发人员可以使用此选项将第二次和第三次提交正确标记为第一次提交.探索的好方法......

我们正在使用安装在Web服务器上的git进行开发,我们在public_html目录之外放置了一个简单的.git项目,然后我们将master分支克隆到public_html中的目录.这允许我们推送到主分支而不用担心已经检出的分支的错误.

我们有了这个想法(并且已经检查过,到目前为止工作得非常好),我们可以在修复主分支并再次拉动时将各个提交头检查为快速回滚.在执行此操作时,我们需要了解任何已知的缺点或安全问题吗？

我正在尝试将git-flow应用于具有多个共享相同代码库的网站的项目.

我目前使用许多功能分支,一个开发分支,一个支持分支和许多生产分支:每个站点一个,因为每个站点都定制了一些配置文件.

git flow工具不提供许多主/生产分支,而是单个分支. 我能做什么？

所以我对我目前的GIT工作流程(我是新手)的意见感兴趣,以及如何确定哪些更改尚未合并/推送到相应的存储库.首先,我当前的系统看起来像这样:

      remote.master
            |
            |
            V
      local.master
   |       |       |
   V       V       V
 branch  branch   branch

对于新任务,我会从remote.master拉到local.master,创建一个新分支并检查它.我会在完成任务时做各种提交,也许会切换到其他任务,然后在准备好之后,将从remote.master拉到local.master,将我的分支合并到local.master,最后推送到remote.master.

所以2个问题:对于一个小团队来说,这是否有点过分？省略本地分支是否更有意义？如果是这样,一些建议表明存在"快速转发"问题(我理解它使remote.master中无法区分的更改)或者过多的具有潜在意外时间戳并且难以解析的提交.

2,假设上述工作流程:我有时会经常在任务之间切换.我想要一个显示我的屏幕:

'branch 01' -> partially merged to local.master 
'branch 04' -> notmerged to local.master 
'local.master' -> partially merged to remote.master

如果各种功能已合并到哪里,我会忘记它.我绝对不想逐个分支,并尝试通过'git diff'或其他命令来判断这些信息.我目前在Windows上使用Tortoise GIT,但我对其他图形替代品持开放态度.我有时会使用shell,但更喜欢用户界面.有没有办法获得这些信息？

我最近在我的git merge策略中犯了一个错误,并且在我已经继续处理该项目并做了更多提交之前没有注意到结果错误.为简洁起见,假设我有两个分支,hotfix并且new_feature.我做了类似以下的事情:

git checkout new_feature
git commit -m "Commit to the feature branch"
git checkout hotfix
git pull origin new_feature # Uh oh, I pulled the wrong branch!
git commit -m "Commit to the hotfix"
git push origin hotfix # Uh Oh, pushed the bad merge!

在上述事件之后,其他开发人员也提交了Hotfix分支.现在,我们有一个我们想推出的修补程序,但不能,因为它包含不完整的功能工作.

我已经看到很多关于这种情况的类似问题,但没有一个匹配100%(大多数都涉及在糟糕的拉动之后直接撤销提交,而不是先推动.我已经更进了一步,并且真的搞砸了.

有关如何解决此问题的任何分步指南？

谢谢!

编辑:许多其他答案提到git reflog,所以这里是我的修改副本.我已经更改了哈希和分支名称以匹配上面的示例.

aaaaaaa HEAD@{0}: checkout: moving from new_feature to hotfix
bbbbbbb HEAD@{1}: checkout: moving from hotfix to new_feature
aaaaaaa HEAD@{2}: commit: Added analytics …

我正在与主人一起工作(与其他人一起).

A - B - C - F - G    (master)
         \
          D - E      (branch-a)

我们会定期将master合并到分支中,以便以后最大限度地减少冲突.

A - B - C - F - G    (master)
         \       \
          D - E - H  (branch-a)

最终,我们将要合并回来.

A - B - C - F - G - I - K - M - N  (master)
         \       \       \     /
          D - E - H - J - L - O    (branch-a)

什么是我可以合并回主人最干净的方式？

1. 我想保留个人提交(即没有壁球)
2. 我将不再使用branch-a,因此提交哈希值可以改变.
3. 如果可能的话H,我想不包括合并提交(例如 …

我在不同的文章和 stackoverflow 问题中迷失了方向，无法集中精力找出 GIT 的命令。这是我想要做的

• 我使用 eclipse Git 从 master 创建了分支。
• 我切换到那个分支
• 做了我的改变

现在，我想

1. 在本地提交更改（`git commit -m "comment"'）
2. 推送到存储库作为 的分支，Master以便我可以创建pull request. 一旦 pull 获得批准，它将merged进入 master。但是我如何将我的本地推送到上游，以便创建分支并且我可以发出拉取请求？

我们正在使用git来跟踪开发和版本化版本,并遇到了一些合并分支的问题.这是我们的工作流程:

production/1.0.0  A--B

stage/2.0.0       A--B--C--D

development       E--F--G--J--L
                         \
feature                   H--I--K

功能开发发生在从开发创建的功能分支上,并在准备好时合并回来进行演示和测试.

这一切都运行良好,问题是创建该功能分支的开发人员将他们的功能放入阶段分支进行部署.因为它们在G开发时分支,当它们合并时,它包括EFG,当他们只想合并HIK时.

我们的git工作流的目标是让开发人员标记他们自己的代码以备发布,并协调整个开发分支将能够合并到部署分支是不可行的,因为开发在世界各地发生.

是否有一个git命令来合并在功能分支上进行的提交？我知道rebase和cherry pick,但是一个功能可以由大量的提交组成,其中包括开发追赶其功能分支的合并.有更好的解决方案吗？

这个工作流程正确吗？我们是在尝试做一些不可持续的事情吗？

上下文: 我们是一个程序员团队,负责一个有多个分支的项目:

Master, Release, Develop

有时我们需要修复发布时的错误,我们需要在开发时报告此修复,报告我们使用的错误修复: git cherry-pick commit-SHA

使用此命令可以很好地报告bug修复,但提交有不同的哈希值

我们需要的 :

有时我们需要知道尚未报告的提交列表,为此,我们使用比较两个分支的命令,并向我们提供发布中存在但不在开发中的提交列表: git log develop..origin/release

问题 :

这个命令比较了提交的哈希值,但正如我之前所说,当我们报告我们的提交时,它们的哈希值会发生变化,因此,我们会得到一些提交,好像它们没有被报告一样

我正在寻找一种方法来报告我们的错误修复而不改变提交的哈希,或者列出两个分支之间的提交差异的方法,而不是通过哈希但是基于消息或其他事物

谢谢