The Local Git Workflow

Git local workflow is the repeatable path from an edit to a recorded version. You change files in the working tree, choose the changes that belong together in the staging area, and create a commit in the local repository. A commit is a checkpoint in local history, so you can compare what changed between points in time.

These three areas are separate by design. The working tree contains the files you currently see and edit. The staging area, also called the index, contains the exact content selected for the next commit. The local repository stores commits and their history inside the hidden Git metadata directory. Understanding these boundaries explains why an edited file can be present but still absent from the next commit.

GitHub is not required for this workflow. You can initialize a repository, make commits, inspect history, and correct local work without an internet connection. A clone normally includes a remote named origin, but commits made after cloning still exist locally until a later push sends them to GitHub.

Create or Clone a Repository

Use git init when you are starting a project from files already on your computer. Run it from the project directory, not from a parent directory that contains many unrelated projects. The following commands create an empty directory, enter it, initialize Git, and inspect its initial state.

mkdir git-workflow-demo
cd git-workflow-demo
git init
git status

The init command creates a hidden .git directory containing the local repository data. The status command should report that the working tree is clean because no project files have been created yet. The exact initialization message can differ according to your Git version and default branch configuration.

Use git clone when a repository already exists on a remote service. Replace the placeholder URL and directory name with a repository that you can access. Cloning downloads the current files and history, creates a new local directory, and normally records the source as the remote named origin.

git clone https://github.com/OWNER/REPOSITORY.git
cd REPOSITORY
git status

A clone is already a Git repository, so running init inside it is unnecessary. If the command fails with an authentication or repository-not-found error, check the URL, your access permission, and whether the network is available. A successful clone usually leaves the working tree clean because the downloaded files match the latest commit.

Inspect and Stage Changes

Inspect the repository before changing its history. The short status format is useful for a quick overview, while the regular status output gives more context. The following example creates a file, stages it, adds another working-tree change, and compares both versions.

printf '%s\n' 'First line' > notes.txt
git status --short
git add notes.txt
git diff --staged
printf '%s\n' 'Second line' >> notes.txt
git status --short
git diff
git diff --staged
git add notes.txt
git diff --staged

Before staging, status reports notes.txt as untracked, commonly shown as ?? notes.txt. After the first add operation, the file is selected for the next commit, and the staged diff shows its first line. Appending the second line changes only the working tree, so status can show AM notes.txt: A is staged content and M is a later modification that is not staged yet.

The regular diff compares the working tree with the staged version. The staged diff compares the staging area with the last commit, or with an empty starting point when the file is new. Running add again updates the staged snapshot to include the second line. This distinction lets you review exactly what a commit will contain before creating it.

The command git add . stages changes below the current directory, which is convenient but broad. It can accidentally include generated files, temporary files, or unrelated edits. Review status and the staged diff after using it. A project-specific ignore file can prevent common generated files from appearing as candidates, but ignoring files does not replace careful review.

Commit and Review History

A commit records the content currently in the staging area. It does not automatically include every modification in the working tree. Use a short, specific message that describes the completed change, then inspect both the resulting status and the history.

git commit -m 'Add notes file'
git status
git log --oneline --decorate --graph
git show --stat --oneline HEAD

A successful commit reports a commit identifier, the message, and a summary of changed files. Status should report a clean working tree if no later edits exist. The log command shows commits with the newest entry first. The show command summarizes the commit referenced by HEAD; replacing the stat option with a full show command displays the actual patch as well.

The first commit may fail with an Author identity unknown message. Git needs a name and email in commit metadata, but this setting is separate from GitHub authentication. Configure it globally for all repositories, or omit the global option when the identity should apply only to the current repository.

git config --global user.name 'Your Name'
git config --global user.email 'you@example.com'

Use your real name and an email address appropriate for your contribution settings, then retry the commit. Do not create an empty commit just to clear an error; first confirm that the intended files are staged and that the identity configuration is valid.

Complete Practice Workflow

The following short lab combines the local workflow in a fresh directory. Run it from a parent directory where local-workflow-lab does not already exist, or choose another directory name. The commands create two files, make an initial commit, add one later change, and make a second commit.

mkdir local-workflow-lab
cd local-workflow-lab
git init
printf '%s\n' '# Local Workflow Lab' > README.md
printf '%s\n' 'Review status before committing' > checklist.txt
git status --short
git add README.md checklist.txt
git diff --staged
git commit -m 'Create local workflow lab'
printf '%s\n' 'Review history after each change' >> checklist.txt
git diff
git add checklist.txt
git diff --staged
git commit -m 'Extend the workflow checklist'
git log --oneline --decorate
git status

The first status check should identify both files as untracked. After adding them, the staged diff should show the complete initial contents. The first commit then records both files. The later append is visible in the working-tree diff but is not part of the first commit until the checklist file is staged again.

After the second commit, the log should show two commits, with the second message at the top. The final status should be clean. This exercise does not require GitHub, a remote, or a network connection, which makes it useful for verifying your understanding of local state before introducing collaboration commands.

Common Errors and Summary

A frequent confusion is expecting the regular diff to display an untracked file. Git has no previous tracked version with which to compare an untracked file, so status identifies it while the regular diff may show nothing. Stage the file and inspect the staged diff, or confirm the filename and directory before continuing.

The message nothing to commit, working tree clean is normally a successful result, not an error. It means there are no staged or unstaged changes. If you expected a change, check that you edited the repository you intended, used the correct filename, and staged the latest version after editing it.

The error not a git repository means the current directory is not inside a repository. Move into the directory created by init or clone, or initialize the intended project directory. A pathspec error usually indicates a misspelled path or a command being run from the wrong directory. Check status before repeating the operation.

The complete local loop is inspect, edit, inspect again, stage, review the staged diff, commit, and review history. Once this loop is predictable, GitHub operations such as push and pull become easier to understand because they transfer or retrieve commits rather than replacing the local workflow.