Git Basics for Beginners, Your First Repository and Commit

If you have ever saved files named budget_final.py, budget_final2.py and budget_REALLY_final.py, you already understand the problem Git solves. Git keeps a history of snapshots of your project, so you can see what changed, when, and go back if something breaks. The steps below use a tiny one-file project and the free official book, Pro Git. Every command was run in a real repository, and the output shown is what Git printed.

1. One-time setup: tell Git who you are

Pro Git says the first thing to do after installing Git is set your name and email, because every commit records them:

git config --global user.name "Sam Lee"
git config --global user.email sam@example.com

The --global option means you only do this once per computer. The book also explains that Git creates a branch called master by default in a new repository, and that from Git 2.28 onward you can choose a different name. Many hosting sites now use main, and this command makes it your default:

git config --global init.defaultBranch main

You can check any setting by asking for it, for example git config user.name, which printed Sam Lee.

2. Step 1: Turn a folder into a repository

Go into your project folder and run:

git init

Output:

Initialized empty Git repository in .../budget-script/.git/

Pro Git explains that this creates a hidden .git subfolder holding the repository, and that nothing is tracked yet.

3. Step 2: Check the status

Create a file, budget.py, containing one line: print("Monthly budget"). Then ask Git what it sees:

git status

Output:

On branch main

No commits yet

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

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

The book describes two states for every file: tracked (Git knows about it) and untracked (everything else). Git will not start including a new file until you tell it to, which, as the book notes, prevents you from accidentally committing generated files you did not mean to include.

4. Step 3: Stage the file

git add budget.py
git status --short

Output:

A  budget.py

The A means the file is staged, or added to the staging area. Think of the staging area as a box you are packing for the next snapshot. Pro Git makes an important point here: Git stages a file exactly as it is when you run git add. If you edit it again afterward, you need to run git add again, or the commit will contain the older version.

5. Step 4: Commit

git commit -m "Add budget script"

Output:

[main (root-commit) 7c5a505] Add budget script
 1 file changed, 1 insertion(+)
 create mode 100644 budget.py

The -m flag lets you write the message on the same line instead of opening a text editor. The book explains what the output shows: the branch, the start of the commit's SHA-1 checksum (7c5a505 here; yours will differ), and how many files and lines changed. A commit records whatever was in the staging area. Anything you did not stage stays as a modified file on disk.

6. Step 5: Make a change and see exactly what changed

Add a second line to budget.py, print("Total: 1200"), and suppose the script also produced a run.log file:

git status --short

Output:

 M budget.py
?? run.log

M means modified and ?? means untracked. To see the actual lines that changed, not just file names, Pro Git points to git diff:

git diff

The important part of the output:

--- a/budget.py
+++ b/budget.py
@@ -1 +1,2 @@
 print("Monthly budget")
+print("Total: 1200")

The line starting with + is new.

7. Step 6: Ignore files that should not be tracked

Log files, caches and virtual environment folders do not belong in history. Pro Git describes the .gitignore file for this: a list of patterns for Git to ignore, where * matches any characters and a trailing / means a folder. Create .gitignore with two lines:

*.log
.venv/

Now git status --short shows:

 M budget.py
?? .gitignore

run.log has disappeared from the list. The book calls it generally a good idea to set up .gitignore before you get going, so you do not accidentally commit files you do not want.

Stage both files and commit:

git add budget.py .gitignore
git commit -m "Print total and ignore log files"

8. Step 7: Look at the history

git log --oneline

Output (your checksums will differ):

9aa38b4 Print total and ignore log files
7c5a505 Add budget script

Pro Git explains that git log lists commits newest first, and that --oneline is shorthand for a compact one-line view with shortened checksums. Plain git log shows the author, date and full message for each commit.

9. The everyday loop

Once set up, most work with Git is the same short cycle:

1. Edit files.
2. git status to see what changed.
3. git diff to review the changes.
4. git add the files you want in the snapshot.
5. git commit -m "A clear message".

10. Key takeaways

• Set user.name and user.email once with git config --global before your first commit.
• git init turns a folder into a repository; nothing is tracked until you git add it.
• Git stages a file as it is at the moment of git add; edit again and you must add again.
• git diff shows the exact lines changed; git log --oneline shows a compact history.
• Put generated files like logs and .venv/ in .gitignore early.