المستودعات والتجهيز والـ commits

Written Explanation

Repository and git init

A repository (repo) is a project folder that Git tracks, together with Git's database of its history. git init creates that database:

mkdir greeter
cd greeter
git init

Initialized empty Git repository in C:/Users/.../greeter/.git/

Git created a hidden folder named .git inside your project. That folder is the history. Your normal files stay where they are; .git sits beside them. Deleting .git removes the history and turns the folder back into an ordinary folder, so never delete it by accident. Run git init once per project, in the project's top folder, never inside another repository.

By default a new repository's first branch is called master in Git itself (the manual says this will change to main in Git 3.0), but many installations are set up to use main. The branch name only matters from lesson L04 on. To choose it yourself: git init -b main, or once per computer git config --global init.defaultBranch main. This course's examples use main.

Telling Git who you are

Each commit records an author. Set it once per computer:

git config --global user.name "Sara Student"
git config --global user.email "sara@example.com"

Use your own details. Without them, git commit stops with a message asking you to set them.

Three places a change can live

This is the most important idea in the lesson. A change travels through three areas:

edit            git add            git commit
working tree ---------> staging ---------------> repository

Why have a middle step? Because the work you did in the last hour might be two different things, such as a bug fix and an unrelated clean-up. Staging lets you record them as two separate commits with two honest messages. The Pro Git book describes the same three states: modified, staged, committed.

Tracked and untracked files

A file Git knows about (it is in the last commit, or you have staged it) is tracked. Everything else is untracked, and Git ignores it until you add it. That is why a brand-new file does nothing until you run git add.

git status: the command you will run most

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	Greeter.java

nothing added to commit but untracked files present (use "git add" to track)

git status tells you the branch, which files are untracked, which are staged ("Changes to be committed"), and which are modified but not staged ("Changes not staged for commit"). It also hints at the next command. Read it before every commit. A shorter form, git status -s, prints one line per file: the left column is the staging area and the right column is the working tree. ?? means untracked, A means newly staged, M means modified.

git add: choose what goes in

git add Greeter.java

This copies the file's content as it is right now into the staging area. If you edit the file again afterwards, the new edit is not staged until you run git add again. You can name several files (git add A.java B.java). git add . stages everything in the current folder, which is quick but dangerous: it will also stage files you did not mean to include, such as compiled .class files. L06 and L07 deal with that. Until then, prefer naming files.

git commit: record the snapshot

git commit -m "Add Greeter class that prints a greeting"

[main (root-commit) 97a2799] Add Greeter class that prints a greeting
 1 file changed, 5 insertions(+)
 create mode 100644 Greeter.java

The commit contains exactly what was staged, not what is in your working tree. -m gives the message on the command line. Without -m, Git opens a text editor for the message; which editor depends on your setup, so if one opens unexpectedly, write the message, save, and close it. The words root-commit appear only for the very first commit of a repository.

Run git status again and it says nothing to commit, working tree clean: the working tree, staging area, and last commit all agree.

Writing a good commit message

A message is a note to a future reader, and the reader is usually you. A good one:

• is short (one line, readable at a glance in a list);
• starts with a verb in the imperative: "Add", "Fix", "Rename", "Remove";
• says what changed and, when it is not obvious, why;
• describes one change, not "stuff".

The imperative style ("Add", not "Added") is a widely used convention rather than a Git rule. What matters most is that your team uses a consistent style and that every message tells a reader something.

The workflow in one loop

1. Edit files.
2. git status to see what changed.
3. git add the files that belong together.
4. git commit -m "...".

Repeat. Small, frequent commits are much easier to understand and undo than one giant commit at the end of the week.