Mastering the Git Workflow: A Guide to Staging and Committing Files
To truly harness the power of Git for version control, you must understand its fundamental workflow: how changes move from your working directory to a permanent place in your project’s history. This process isn’t just about saving files; it’s about crafting a clean, understandable, and manageable history of your project’s evolution.
The core of this process revolves around three key states a file can be in: modified, staged, and committed. Understanding the distinction between these states is the first step toward becoming proficient with Git.
Understanding the Three States of Your Files
Every file in your working repository is in one of two primary states: tracked or untracked. Tracked files are those that Git knows about—they were part of the last snapshot (or commit). Untracked files are everything else.
Tracked files can be further broken down into three sub-states:
- Modified: You have changed the file, but you have not yet marked that change to be included in your next commit. The changes exist only in your working directory.
- Staged: You have formally marked a modified file in its current version to be included in your next commit snapshot. This is a crucial intermediate step that allows you to carefully select which changes make up your next commit. This “holding area” is known as the staging area or the “index.”
- Committed: The data from the file is safely stored in your local Git repository. The change is now a permanent part of your project’s history.
This three-state model is what makes Git so flexible. It allows you to fine-tune your commits, ensuring each one represents a logical, self-contained unit of work.
Checking the Status of Your Repository: git status
The most important command in this workflow is git status. You should run it frequently to see the current state of your files. It tells you which files are untracked, which are modified, and which are staged.
When you run git status, Git will present a clear summary:
- Changes to be committed: These are your staged files, ready for the next commit.
- Changes not staged for commit: These are tracked files that you have modified but not yet staged.
- Untracked files: These are new files in your directory that Git does not yet track.
Staging Your Changes: The Power of git add
The git add command is used to move changes from the modified state to the staged state. It’s a multipurpose command that you use to begin tracking new files and to stage modifications to existing files.
Let’s say you’ve edited style.css and created a new file called script.js.
- Running
git statuswill showstyle.cssunder “Changes not staged for commit” andscript.jsunder “Untracked files.” - To stage the changes to the stylesheet, you would run:
bash
git add style.css
- To begin tracking and stage the new script file, you run the same command:
bash
git add script.js
After running these commands, git status will now show both files under “Changes to be committed.” You have successfully prepared a snapshot of these changes, but you haven’t recorded them permanently yet. The staging area allows you to build your commit piece by piece.
Committing Your Work: Creating a Snapshot
Once your staging area has all the changes you want for a single, logical unit of work, you can commit them. This is done with the git commit command.
Committing takes the files as they are in the staging area and permanently stores that snapshot in your Git history.
The best practice is to include a descriptive message with your commit using the -m flag. This message explains why you made the change.
git commit -m "Add responsive styling for mobile navigation"
A well-written commit message is crucial for collaboration and for understanding your project’s history later. If you run git commit without the -m flag, Git will open your default text editor for you to write a more detailed, multi-line message.
Skipping the Staging Area: A Useful Shortcut
For simple workflows, you might want to commit all changes to tracked files without manually running git add. Git provides a shortcut for this.
The git commit -a command will automatically stage every file that is already tracked by Git before committing.
git commit -a -m "Fix typo in footer and update contact email"
Important: This command will not add new, untracked files to your commit. It only works for files that Git already knows about. For new files, you must always use git add first.
Managing Files: Removing and Renaming
To properly remove a file from your project, you need to remove it from Git’s tracking and delete it from your working directory. The git rm command handles both.
git rm old_script.js
This command removes the file and stages that removal. The file will be permanently gone from your project after the next commit.
If you want to rename a file, the proper Git command is git mv:
git mv old_name.js new_name.js
This is equivalent to running mv old_name.js new_name.js, git rm old_name.js, and git add new_name.js in sequence.
Ignoring Files: The Crucial .gitignore File
Often, you have files or directories in your project that you do not want Git to ever track. These can include log files, build artifacts, dependency folders (node_modules), or files with sensitive credentials.
You can tell Git to ignore these files by creating a file named .gitignore in your project’s root directory. Each line in this file is a pattern for files or folders to ignore.
A simple .gitignore file might look like this:
# Ignore log files
*.log
# Ignore OS-generated files
.DS_Store
# Ignore build output directory
/build/
# Ignore dependency cache
node_modules/
Setting up a .gitignore file is one of the first things you should do in a new repository. It prevents you from accidentally committing unnecessary or sensitive files.
Source: https://linuxhandbook.com/courses/git-for-devops/first-commit/
