Understanding Version Control with Git

# CHAPTER 2

Understanding Version Control with Git #

1. Introduction #

Continuous Integration pipelines are triggered by code changes. To track those changes, collaborate with other engineers, and trigger automation safely, you must use a Version Control System (VCS). Git is the undisputed industry standard for version control. In this chapter, we will establish the foundational Git workflows required for modern CI/CD. We will explore branching strategies, the concept of the Pull Request (PR), and how Git serves as the ultimate "Source of Truth" for your infrastructure and applications.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Explain the purpose of a Distributed Version Control System like Git.

• Differentiate between Git (the tool) and GitHub (the hosting platform).

• Execute basic Git commands (add, commit, push, pull).

• Understand the "Feature Branch" workflow.

• Define what a Pull Request is and why it acts as a CI/CD gateway.

3. Beginner-Friendly Explanation #

Imagine writing a novel with a co-author.

• Without Git: You email a file named BookFinalV2_ActualFinal.docx back and forth. You both edit Chapter 1 at the same time. You email the files back, and now you have two conflicting files and no idea who made what changes.

• With Git: You store the novel in a central vault. When you want to work on Chapter 1, you create an exact copy (a Branch) of the whole book. You make your changes. When you are done, you submit your Branch to the vault. Git highlights exactly which sentences you changed. If it looks good, Git seamlessly merges your sentences into the master copy.

4. Git vs GitHub #

• Git is the command-line software installed on your computer. It tracks changes to files locally.

• GitHub (or GitLab, or Bitbucket) is a website. It is a cloud server that hosts your Git repositories so other developers can download them, and more importantly, so CI/CD robots can access them.

5. The Feature Branch Workflow #

In a CI environment, you never, ever push code directly to the main branch. The main branch is sacred; it represents production.

The Workflow:

1. 1. Branch: You create a safe, isolated workspace for your new feature.

git checkout -b add-login-button

1. 2. Commit: You make your code changes and save them locally.

git add . git commit -m "Added the login button"

1. 3. Push: You upload your branch to the cloud server (GitHub).

git push origin add-login-button

1. 4. Pull Request (PR): You ask the team, "Can I merge my add-login-button branch into the main branch?"

6. Mini Project: Create Collaborative Git Workflow #

Let's conceptualize how the Pull Request interacts with our CI Pipeline.

The Pull Request Gateway: When you open a Pull Request, a human usually reviews the code. However, humans make mistakes. This is where CI steps in.

1. 1. The developer clicks "Create Pull Request".

1. 2. The CI Trigger: GitHub instantly detects the PR. It sends a signal to the CI Server.

1. 3. The CI Server downloads the code from the add-login-button branch.

1. 4. The CI Server runs unit tests.

1. 5. The Gateway: If the tests FAIL, the CI server puts a big red X on the Pull Request. The "Merge" button is blocked. The code cannot be merged into main. If the tests PASS, the CI server puts a green checkmark, and the human reviewer is allowed to click "Merge".

*The CI pipeline acts as an automated bouncer, ensuring broken code never enters the main branch.*

7. Real-World Scenarios #

A junior developer was working on a small CSS fix. Because the company didn't use Pull Requests or CI, the developer pushed the code directly to the main branch. They accidentally deleted a semicolon in the core JavaScript file, breaking the entire website's checkout process. It took hours to find the bug. The next day, the company instituted a strict "Feature Branch + PR" policy. Direct pushes to main were disabled. Now, if a developer misses a semicolon, the CI pipeline catches it during the Pull Request phase, blocks the merge, and the live website is completely unaffected.

8. Best Practices #

• Atomic Commits: A commit should do *one* thing. Do not write a single commit message that says: git commit -m "Fixed login bug, updated CSS, and refactored database connection". If that commit breaks the CI pipeline, you have no idea which of the three changes caused the failure. Break it into three separate, atomic commits.

9. Security Recommendations #

• Branch Protection Rules: In GitHub or GitLab, you must configure "Branch Protection" on your main branch. You must check two critical boxes:

1. 1. *Require Pull Request reviews before merging.*

1. 2. *Require status checks to pass before merging.* (This forces the CI pipeline to pass before a merge is allowed).

10. Troubleshooting Tips #

• Merge Conflicts: If you and another developer edit the exact same line of code in the exact same file, Git will throw a "Merge Conflict" during the Pull Request. Git is smart, but it refuses to guess who is right. You must manually open the file, decide which line of code stays, and then commit the resolution.

11. Exercises #

1. 1. What is the operational danger of committing code directly to the main branch in a collaborative environment?

1. 2. Explain how a Pull Request functions as an automated quality gateway in a CI/CD pipeline.

12. FAQs #

Q: Can I use CI/CD without Git? A: Theoretically, yes (using SVN or Mercurial), but practically, no. The entire modern DevOps ecosystem is built fundamentally around Git. Git and CI/CD are inseparable.

13. Interview Questions #

• Q: Describe the "Feature Branch Workflow." At what specific stage in this workflow does a Continuous Integration pipeline typically execute, and why?

• Q: Explain the purpose of Branch Protection rules in a Git hosting platform (like GitHub). How do these rules prevent broken code from being deployed to production?

14. Summary #

In Chapter 2, we established the bedrock of all automation: Version Control. We learned that Git allows teams to collaborate safely by isolating risky changes into Feature Branches. We transitioned from seeing Git merely as a backup tool to understanding its role as the definitive trigger for our CI pipelines. By enforcing Branch Protection rules and utilizing Pull Requests, we created a rigorous, automated gateway. Broken code is now caught by our CI robot *before* it is ever merged into the sacred main branch, ensuring absolute stability for our application.

15. Next Chapter Recommendation #

We understand the theory of pipelines and the Git triggers that start them. But who actually runs the pipeline? We need a tool. Proceed to Chapter 3: CI/CD Tools Overview.