问题描述

这是关于 Splunk Phantom 剧本代码部署的。

每当我们创建一个新的剧本时，它都会在存储库中为每个剧本创建两个文件（.json、.py）。我们有 3 个不同的分支与一个存储库（DEV、QA、PROD）相关联。

在我们的 DEV 分支中，开发工作将继续进行，它有大约 300 个文件（JSON 和 Python 文件，这意味着 Phantom 开发 GUI 中有 150 个剧本）。

现在，我不想将所有这些文件合并到我的 QA 中，我只需要一些在 DEV 中发生更改的文件需要推送到 QA（因为在 DEV 中的 300 个文件中，我们在 QA 中有大约 160 个文件相同代码）。

当 DEV 文件发生任何更改时，我必须选择那些特定文件并提出拉取请求然后合并（这意味着只有那些在 DEV 中发生更改的文件才应该移动到 QA {kinda Cherry-picking}）。

我遵循了以下过程，但我遇到了合并冲突。

过程：

创建一个新分支
```
git checkout -b branch_name
```
删除此分支的所有文件
```
git rm -rf .
```
提交更改
```
git commit -m "create new branch" 
```

从主分支检索一些文件

git checkout master -- file1 file2 file3 file4

提交更改
```
git commit -m "create new branch" 
```

完成此过程后，我导航到我的 VSTS UI，并在我在第 4、5 步完成的“提交”上应用樱桃选择（我能够在执行樱桃时成功地使用所需文件创建提交-选择，我遇到了问题）。

下面是我尝试进行樱桃挑选时的屏幕截图 - 错误消息如下所示：

There were conflicts when cherry-picking commit 60625f. This operation needs to be done locally

标签： gitsplunkgit-cherry-pick

解决方案

tl;博士

如果您发现自己使用cherry-pick或rebase -i每次都想通过 Pull Request 促进更改，那么您的流程和工具配置是错误的。

考虑使用功能分支

从主干 ( ) 延伸的功能（或主题，如果您阅读 git scm 书）分支master是集中且一次性的。这种模型不仅使拉取请求和发布更容易理解，而且比在适当的时间以适当的节奏保持 2 或 3 个生命周期分支同步和不同步更容易管理。

对需要进行版本控制的内容如实

在存储库的一个生命周期分支中拥有永远不会被带入其他生命周期分支的文件强烈表明这些文件实际上不需要受版本控制。虽然这些文件可能是开发您的产品所必需的，但它们显然并不代表您可交付成果的真实部分。这正是该.gitignore文件存在的原因。设置您的.gitignore文件以允许这些文件存在于工作空间中而不会被跟踪。

正确实施.gitignore文件应该首先消除使您陷入合并冲突的工作的需要，并且使用一个生命周期分支而不是 3 个生命周期分支的功能分支将使您的团队实施 DevOps 实践的其他一切变得代码更容易理解和维护。

照这样说...

修复本地解决合并冲突的一般问题

这些建议假设您的 PR 正试图将更改branch_name从origin\QA

Azure devops（以前称为 VSTS）要求您在本地解决合并冲突并将这些更改推送到您的 PR。

在您的第 5 步之后，您需要来自远程的 PR 目标分支（我猜是 QA）的本地副本origin（通常在您的本地仓库中标识）。

完成后，返回branch_name并运行git merge localQA. 这应该向您表明，由于冲突而无法完成合并。现在您需要打开git status未添加到索引中的文件并更正冲突。当文件冲突得到纠正后，您可以提交合并和推送。

对您当前的情况采取不同的方法

不要删除 master 中的所有文件branch_name并checkout有选择地从 master 中删除，我假设它代表origin/DEV. 相反，branch_name从最新的本地副本中删除您的origin\QA. 这将使您开始使用所需文件的 QA 副本。然后，您可以从该分支将这些git checkout master -- fileA etc.更改重写到您的 QA 副本中。现在您可以将 QA 副本推送到origin并创建 PR。

如果您精明，您可能已经注意到，这种做事方式与拥有一个使用 PR 从特性分支获取更改的单一生命周期分支 (QA)完全一样。这是因为来自 DEV 的提交实际上并没有从 DEV 中取出。

当您使用时，git checkout <tree-ish> -- [pathspec]您不会移动提交，而是移动更改。例如..

假设我有一个分支并为一些更改 master创建一个分支并添加一个文件。test

现在，如果我创建一个新分支并使用它，checkout <tree-ish> -- [pathspec]您会看到它正在创建一组新的更改供我提交。

在我如何使用版本控制的示例中，如果master代表你的origin/QA和test代表，如果我要在代表中所做的更改上创建新的提交origin/DEV，我为什么还要打扰分支呢？我（你）不应该。testnewTesttest

另一种选择

git rebase -i在您的分支上使用以拆分提交，以便您要忽略的文件在您可以忽略的提交中。使用这种方法，您仍然应该从origin/QAPR 目标或任何您的 PR 目标创建分支。然后，您可以cherry-pick在开发分支中使用您想要的提交，并在此分支和目标之间使用 PR。

理解：以这种方式使用 Rebase 就是重写你的分支的历史。有些人会认为这是不明智的，所以请确保您知道自己在做什么

git - 将我需要的文件从 DEV 分支合并到 Azure VSTS 中的 QA