问题描述
对使用Jenkins进行持续集成与使用git集成外部代码之间的区别有疑问。他知道Jenkins可以帮助他集成开发人员构建的所有代码。所以问题是：这个问题不是已经通过Github（或任何其他git工具）解决了吗？他可以运行git stash，git pull origin master和/或git stash apply来将其他代码与自己的代码集成。所以他认为自己对持续集成有所误解。他希望能够澄清这个问题。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
合并代码变更确实是由Git及其工具处理的。但是持续集成还包括对软件进行测试和构建。开发团队会不断获得有关其分支状态的反馈，以及测试、构建等是否失败的信息。
Jenkins提供了工具来实现这种反馈。通过在Jenkins中创建一个持续集成“流水线”，开发人员可以更好地了解构建的情况，超出了简单的Git合并和存储提供的功能。
方案2
使用脚本或工具来管理容器的启动顺序可能会增加复杂性，并且需要确保容器A和容器B之间的依赖关系正确设置。
持续集成使用Jenkins来处理代码集成，但这不是它的唯一作用。这可能是你所忽视的。
对于持续集成，您还将运行测试和构建步骤。但是，如果您没有测试（我强烈建议您使用测试），并且不需要构建阶段，git就足够了。
方案3
持续集成允许在软件构建和运行方面拥有一个“单一的真实位置”，以及系统环境依赖关系。
随着基础设施即代码的兴起，您当然可以说，好吧，我有git来放置我的Dockerfile，但这在某种程度上是没有意义的。
许多GitHub上的开源项目通过持续集成验证拉取请求的有效性，并进行双重甚至三重检查，即使只有一个CI系统也无法实现高质量。
方案4
软件集成有两个方面（无论是持续集成还是非持续集成）：
– 执行技术步骤以集成多个更改 – 这是您在基于git的环境中提到的内容
– 检查集成代码的质量 – 在传统的持续集成方法中，这是Jenkins和其他持续集成工具所做的事情
Jenkins本身不会执行技术集成步骤，据我所知，它无法做到这一点。它的操作仅在技术集成步骤完成后触发，通常由开发人员完成（在您的情况下，当您将更改git commit和git push到origin后）。
还有一种不同类型的持续集成工具，即门控提交工具，它实际上执行技术集成，对结果运行QA验证，并且仅在验证成功后将结果合并到origin。它们实际上完成了整个软件集成工作，因此能够保证最终结果中没有QA回归。
以上是关于持续集成与使用git集成外部代码之间的区别的解决方案。希望能够帮助你理解持续集成的概念。