Git & Professional Java Workflow — Java Course

What you'll learn

Git is the version-control system the entire software world runs on. It tracks every change, lets teams work in parallel without stepping on each other, and makes mistakes reversible. This module covers Git and the professional workflow built around it on GitHub.

By the end you'll be able to:

Create a repository and commit your work
Use branches and merge them (and understand rebasing)
Keep junk out of your repo with .gitignore
Collaborate via GitHub pull requests and code review
Understand semantic versioning and CI/CD

Repositories & commits

A Git repository tracks the full history of a project. You work in three areas — your files, a staging area where you gather the changes for the next snapshot, and the repository of committed history:

Git's areas

Working directory

Your edited files

→git add

Staging area

Changes ready to commit

→git commit

Local repository

Your commit history

→git push

Remote (GitHub)

Shared with your team

A commit is a saved snapshot with a message. Small, focused commits with clear messages make history readable and mistakes easy to undo:

Terminal

git init                    # start tracking this project
git add .                   # stage all your changes
git commit -m "Add login"   # save a snapshot with a message

git status                  # what's changed / staged?
git log --oneline           # browse the commit history

Tip

Write commit messages in the imperative mood — "Add login validation," not "Added..." or "Adding...". It reads like a command describing what the commit does, matching Git's own style.

Branches & merging

A branch is an independent line of work. You create one for each feature or fix, work on it without disturbing main, then merge it back when it's ready. This is what lets a whole team build different things at once:

Terminal

git checkout -b feature/login   # create AND switch to a new branch
# ...edit files...
git commit -am "Implement login form"

git checkout main               # switch back to the main branch
git merge feature/login         # bring the feature's commits in

Note

Merging combines branches and preserves their history (sometimes creating a merge commit). Rebasing re-applies your commits on top of another branch for a linear history. Both are valid — teams pick a convention. When two people change the same lines, you resolve a merge conflict by choosing what the final version should be.

.gitignore

Not everything belongs in version control. Build output, IDE settings, and — critically — secrets should never be committed. A .gitignore file lists patterns Git should skip:

.gitignore

# build output
target/
build/
*.class

# IDE files
.idea/
.vscode/

# secrets and local config
.env
*.local

Watch out

Never commit passwords, API keys, or .env files. Once pushed, a secret is in the history forever — even if you delete it later — and must be rotated. Add it to .gitignore before your first commit.

GitHub & pull requests

GitHub hosts repositories and adds collaboration on top. The standard team workflow: branch → push → open a pull request (PR) → teammates review the changes and suggest improvements → once approved, merge. Code review catches bugs, spreads knowledge, and keeps quality high — it's a cornerstone of professional development.

Versioning & CI/CD

Releases are numbered with semantic versioning — MAJOR.MINOR.PATCH (e.g. 2.4.1): bump PATCH for bug fixes, MINOR for new backward-compatible features, and MAJOR for breaking changes. And CI/CD (Continuous Integration / Continuous Delivery) automatically builds and tests every push — often deploying automatically when tests pass — so problems are caught immediately, not at release time.

Tip

A typical CI pipeline (e.g. GitHub Actions) runs on every PR: check out the code, build with Maven/Gradle, run all the tests, and report back. If anything fails, the PR can't be merged — automated quality control for the whole team.

Recap & quick check

Key takeaways

Git tracks history across working directory → staging (git add) → repo (git commit) → remote (git push).
Branches isolate work; merge (or rebase) brings it back into main; resolve conflicts by hand.
.gitignore keeps build output and — crucially — secrets out of the repo.
GitHub pull requests + code review are the standard team workflow.
Semantic versioning is MAJOR.MINOR.PATCH; CI/CD auto-builds and tests every change.

Quick check

1. Which command saves a snapshot of your staged changes?

2. Why use branches?

3. What should you NEVER commit to a repository?

4. In semantic versioning 2.4.1, what does the '1' represent?

5. What does CI/CD automate?

Excellent — you can now collaborate the way real teams do. Next up: Module 33 — Clean Code & Object-Oriented Design.