Git and GitHub Fundamentals

# CHAPTER 5

Git and GitHub Fundamentals #

1. Introduction #

2. Learning Objectives #

• Understand the basic Git workflow (commit, push, branch, merge).

• Distinguish between Git (the tool) and GitHub (the platform).

• Configure workflows to trigger on specific branches (e.g., main vs. dev).

• Understand how Pull Requests interact with GitHub Actions.

• Utilize the actions/checkout step to load repository code.

3. Beginner-Friendly Explanation #

• Git (The Time Machine): You write a scene, save a snapshot (commit), and write another. If you ruin the scene, Git allows you to instantly rewind time to the previous snapshot.

• Branching (Alternate Universes): You want to experiment with killing off the main character. You create a "Branch" (an alternate universe). You write the crazy scene there. The main script is safe.

• GitHub (The Writers' Room): The central hub where everyone uploads their alternate universes.

• Pull Request (The Pitch): You ask the director: "Can we merge my crazy alternate universe into the official main script?"

• GitHub Actions (The Fact Checker): Before the director says yes, an automated robot checks your alternate universe script to ensure you didn't introduce any plot holes.

4. Branching and Workflow Triggers #

Example: Triggering on Specific Branches

on:
  push:
    branches:
      - main # Only run if pushed to main
  pull_request:
    branches:
      - main # Run when a PR is OPENED against main

In this scenario, if a developer pushes code to feature-login, the workflow *does not run*. But the moment they open a Pull Request asking to merge feature-login into main, the workflow fires!

5. The Critical Step: actions/checkout #

We use an official marketplace action for this:

steps:
  - name: Checkout Repository
    uses: actions/checkout@v4
    
  - name: Now I can see my files
    run: ls -la # This will list all the files in your repo

Without actions/checkout@v4, your runner is just an empty Linux box.

6. Mini Project: Create Collaborative GitHub Workflow #

Step-by-Step Walkthrough:

1. 1. Create .github/workflows/pr-check.yml.

1. 2. Paste the following code:

name: Pull Request Quality Gate
on:
  pull_request:
    branches:
      - main

jobs:
  validate-code:
    runs-on: ubuntu-latest
    steps:
      - name: Get the code
        uses: actions/checkout@v4
      
      - name: Run a simulated quality check
        run: |
          echo "Checking code formatting..."
          sleep 2
          echo "Code meets quality standards!"

1. 3. Commit this file directly to the main branch.

1. 4. Now, create a new branch called test-branch. Make a tiny change to any file and commit it.

1. 5. Go to the Pull requests tab in GitHub and open a new Pull Request from test-branch into main.

1. 6. Observation: Look at the bottom of the Pull Request screen! GitHub has paused the merge process. You will see a yellow circle indicating the "Pull Request Quality Gate" workflow is running. Once it finishes, it turns into a green checkmark, giving reviewers confidence that the code is safe to merge.

7. Real-World Scenarios #

• pullrequesttarget vs pullrequest: If you are managing an open-source repo, strangers can submit malicious code to steal your repository secrets via Actions. Never use repository secrets in workflows triggered by the standard pullrequest event from a forked repository. GitHub provides specialized security events (like pullrequesttarget) to handle this safely.

1. 2. Explain how a workflow triggered by on: pullrequest acts as a safety net for a development team.

12. FAQs #

13. Interview Questions #

• Q: Explain the operational workflow of integrating GitHub Actions with Branch Protection Rules to enforce code quality before a merge.

• Q: A developer complains that their pipeline runner is executing commands on an empty directory, even though the workflow file is clearly inside a repository full of code. Identify the missing component in their YAML file.

14. Summary #

15. Next Chapter Recommendation #