Git & GitHub | CampusToAI Academy

🧠

Concept

What is Version Control and Git?

Imagine writing a novel and saving it as "novel_v1.docx", "novel_v2.docx", "novel_final.docx", "novel_FINAL_REAL.docx". That's version control without Git — chaotic.

Git tracks every change you make to every file, lets you name those snapshots (commits), go back to any point in time, and work on different versions (branches) simultaneously.

Concept	Meaning
Repository (repo)	A folder tracked by Git — contains all files + history
Commit	A saved snapshot of your changes with a message
Branch	An independent line of development
Merge	Combine changes from two branches
Remote	A copy of the repo on a server (GitHub)
Clone	Download a remote repo to your machine
Push	Upload your local commits to remote
Pull	Download and merge remote changes to local

⚙️

Step 1

Install & Configure Git

1

Install Git

Windows: Download from git-scm.com → run installer (all defaults are fine).
Mac: brew install git or it installs when you run git --version.
Linux: sudo apt install git

2

Configure your identity

git config --global user.name "Rahul Sharma"
git config --global user.email "rahul@email.com"
git config --global init.defaultBranch main

3

Verify

git --version   # git version 2.44.0
git config --list

📝

Step 2

Git Basics: init, add, commit, log

# Start a new Git repository in current folder
git init

# Check what's changed (most used command!)
git status

# Stage files for commit (add to "staging area")
git add StudentController.java    # specific file
git add src/                       # entire folder
git add .                          # everything in current directory

# Commit staged changes with a message
git commit -m "Add StudentController with CRUD endpoints"

# View commit history
git log                    # full history
git log --oneline          # one line per commit (cleaner)
git log --oneline --graph  # visual branch graph

# See what changed in files (before staging)
git diff

# Undo staged changes (unstage)
git restore --staged StudentController.java

# Discard local file changes (WARNING: can't undo!)
git restore StudentController.java

Write good commit messages. Bad: "fix". Good: "Fix NullPointerException in StudentService.findById when id doesn't exist". Future you will thank present you.

🌿

Step 3

Branching Strategy

Branches are like parallel universes. The main branch is the production universe. When you add a new feature, you create a new universe (branch), make changes there, and when it's ready, merge it back into main.

# Create and switch to new branch
git checkout -b feature/add-course-api
# OR (newer syntax)
git switch -c feature/add-course-api

# List all branches
git branch        # local branches
git branch -a     # local + remote branches

# Switch to existing branch
git switch main

# Merge a branch into current branch
git switch main
git merge feature/add-course-api

# Delete a branch (after merging)
git branch -d feature/add-course-api

Team Branching Workflow (GitFlow simplified)

Branch	Purpose	Rule
`main`	Production-ready code	Never commit directly
`develop`	Integration branch	Features merged here first
`feature/xxx`	New feature work	Branch from develop, merge back to develop
`fix/xxx`	Bug fix	Branch from main or develop

🐙

Step 4

GitHub & Remote Repositories

# Clone an existing repo from GitHub
git clone https://github.com/username/student-api.git

# Add remote origin to an existing local repo
git remote add origin https://github.com/username/student-api.git
git remote -v  # verify remote URL

# Push local commits to GitHub
git push origin main              # push main branch
git push -u origin main           # -u sets upstream (do once)
git push origin feature/auth-api  # push a feature branch

# Pull latest changes from GitHub
git pull origin main    # fetch + merge
git fetch origin        # only download, don't merge yet

# Daily workflow
git pull                # get latest changes from team
# ...make your changes...
git add .
git commit -m "your message"
git push                # send to GitHub

🔁

Team Workflow

Pull Requests (PRs)

A Pull Request is a formal request to merge your branch into main. Your teammates review the code, ask questions, suggest improvements, and approve it before it goes to production. It's the code review process.

1

Create feature branch and push

git checkout -b feature/payment-api
# ... write code ...
git add .
git commit -m "Add payment processing API"
git push origin feature/payment-api

2

Open PR on GitHub

GitHub shows a "Compare & pull request" banner when you push a new branch. Click it. Fill in the PR title and description explaining WHAT you changed and WHY.

3

Code review and merge

Reviewers leave comments. Address feedback by pushing more commits to the same branch — the PR updates automatically. Once approved, merge the PR.

⚠️

Problem Solving

Merge Conflicts

A merge conflict happens when two branches changed the same line(s) of the same file. Git can't decide which version to keep — you have to resolve it manually.

# After running: git merge feature/auth-api
# Git shows CONFLICT message. The file looks like:

<<<<<<< HEAD  (your current branch changes)
return ResponseEntity.ok(student);
=======
return ResponseEntity.ok(studentDto);
>>>>>>> feature/auth-api  (incoming branch changes)

1

Open the conflicted file in VS Code

VS Code highlights conflicts and shows "Accept Current", "Accept Incoming", or "Accept Both" buttons — use them!

2

Resolve and save

Delete the conflict markers (<<<, ===, >>>) and keep the correct code. Save the file.

3

Commit the resolution

git add StudentController.java
git commit -m "Resolve merge conflict in StudentController"

⚙️

CI/CD

GitHub Actions — Automated Build & Test

GitHub Actions is your robot teammate. Every time someone pushes code, the robot: builds the project, runs all tests, and if everything passes, optionally deploys to production. This is CI/CD — Continuous Integration / Continuous Deployment.

.github/workflows/ci.yml

name: CI — Build & Test

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up JDK 21
        uses: actions/setup-java@v4
        with:
          java-version: '21'
          distribution: 'temurin'

      - name: Build with Maven
        run: mvn clean compile

      - name: Run Tests
        run: mvn test

      - name: Build JAR
        run: mvn package -DskipTests

Every PR now shows a green checkmark ✅ when tests pass or a red ✗ when they fail. Reviewers won't merge broken code. This is standard industry practice.

🎯

Interview Prep

Common Interview Questions

QWhat is Git and why do we use it?

Git is a distributed version control system that tracks changes to files over time. We use it to: maintain history of every change (who changed what and why), collaborate with teams without overwriting each other's work, experiment safely with branches, revert to any previous state, and enable CI/CD pipelines.

QWhat is the difference between git fetch and git pull?

git fetch downloads changes from the remote repository but does NOT merge them into your working branch. It updates your remote-tracking branches (origin/main) but your local main stays unchanged. Safe to run anytime.

git pull = git fetch + git merge. Downloads changes AND immediately merges them into your current branch. Use when you're ready to incorporate remote changes.

QWhat is a merge conflict and how do you resolve it?

A merge conflict occurs when two branches have modified the same lines of the same file. Git can't automatically choose which version to keep.

To resolve: open the conflicted file (Git marks conflicts with <<<, ===, >>> markers), manually decide the correct code, remove the markers, save the file, stage it with git add, and commit.

QWhat is the difference between git merge and git rebase?

git merge creates a new "merge commit" that combines two branches. It preserves the full history of both branches. The branch history is non-linear but authentic.

git rebase moves or "replays" your commits on top of another branch's tip. It creates a linear history — looks like you branched from the latest commit. Cleaner history but rewrites commit hashes.

Rule: Use merge for shared/public branches. Use rebase for your local feature branches before creating a PR (to clean up history).

QWhat is CI/CD?

CI (Continuous Integration) — Every code push triggers an automated build and test run. Catches bugs immediately when code is merged. Tools: GitHub Actions, Jenkins, GitLab CI.

CD (Continuous Deployment/Delivery) — After CI passes, code is automatically deployed to staging or production. Every passing build can go live without manual steps.