Skip to content

TD-Git — Version Control with Git

← Part 1 Overview

S7 Inf A3 — Java for Graphical and Mobile Programming
Stéphane Derrode — Centrale Lyon
Part 1 — Java Fundamentals
Duration: 2h · Pair or individual work

Objectives

By the end of this session you will be able to:

  • Configure Git on your machine (identity, first-time setup)
  • Turn your TD1 Maven project into a Git repository with a correct .gitignore
  • Use the core loop: status → add → commit → log, with good commit messages
  • Create a feature branch, commit on it, and merge it back into main
  • Connect a private remote on GitHub (or GitLab) and push your history
  • Clone a partner's repository to work together
  • Submit BE1 / BE2 through GitHub instead of a Moodle zip

Part 0 — Why this matters

Prerequisite: you must have finished TD1 — this session versions that project (the Car / Garage Maven project). If you skipped a step, your td1/ folder must at least contain pom.xml, Car.java, Garage.java and App.java.

Git gives your code save points and a history: you can undo a bad change, compare two versions, and never lose work. For the graded projects (BE1, BE2) done in pairs, it lets both partners contribute and merge their work — and it becomes the official submission channel for this course (no more Moodle zip).

If you already use Git in another course, skim Parts 1–2 and slow down at Part 5 (branches) and Part 7 (submission).

Part 1 — Install Check & First-Time Configuration (15 min)

1.1 Verify Git is installed

Open a terminal inside VSCodium (Ctrl+`) and run:

git --version    # git version 2.x.x

If the command is not found, install Git first:

OS Command / link
Windows git-scm.com/download/win
macOS brew install git (or install the Xcode Command Line Tools)
Linux sudo apt install git

1.2 Set your identity (once per machine)

Git stamps every commit with a name and an email. Set them once, globally:

git config --global user.name  "Ada Lovelace"
git config --global user.email "ada.lovelace@etu.ec-lyon.fr"

Use your school email — it is the address your instructor and your partner will recognise in the history.

Check what Git recorded:

git config --global --list
# user.name=Ada Lovelace
# user.email=ada.lovelace@etu.ec-lyon.fr

While you are here, make main the default branch name for new repositories (modern convention):

git config --global init.defaultBranch main

Part 2 — Initialise the Repository & .gitignore (20 min)

2.1 init inside the TD1 project

Navigate to your TD1 project folder (the one that contains pom.xml) and turn it into a repository:

cd path/to/td1      # adjust to where your project lives
git init            # creates a hidden .git/ folder — do this once

You should see: Initialized empty Git repository in .../td1/.git/.

2.2 Add a Maven .gitignore before the first commit

Never commit build artefacts — they are regenerated by Maven and only bloat the repository. Create a file named .gitignore at the project root (same level as pom.xml) with exactly:

target/
*.class
.vscode/
*.iml

What each line excludes:

Pattern Why ignore it
target/ Maven's compiled output (.class files, packaged jar) — regenerated by mvn compile
*.class Any stray compiled class outside target/
.vscode/ Editor-local settings, specific to your machine
*.iml IntelliJ module files, if a teammate uses IntelliJ

2.3 Confirm the ignore works

git status

You should see pom.xml, src/, .gitignore listed as untracked — but not target/. If you see target/ in the list, your .gitignore is in the wrong folder or misspelled.

Part 3 — The Core Loop: status / add / commit / log (25 min)

The everyday Git cycle has four moves. Learn them on this first commit.

3.1 First commit

git status                 # 1. what changed? (everything is untracked)
git add .                  # 2. stage all changes for the next commit
git commit -m "TD1: Car, Garage and App working"   # 3. record the snapshot
git log --oneline          # 4. see your history (one line per commit)

git log --oneline prints something like:

a1b2c3d (HEAD -> main) TD1: Car, Garage and App working

3.2 The staging area, in one picture

working dir   --git add-->   staging area   --git commit-->   history
 (you edit)                   (snapshot              (permanent
                               to be saved)           save point)
  • git add decides what goes into the next commit.
  • git commit writes that snapshot to history with a message.
  • git status tells you where each file is in this pipeline.

3.3 Writing good commit messages

A message says what you did, in the imperative, short enough to scan in log --oneline:

Good Bad
Add cruiseAt() method to Car update
Fix accelerate() cap at maxSpeed() stuff
TD1: Garage array with startAll() asdf

Commit small and often. One commit = one coherent change.

Part 4 — Commit Across the TD1 Steps (15 min)

A clean history reads like a changelog. Make a few more commits that retrace TD1.

4.1 Make a change, then commit it

Add the Part 4.1 counter from TD1 to Car.java (if you have not already):

private static int carsCreated = 0;

// inside both constructors:
carsCreated++;

public static int getCarsCreated() { return carsCreated; }

Then run the core loop again:

git status                                  # Car.java shows as "modified"
git add Car.java
git commit -m "Add static carsCreated counter to Car"

4.2 One more: the exploration method

Add cruiseAt(double v) (TD1 Part 4.2), then:

git add Car.java
git commit -m "Add cruiseAt() with bounds check"
git log --oneline

Your history should now have at least three commits:

e5f6g7h (HEAD -> main) Add cruiseAt() with bounds check
c3d4e5f Add static carsCreated counter to Car
a1b2c3d TD1: Car, Garage and App working

Tip: git add Car.java stages only that file. Use a specific filename when you want one focused commit; use git add . when several files belong to the same change.

Part 5 — A Feature Branch and a Merge (25 min)

Branches let you develop a feature in isolation without touching main. When it works, you merge it back. This is exactly how you and your BE partner will avoid stepping on each other.

5.1 Create and switch to a branch

We will add a small Car feature — a honk() method — on its own branch:

git switch -c feature/honk     # create branch "feature/honk" and switch to it
git branch                     # the * marks your current branch
# * feature/honk
#   main

5.2 Develop the feature

Add this method to Car.java:

public String honk() {
    return started ? "Beep beep!" : "(engine off — no honk)";
}

Test it from main() in App.java:

Car clio = new Car("Clio", 90);
System.out.println(clio.honk());   // (engine off — no honk)
clio.start();
System.out.println(clio.honk());   // Beep beep!

Commit on the branch:

git add Car.java App.java
git commit -m "Add honk() to Car"

5.3 Merge back into main

Switch back to main and merge the finished feature:

git switch main                # back to the main line
git merge feature/honk         # bring the feature in
git log --oneline              # the honk() commit now appears on main

Because main did not change while you worked, Git performs a fast-forward merge (no conflict). Clean up the merged branch:

git branch -d feature/honk     # delete the now-merged branch

When does a conflict happen? Only if the same lines were edited on both branches. Git then marks the file with <<<<<<< / ======= / >>>>>>>; you edit the file to keep the right version, git add it, and git commit. You will meet this for real during the BE.

Part 6 — Connect a Private Remote & Push (20 min)

A remote is a copy of your repository hosted online (GitHub or GitLab). It is your off-machine backup and the way two partners share code.

6.1 Create an empty private repository

On github.com (or your GitLab instance):

  1. Click New repository.
  2. Name it s7-java-td1.
  3. Set visibility to Private. Coursework repositories must stay private — check the school's policy before pushing.
  4. Do not add a README, .gitignore, or licence — you already have local content.
  5. Click Create repository and copy the URL it shows.
git remote add origin https://github.com/your-user/s7-java-td1.git
git push -u origin main        # -u remembers the link; later just "git push"

Reload the GitHub page — your files and your commit history are now online.

After this first push, the loop shrinks to:

git add .
git commit -m "..."
git push                       # send new commits to the remote

Part 7 — Clone a Partner's Repository (10 min)

To work on a partner's project, you clone it — Git copies the whole repository, history included.

7.1 Get access

Your partner adds you as a collaborator on their private repo (GitHub: Settings ▸ Collaborators ▸ Add people). You will get an invitation by email.

7.2 Clone it

cd ..                          # leave your own td1 folder
git clone https://github.com/partner-user/s7-java-td1.git
cd s7-java-td1
git log --oneline              # you see their full history

From now on the workflow is shared: git pull to fetch your partner's latest commits before you start, then add / commit / push your own. For the BE you will both push to the same repository.

Part 8 — GitHub as the BE1 / BE2 Submission Channel (15 min)

For the graded projects, GitHub replaces the Moodle zip. Your repository is your submission.

8.1 What to submit

  1. A private GitHub repository containing your BE project.
  2. Both partners as collaborators, each with real commits in the history (the history shows who did what).
  3. The instructor added as a collaborator so it can be graded.
  4. The PDF report committed in the repository root (see each project brief).

8.2 If a zip is still required

Some deadlines may still ask for an archive. From a Git repository, produce a clean zip of exactly the tracked files — no target/, no .git/:

git archive -o BE1_Lovelace_Babbage.zip HEAD

git archive packages the committed snapshot only, so it is automatically free of build artefacts. Name it exactly:

  • BE1_NomPrenom1_NomPrenom2.zip
  • BE2_NomPrenom1_NomPrenom2.zip

If you ever zip the folder by hand instead, run mvn clean first to delete target/.

8.3 VSCodium's Source Control panel

You do not have to type Git commands. VSCodium has built-in Git support:

  • Open the Source Control panel with Ctrl+Shift+G (Cmd+Shift+G on macOS).
  • Changed files appear there; hover a file and click + to stage (the GUI equivalent of git add).
  • Type a message in the box and click the ✓ Commit button.
  • The … menu ▸ Push / Pull mirrors git push / git pull.
  • The branch name in the bottom-left status bar lets you switch / create branches with a click.

The terminal and the panel act on the same repository — use whichever you prefer.

Deliverable

By the end of the session, your TD1 project must be a Git repository pushed to a private GitHub/GitLab remote, with:

  • a correct Maven .gitignore (no target/ tracked),
  • at least four commits with meaningful messages,
  • evidence of one merged feature branch in the history (git log --oneline --graph shows it).

Show your git log --oneline to the instructor before leaving. This same repository convention is what you will use to submit BE1 and BE2.

Common Errors

Error Cause Fix
Author identity unknown on first commit user.name / user.email not set Run the two git config --global commands from Part 1.2
target/ appears in git status .gitignore missing, misspelled, or in the wrong folder Put .gitignore next to pom.xml; check the four patterns from Part 2.2
Committed target/ by mistake Files were added before .gitignore existed git rm -r --cached target/ then commit
nothing to commit, working tree clean No changes staged, or you forgot to save the file Save in VSCodium (Ctrl+S), then git add
fatal: remote origin already exists git remote add origin run twice Use git remote set-url origin <url> instead
Updates were rejected on push Partner pushed commits you do not have git pull first, resolve any conflict, then git push
Permission denied / auth fails on push Not authenticated to GitHub Use a Personal Access Token (or SSH key) — not your account password