Understanding the Git Workflow: Working Directory, Staging, Commit, and Push

The first time we were introduced to Git, we really didn't know where our code was going to be saved until I learned that Git is part of a control system. It keeps track of changes made to files in a project so you can: track what changed, see previous versions of what you were working on to undo mistakes, work on different features, collaborate with others on the code or project we were working on, and back up projects to GitHub. Once you have added the knowledge of the stages of a Git workflow, then you have total control of your project from the previous history to the current workspace.
During our learning, we were able to cover four stages of a Git workflow: working directory, staging, committing to the local repository, and pushing to the remote repository.

Working Directory

This is our working directory where we type our code, a folder where our code lives. When opening a file in the code editor and making changes, we are working in the Working Directory; at this moment Git is aware that something has changed, but it hasn't recorded anything permanently yet. If we check the status by writing a command like git status, it will show the files that have been modified or deleted. Here, the changes are tracked but not yet saved.
Suppose we edited a file here, and we check the status. Git sees the changes, but they are unstaged. For example
SQL CODE like;

select customer_id, product_id 
            From Customers
Then we make a change to this code; let's say 
        Select customer_id, product_id,
            Sum (sales_amount) AS total_amount
            From customers 
            Group by customer_id

At this point, the code has changed in your code editor but no permanent version of this on Git, so this is the working directory. The changes haven’t been committed; it tells you I can see the changes, but you haven’t told me to include them in Git.

Staging area

This is the preparation stage for me, like telling Git to take this screenshot and prepare it for a more committed state. Include these changes in my next commit. If we were working on a data analysis project, you would tell Git to bash.

</>Bash
Add sql/analysis.sql

Then check the status

</>Bash
git status

The result will be

changes to be committed:
    Modified: sql/analysis.sql

The file is now staged, and Git lets you choose which changes to include in your next commit.
We move changes from the Working Directory into the Staging Area using:
git add <filename>
Or, to stage everything that has changed:
git add

Staging gives a chance to know what to commit at each stage, making it clear and clean, and it is a preview stage.

The commit (Local Repository)

Now, since our changes have been staged, we save them permanently to project history using the commit command.
git commit -m "A clear, descriptive message about what changed"
like; </> bash

git commit -m "Added customer sales analysis"

This creates a commit that is a snapshot of the changes that you have made and is stored in the local repository. We also know that the commit at this stage has a unique ID, the author's email and name, a commit message, and a timestamp, including the reference to the previous commit.
The commits at this stage are stored locally; no one can access them, and they are a permanent safe place where you can come back to refer to if you make any errors at a given point.

The Push (Remote Repository)

Everything that we have been doing from the beginning to this point has just been happening on our computers or on our code editor platform; to share this information with our team, like we have been working on the health report in Kenya, and we have been cleaning that data, and we want to share those changes we have made, we have to push the commits to a Remote Repository like GitHub or GitLab. This can be achieved through;
git push origin main
Here, origin is the default name Git gives to the remote repository you added manually, and main is the branch you're pushing to.
Once the changes have been pushed, the commit is available for access by anyone with access to your local repository. Now your work has been shared with your teammates. It is always a good habit to check for updates before pushing your commit.

These stages are more important as a beginner; I used to ask why you just save directly, as Google Docs does, then I realized that software projects sometimes are more complex. Git stages give you control over what to commit at each stage; you can make changes to any errors you may have before committing them or saving them permanently, and you can understand each stage of your project or code history. Without forgetting, pushing and pulling help you collaborate with others, making work easier.
Work you edit your file normally
git add <file> you make changes to be included.
git commit -m "message" saves permanently
git push origin <branch> uploads commits to be shared
git status shows what changed, staged.

Each stage exists for a specific reason.