Most software development today is done in teams working on one or more code repositories managed in a version-control system. Individual developers work on the areas of code that require changes and must decide when to commit their changes back into version control.

Sometimes, the code changes are easy and introduce few risks, so the developer can make the edits and commit with a low risk of interfering teammates working on the same codebase.

[ The essentials from InfoWorld: Get started with CI/CD: Automating your application delivery with CI/CD pipelines. • 5 common pitfalls of CI/CD—and how to avoid them. | Keep up with hot topics in programming with InfoWorld’s App Dev Report newsletter. ]

But what if the team is working on a bigger feature that will require several days, weeks, or even months of development? When is it appropriate to check in these code changes back into version control? Furthermore, what happens when that code is checked in to ensure that the integrated code developed by the team of developers integrates without build errors or other functionality defects?

To read this article in full, please click here