git 中没有 CVS 样式合并更改？使用 VSCode 和 Gitlens。我只想保留或忽略冲突中的更改
No CVS style merge changes in git? Using VSCode and Gitlens. I just want to keep or ignore changes in a confict
这感觉像是一个我应该能够找到答案的问题，但我似乎找不到一个，我想我读过的很多帖子实际上是想问我将要尝试解释的内容。我正在使用 VSCode，如果重要的话我有 Gitlense。
我以前是 CVS 用户。我更喜欢 git... 除了合并更改。我可能被 CVS 图形用户界面之类的东西宠坏了：
当我进行了不同于我的 CVS 存储库中的本地更改时，我能够像 git 一样查看差异：左侧是存储库副本，右侧是我的工作副本。完全有道理。 diff 中的行标记不同（我能够找到的问题），但我真正想念的是单击更改并将其移动到工作副本或忽略它的能力。合并这些更改后，我可以检入更改后的文件。
在 git 中，我发现的是...首先，如果我有本地更改，我将无法拉取。我必须把它们藏起来，拉动，然后弹出，然后差异。我可以查看我熟悉的差异。然后，如果我看到更改，则不允许我在 diff 工具中修改我的工作副本。我必须从 diff 复制，转到我的工作副本，粘贴更改，返回 diff 并继续逐行滚动。
我缺少什么工具或步骤吗？我只想单击一个按钮并将更改移至工作副本。我可以接受 stash 然后 pop，但每次都这样做似乎有点傻。
刚才我不得不存储 20 多个文件，提取了一大堆文件，我正准备执行存储弹出操作并让自己花一天时间合并更改。有没有更简单的方法？
首先，CVS 和 Git 都没有单一的标准 GUI，因此对“点击”的引用表明部分区别不在 CVS 和 Git 之间，而是在 GUI 工具之间你用过。 Git 有许多 GUI，以及与 IDE 的集成，质量和复杂性各不相同。所以，对于那部分，真正的问题可能是“我如何找到更好的 Git GUI？” （答案是四处寻找你喜欢的外观并尝试一下。）
其次，git 更加强调 提交和分支 ，而不是 文件和更改 。 git 中的分支 便宜 ，而且每天都创建新分支很常见。
因此，您描述的本地和远程更改过程通常在 git 中通过多个分支进行管理，并在它们之间进行合并：
- 您创建了一个分支“feature-123”，并随时提交您的更改
- 您的同事创建了一个不同的分支“feature-456”。
- 您的同事先完成，然后将“feature-456”合并到共享分支（例如“main”、“master”或“develop”）。
- 要获取他们的更改，您首先要提交您目前拥有的内容，然后使用“git pull”来merge 共享分支（“main”/“master”/“develop”）到你的工作分支（“feature-123”）。
- 此时，您会看到两个分支之间的冲突，解决它们，然后提交结果。
您可能偶尔会在第 4 步使用“stash”而不是“commit”，但这是例外而不是规则。
您可能也更喜欢使用“rebase”而不是“merge”，但结果是相似的。
关键是两个人很少直接提交到同一个分支。每个开发人员提交他们自己的分支，并以某种方式共享它——通常在某些中央服务器（如 Github、GitLab、BitBucket 等）上使用“拉取请求”或“合并请求”。
让我给出一个更以 CVS 为中心的答案。
所有其他答案（到目前为止）都是正确的。但是来自 CVS 背景，有时被告知“你做的不对”是有帮助的，有时则不是那么有用。
@IMSoP 关于 GUI 的评论 100% 正确。 CVS 是一个命令行工具。 Git 是一个命令行工具。它们每个都有可用于解决冲突的 GUI。一些 GUI，如 meld 或 kdiff3 可以在 CVS 或 git 中使用。您需要研究最适合您的工具。
您确实可以像以前一样继续工作。您编辑文件，并定期 git pull 来自上游，这些上游提交要么自动无缝地拉入您的工作区，要么您有冲突需要解决。
以下配置将为您设置。
git config pull.rebase true
git config rebase.autoStash true
如果您正在处理经过编译的代码，这可能会出现问题，因为您突然重新touch编辑了您工作区中所有修改过的文件，并且您的构建系统（例如 gnu make）可能会看到它们已更改并导致重新编译。在这种情况下，您可能想要创建一个包装器脚本（也许将其称为 git-up (*) 以镜像 cvs up 以找到所有已修改的文件，记下它们的时间戳、存储、拉取、弹出存储，以及使用旧时间戳重新修改您的文件对于所有未从传入更改中更新的文件。
要获得更详细的解释，我建议您阅读 。
(*)：如果你把 git-up 放在你的路径中，它可以像任何 git 命令一样被调用为 git up（没有破折号）。 Git魔法。
这感觉像是一个我应该能够找到答案的问题，但我似乎找不到一个，我想我读过的很多帖子实际上是想问我将要尝试解释的内容。我正在使用 VSCode，如果重要的话我有 Gitlense。
我以前是 CVS 用户。我更喜欢 git... 除了合并更改。我可能被 CVS 图形用户界面之类的东西宠坏了：
当我进行了不同于我的 CVS 存储库中的本地更改时，我能够像 git 一样查看差异：左侧是存储库副本，右侧是我的工作副本。完全有道理。 diff 中的行标记不同（我能够找到的问题），但我真正想念的是单击更改并将其移动到工作副本或忽略它的能力。合并这些更改后，我可以检入更改后的文件。
在 git 中，我发现的是...首先，如果我有本地更改，我将无法拉取。我必须把它们藏起来，拉动，然后弹出，然后差异。我可以查看我熟悉的差异。然后，如果我看到更改，则不允许我在 diff 工具中修改我的工作副本。我必须从 diff 复制，转到我的工作副本，粘贴更改，返回 diff 并继续逐行滚动。
我缺少什么工具或步骤吗？我只想单击一个按钮并将更改移至工作副本。我可以接受 stash 然后 pop，但每次都这样做似乎有点傻。
刚才我不得不存储 20 多个文件，提取了一大堆文件，我正准备执行存储弹出操作并让自己花一天时间合并更改。有没有更简单的方法？
首先，CVS 和 Git 都没有单一的标准 GUI，因此对“点击”的引用表明部分区别不在 CVS 和 Git 之间，而是在 GUI 工具之间你用过。 Git 有许多 GUI，以及与 IDE 的集成，质量和复杂性各不相同。所以，对于那部分，真正的问题可能是“我如何找到更好的 Git GUI？” （答案是四处寻找你喜欢的外观并尝试一下。）
其次，git 更加强调 提交和分支 ，而不是 文件和更改 。 git 中的分支 便宜 ，而且每天都创建新分支很常见。
因此，您描述的本地和远程更改过程通常在 git 中通过多个分支进行管理，并在它们之间进行合并：
- 您创建了一个分支“feature-123”，并随时提交您的更改
- 您的同事创建了一个不同的分支“feature-456”。
- 您的同事先完成，然后将“feature-456”合并到共享分支（例如“main”、“master”或“develop”）。
- 要获取他们的更改，您首先要提交您目前拥有的内容，然后使用“git pull”来merge 共享分支（“main”/“master”/“develop”）到你的工作分支（“feature-123”）。
- 此时，您会看到两个分支之间的冲突，解决它们，然后提交结果。
您可能偶尔会在第 4 步使用“stash”而不是“commit”，但这是例外而不是规则。
您可能也更喜欢使用“rebase”而不是“merge”，但结果是相似的。
关键是两个人很少直接提交到同一个分支。每个开发人员提交他们自己的分支，并以某种方式共享它——通常在某些中央服务器（如 Github、GitLab、BitBucket 等）上使用“拉取请求”或“合并请求”。
让我给出一个更以 CVS 为中心的答案。
所有其他答案（到目前为止）都是正确的。但是来自 CVS 背景，有时被告知“你做的不对”是有帮助的，有时则不是那么有用。
@IMSoP 关于 GUI 的评论 100% 正确。 CVS 是一个命令行工具。 Git 是一个命令行工具。它们每个都有可用于解决冲突的 GUI。一些 GUI，如 meld 或 kdiff3 可以在 CVS 或 git 中使用。您需要研究最适合您的工具。
您确实可以像以前一样继续工作。您编辑文件，并定期 git pull 来自上游，这些上游提交要么自动无缝地拉入您的工作区，要么您有冲突需要解决。
以下配置将为您设置。
git config pull.rebase true
git config rebase.autoStash true
如果您正在处理经过编译的代码，这可能会出现问题，因为您突然重新touch编辑了您工作区中所有修改过的文件，并且您的构建系统（例如 gnu make）可能会看到它们已更改并导致重新编译。在这种情况下，您可能想要创建一个包装器脚本（也许将其称为 git-up (*) 以镜像 cvs up 以找到所有已修改的文件，记下它们的时间戳、存储、拉取、弹出存储，以及使用旧时间戳重新修改您的文件对于所有未从传入更改中更新的文件。
要获得更详细的解释，我建议您阅读
(*)：如果你把 git-up 放在你的路径中，它可以像任何 git 命令一样被调用为 git up（没有破折号）。 Git魔法。