2IRR00Software Design

2IRR00 · Topic 05

Collaboration & Version Control

Git workflow, centralized vs distributed, properties

Version control concepts

A version control system tracks changes to files, stores ordered versions, allows reverting and collaboration, and can (semi-)automatically merge non-conflicting changes.

Change/diff/delta = a modification (line-based for code, file-based for binaries). Commit = a collection of changes with a message. Version/revision = a state after a commit (unique id). Head = the most recent commit on a branch.

Repository = a location storing all files. Should contain source, build files, docs, resources. Should NOT contain object files (.class) or executables.

Branch = a duplicate of files within the repository, developed independently (features/bugfix/release); deleted if the repo is deleted. Fork (GitHub) = an independent copy (different owner), survives deletion of the original; merges back via pull requests.

Merge conflict = the system cannot auto-merge (same lines / binary); requires manual resolution and a new commit.

Good commit messages explain the WHY (issue/requirement/necessity) and the WHAT (summary of changes).

Double-click this block to add a note to Version control concepts.

Common mistakes

  • Committing build artifacts/executables (.class) into the repo.
  • Updating binaries frequently — full copies are stored, bloating the repo.
Double-click this block to add a note to Common mistakes.

Exam tips

  • Branch lives inside the repo (deleted with it); fork is independent (survives, different owner, merge via PR).
  • Head = latest commit; commits reference their parent (point back in time).
Double-click this block to add a note to Exam tips.

Version control concepts practice

1 questions

Question 1/1 · 0 reviews recorded
Self-review
Difference between a branch and a fork?
Double-click this block to add a note to Version control concepts practice.

Git workflow & centralized vs distributed

Git is a distributed VCS: clone/add/commit/push/pull move changes between the working directory, staging/index, local repository, and remote repository.

git clone = create a local copy of the remote. git add = stage specific/all files. git commit -m = snapshot the staging area into the LOCAL repo. git push = send committed changes to the remote. git pull = fetch + merge from the remote.

Pipeline: working directory → (git add) → staging/index → (git commit) → local repository → (git push) → remote repository.

Centralized (e.g. SVN): one central server stores all data; developers hold only the current version (no history); every interaction needs a connection; if the server is lost, history is lost.

Distributed/decentralized (e.g. Git): everyone has a full local copy INCLUDING history; can work offline/in isolation (risk: forgetting to update).

Dangerous commands: git reset --hard (loses uncommitted changes), git push --force (overwrites others' commits). Be careful with options you don't understand.

Double-click this block to add a note to Git workflow & centralized vs distributed.
What `clone → add *.java → commit` has and hasn't done (exam Q13)
git clone repo                       # ✔ created a new LOCAL copy of the repo
git add *.java                       # ✔ staged all new/modified Java files
git commit -m "changed something"    # ✔ submitted changes to the LOCAL repo
# ✘ NOT yet sent to the remote — that needs git push
Double-click this block to add a note to git-commands-example.

Common mistakes

  • Thinking commit sends changes to the server — it only writes to the LOCAL repository; push sends to the remote.
  • Using reset --hard / push --force without understanding them.
Double-click this block to add a note to Common mistakes.

Exam tips

  • Key centralized-vs-distributed difference (open Q, 2 points): centralized = one server, only current version (no history); distributed = every dev has a full local copy including history.
  • You won't have to write git options — but you must explain commands and their order.
Double-click this block to add a note to Exam tips.
Double-click this block to add a note to Memory aid.

Git workflow & centralized vs distributed practice

1 questions

Question 1/1 · 0 reviews recorded
Self-review
After clone, add, commit (no push), where are your changes?
Double-click this block to add a note to Git workflow & centralized vs distributed practice.

Java Properties (configuration)

Java Properties externalise settings (key=value) into a configuration file instead of hard-coding scattered parameters.

Put the .properties file under src/main/resources so Maven copies it into target during the build.

Use props.load(InputStream) to read, getProperty(key) / getProperty(key, default), setProperty, remove, and store(Writer, comment) to write.

Maven may not overwrite a file in target if it was modified there only — delete it to restore the original.

Double-click this block to add a note to Java Properties (configuration).

Common mistakes

  • Hard-coding scattered configuration values throughout the code.
Double-click this block to add a note to Common mistakes.

Exam tips

  • Know that Properties move scattered hard-coded settings into a dedicated config file (variation in space).
Double-click this block to add a note to Exam tips.

Java Properties (configuration) practice

1 questions

Question 1/1 · 0 reviews recorded
Self-review
Why use a properties file instead of hard-coded settings?
Double-click this block to add a note to Java Properties (configuration) practice.