问题标签 [git-workflow]

在使用 Gitflow 时，将分支命名分为功能、错误修复和修补程序的原因是什么？

即为什么不只是，例如，而不是：

做就是了：

按功能/错误修复/修补程序分开有什么好处？

我们的 git 存储库通常包含我们整个网站和服务的代码。这包括所有用于营销、法律、用户界面等的精心措辞的文本。

本质上，一个流氓开发者可以克隆它，改变一些东西，并成为我们的竞争对手（除了所有法律问题）。或者更有可能的是，他们经常会在未经授权的情况下将其他人的工作作为他们自己的工作包括在他们的投资组合中。在某些情况下，这会导致我们不想要的特性和功能的早期披露。

无论如何，这已被认为是一种风险，因为我们偶尔会与全球各地的开发人员合作，并且需要尽快添加更多内容——授予他们访问他们将使用的整个代码库的权限。

你有没有遇到过这个问题？或者已经实施了减少或减轻类似风险的解决方案？

我在想一种潜在的策略可能是创建 3 个具有不同目的（而不是分支）的单独 git 存储库，但如下所示：

Git 仓库：Project1_DEVELOPERS

上面的工作流程：基本上是问题/功能分支样式。开发人员被委派了一项任务，将其作为问题/功能分支进行检查。完成后，将该分支和合并请求提交到开发分支。如果可以，我们测试分支并合并到 dev。

以上基本上就是我们今天做事的方式。而已。整个 repo 在发布到世界时都在“master”中。

但是为了实现既定目标，我正在考虑添加类似...

Git 仓库：Project1_OBFUSCATE

和生产回购...

Git 存储库：Project1_PRODUCTION

就问题的内容而言，将简单的网页想象成回购...

因此，我的目标是从“开发人员”存储库中的分支中剥离或修补带有虚拟徽标的真实/假“logo.png”。

在实践中，可能不仅仅是一个 logo.png，它可能是一堆 .blade 文件（Laravel） .twig 文件或任何可能包含我们希望限制访问的内容位的模板文件。在某些情况下，这些文件可能只存在于“OBFUSCATE”远程中。

有没有人做过类似的事情，可能会分享一些见解？

以我建议的方式考虑这样做让我很头疼，甚至可能行不通:)

我有project1和project2. project2是从project1无意合并回来的（它现在是一个单独的产品）。

现在，我介绍了一些project2我想有选择地移植回project1. 我应该将project2's repo 添加为遥控器project1吗git cherry-pick？或者我应该使用git format-patch后跟git am？

有问题的功能非常复杂，在项目分歧后已经通过多次提交实现。

有3个分支：

1. master= 生产部门
2. feature_1= 基于分支master
3. feature_2= 分支取决于feature_1

feature_1完成后将分支合并到主控的正确方法是什么？通常我使用变基，但在这种情况下，它会引发很多冲突，因为feature_2分支不断合并以feature_1保持同步（因为它会更改feature_1分支中的所有提交哈希）。

使用常规合并是唯一的选择吗？

或者对于这种类型的工作流程可能有更好的方法？

还有一个后续问题：

1. master- 包含feature_1
2. feature_1- 完成并合并到主人
3. feature_2- 依赖并同步feature_1
4. feature_3- 新分支依赖于feature_1和feature_2分支

开始使用分支的正确方法是什么feature_3？

提前致谢！

我浏览了类似的问题，但找不到合适的答案。

我有一个需要用于每日报告的脚本。是否可以将我的代码托管在单独的目录/存储库中，并且仅将主要更新“推送”到该目录/存储库以获得最大的正常运行时间？

现在，我在脚本所在的目录中工作，所以从我签出一个 dev 分支到我返回 master 时，脚本都被破坏了。

例如，我想将工作文件保留在一个仅获取主要更新的目录中：

然后有另一个目录用于增量开发，允许主目录保持不变，直到新的主要更新准备好上线：

这可能吗？

所以管理层在 Git 上出售。我们目前使用 Perforce 并将变更列表从阶段合并到发布分支，当它们准备好时。我们当前工作流程的优势是我们可以选择哪些功能用于生产，而不必担心发布周期。一经测试，一切顺利。

使用 Git，我们的工作流程将是开发人员在 dev 分支或他们自己的分支中工作。然后，他们将更改合并到阶段（测试）分支以供 QA 测试。
一旦 QA 完成测试，PM 将希望将这些更改合并到发布分支并部署到生产。诀窍是我们可能在 Stage 分支中测试了 10 个东西，只有一个准备好合并到 Release。

我知道合并整个 Stage 分支来发布很容易，但这永远不会发生。同样使用 Git 樱桃选择是可怕的，如果我们不能按分支合并，那么使用 Git 没有多大意义。在perforce 中，我们将changlelists 从stage 合并到Release。

我们如何在 Git 中做到这一点？
能给我举个例子吗？

我在一家产品开发公司工作。我们有一个在 MEAN 堆栈上开发的 CMS 应用程序，我们使用 Jenkins CI 进行自动化部署。我们使用 github 来托管我们的代码。

我们从客户那里收到实施新功能的请求，这些功能应该只有我们才能提供给请求它们的客户，因为这些功能旨在定制应用程序以满足他们的特定要求。我们也可能会自行推出新的功能/修复程序，所有客户都可以使用。

哪种工作流程最适合上述场景，以确保开发过程和发布周期顺畅。

管理 git 非常困难。我的问题：

假设我有一个项目，并且有名为“ master ”和“ develop ”的分支，并且说Mary在一个名为“ feature-payment ”的功能分支上工作（这个分支是从 master 创建的）， mary完成了“ feature- ”上的工作支付”分支然后合并并推送到开发分支。

然后john将开发分支拉到他的本地。然后他想做一些CSS部分。由于他没有功能分支，他必须在开发分支上工作。然后他进行更改并完成样式并推送开发分支。

当该功能准备好上线时，mary将她的分支合并到master，但 john 无法将develop合并到master，因为 develop 分支上有多个未上线的功能。在这种情况下，伙计们应该怎么做？？请帮助指导我进行分支工作流程..这个问题每次都会发生在我身上。:(

我知道标题有点笨拙-因此引用了！

假设我有一个分支，b_feature它是从主开发分支分支并合并到其中的b_master。存在另一个分支，b_release我希望将这些更改添加到（作为点发布）。b_master并且b_release已经分道扬镳，永远不会再合并。

我知道我可以挑选整个事情作为一个单一的差异git cherry-pick -m Mm，给

whereSquashed是一个提交，包含功能的所有更改，并带有 merge 的消息Mm。

但是，如果我想保留更改历史记录和单个提交消息怎么办？我总是可以用这个近似的工作流程手动挑选：

但这对于我不知道的更优雅的解决方案来说似乎是一个笨拙的解决方法！

rebase --onto b_release Bm Mm似乎也没有产生我正在寻找的结果。

有什么更好的方法吗？

我想知道是否已经可以从 GIT 中给定分支的给定文件中获取给定范围的行？我正在做一个相当大的项目，在切换到新分支后重新加载整个解决方案持续几秒钟，但有时我需要从例如 master 中查看当前文件的历史记录/版本。是否可以不切换到master？