Initiating a Repository

The lifecycle of a Git project begins with the init command. This creates the .git directory and sets up the necessary infrastructure for tracking.

mkdir my-university-project
cd my-university-project
git init

By default, Git will create a branch (usually named master or main). From this point forward, Git will watch for changes in this directory.

Monitoring Status

The most frequently used command is git status. It provides a summary of which files are in which state (Tracked, Untracked, Modified, Staged).

git status

Staging and Committing

The workflow in Git is a two-step process: Staging and Committing.

Staging with git add

Staging allows you to group related changes together. You might have changed ten files, but only five of them are related to a specific bug fix. You can stage just those five:

git add file1.c file2.c

Committing with git commit

A commit is a permanent snapshot. It is critical to write descriptive commit messages that explain why a change was made, not just what was changed.

git commit -m "Refactor memory allocation in parser to prevent overflow"

Observing Changes

To see exactly what has changed in your files since the last commit (but before you stage them), use git diff:

git diff

Once staged, you can use git diff --staged to see what is ready to be committed.

Exploring History

The git log command displays the commit history in reverse chronological order.

git log --oneline --graph --decorate

Excluding Files: The .gitignore

In any project, there are files that you never want to track:

• Compile artifacts (*.o, *.exe, bin/)
• User-specific IDE settings (.vscode/, .idea/)
• Sensitive information (.env, secrets.json)
• Dependency folders (node_modules/, venv/)

A .gitignore file is a text file where each line contains a pattern for files/directories to ignore.

# Ignore all object files
*.o

# Ignore the build directory
/build/

# Ignore sensitive files
.env

Atomic Commits

A “Best Practice” in DevOps is the concept of Atomic Commits. Each commit should represent a single logical change. If you are halfway through a feature and you find a typo in a completely different part of the codebase, don’t include the typo fix in your feature commit. Commit them separately. This makes the history easier to read, revert, and debug (e.g., using git bisect).

# Find which branch you are currently on
git