<p>Merging code changes is definitely handled by Git and its tools.  But Continuous Integration also includes <strong>testing</strong> and <strong>building</strong> the software. The development teams are provided with constant feedback on the status of their branch(es) and whether they are failing tests, builds, etc.</p>

<p>Jenkins provides the tools to enable this feedback.  By creating a CI "pipeline" in Jenkins the developer gain much better insight into the build, beyond what simple Git merges and stashes provide.</p>

CC BY-SA 4.0
2019-03-26T15:37:42.077Z
2019-03-26T15:37:42.077Z
swysocki
<p>To extend others' answers, CI allows to have a "single place of truth" how the software builds and runs in terms of system environment dependencies.</p>

<p>With the rise of infrastructure as code you could of course say okay I have git to put my Dockerfiles for example but this makes somehow no sense.</p>

<p>Many open source projects on GitHub verify validity of pull requests through CI untegration and do double, even triple checks, that is even just one CI system appears not enough to achive high quality.</p>

CC BY-SA 4.0
2019-03-27T05:41:51.930Z
2019-03-27T05:41:51.930Z
Ta Mu
<p>There are 2 aspects of the software integration (be it continuous or not):</p>

<ul>
<li>performing the technical steps to integrate multiple changes - which is what you're referring to in the git-based environments</li>
<li>checking the quality of the integrated code - in the traditional CI methodology this is what Jenkins and other CI tools do</li>
</ul>

<p>Jenkins won't technically do the integration steps itself, AFAIK it is not capable of doing that. Its operation is only triggered <strong>after</strong> the technical integration steps are completed, typically by the developers (in your case after you <code>git commit</code> and <code>git push</code> your changes to origin).</p>

<p>There is a different kind of CI tools out there, the gating-commits ones, which actually perform the technical integration, run the QA verifications on the result and, only on success of the verification, they also merge the result into origin. They effectively do the entire software integration work and are thus capable of guaranteeing no QA regressions in the end result.</p>

CC BY-SA 4.0
2019-03-27T11:25:16.190Z
2019-03-27T11:25:16.190Z
Dan Cornilescu
<p>Continuous Integration with Jenkins would handle code integration but that would not be its only role. This is what I think you are missing.</p>

<p>For continuous integration, you would also run your <strong>testing</strong> stack and <strong>product building</strong> steps. However, if you don't have testing (I would highly recommend it) and you have no need for a building stage, git would do just fine.</p>

CC BY-SA 4.0
2019-03-26T15:38:48.857Z
2019-03-26T15:43:55.773Z
2019-03-26T15:43:55.773Z
Aliminator
<p>I have a conceptual doubt about CI using Jenkins. I know Jenkins can help me to integrate all code built by developers. </p>

<p>So the question is: How is this not already resolved with Github (or any other git tool)?</p>

<p>I can run <code>git stash</code>, <code>git pull origin master</code>, and/or <code>git stash apply</code> to integrate other code with my code.</p>

<p>So I think I am misunderstanding something about continuous integration. Can you clear my mind?</p>

<continuous-integration><cicd>
How is Continuous Integration different from using git to integrate external code?
mgg
# How is Continuous Integration different from using git to integrate external code?

(Asked by: username_0 on 2019-03-26)

I have a conceptual doubt about CI using Jenkins. I know Jenkins can help me to integrate all code built by developers.

So the question is: How is this not already resolved with Github (or any other git tool)?

I can run `git stash`, `git pull origin master`, and/or `git stash apply` to integrate other code with my code.

So I think I am misunderstanding something about continuous integration. Can you clear my mind?

**Tags:** continuous-integration, cicd


---

## 4 answers

### Answer by username_1 on 2019-03-26. Score: 1

Merging code changes is definitely handled by Git and its tools. But Continuous Integration also includes **testing** and **building** the software. The development teams are provided with constant feedback on the status of their branch(es) and whether they are failing tests, builds, etc.

Jenkins provides the tools to enable this feedback. By creating a CI "pipeline" in Jenkins the developer gain much better insight into the build, beyond what simple Git merges and stashes provide.


---

### Answer by username_2 on 2019-03-27. Score: 0

To extend others' answers, CI allows to have a "single place of truth" how the software builds and runs in terms of system environment dependencies.

With the rise of infrastructure as code you could of course say okay I have git to put my Dockerfiles for example but this makes somehow no sense.

Many open source projects on GitHub verify validity of pull requests through CI untegration and do double, even triple checks, that is even just one CI system appears not enough to achive high quality.


---

### Answer by username_3 on 2019-03-27. Score: 0

There are 2 aspects of the software integration (be it continuous or not):

* performing the technical steps to integrate multiple changes - which is what you're referring to in the git-based environments
* checking the quality of the integrated code - in the traditional CI methodology this is what Jenkins and other CI tools do

Jenkins won't technically do the integration steps itself, AFAIK it is not capable of doing that. Its operation is only triggered **after** the technical integration steps are completed, typically by the developers (in your case after you `git commit` and `git push` your changes to origin).

There is a different kind of CI tools out there, the gating-commits ones, which actually perform the technical integration, run the QA verifications on the result and, only on success of the verification, they also merge the result into origin. They effectively do the entire software integration work and are thus capable of guaranteeing no QA regressions in the end result.


---

### Answer by username_4 on 2019-03-26. Score: 0

Continuous Integration with Jenkins would handle code integration but that would not be its only role. This is what I think you are missing.

For continuous integration, you would also run your **testing** stack and **product building** steps. However, if you don't have testing (I would highly recommend it) and you have no need for a building stage, git would do just fine.


---

