Git Workflow

Git Workflow

Git Workflow provides essential version control capabilities for managing codebase changes cleanly, predictably, and efficiently.

Core Concepts & Explanation

---

• Working Directory - Where you make changes
• git add - Stage changes
• git commit - Save changes to your repository
• git push - Share changes with others
• git status - Check what's going on
• Undo/Amend - Fix mistakes (git restore, git reset, git commit --amend)

See Also: GitHub Flow is a popular collaborative workflow for teams using GitHub.

If you work with GitLab or Bitbucket, those platforms have their own workflows too. Learn more about GitHub Flow »

---

Git uses a distributed workflow that allows you to work on your code, stage changes, and commit them to your local repository before sharing with others.

Understanding this workflow is essential for effective version control.

The Three Areas of Git

• Working Directory : Where you make changes to your files.

• Staging Area (Index) : Where you prepare changes before committing.

• Repository : Where your committed history is stored.

  Workflow Diagram

  [Working Directory] --git add--> [Staging Area] --git commit--> [Repository]

---

• Commit frequently with clear, meaningful messages.
• Check your status often with git status to avoid surprises.
• Stage only what you intend to commit. Use git add <file> for precision.
• Push regularly to back up your work and share with others.
• Review your changes with git diff before committing.

---

---

Working Directory

This is where you make changes to your files.

Think of it as your workspace or desk.

Files here can be new, modified, or deleted, but Git won't save these changes until you stage and commit them.

---

Staging Changes (git add)

When you are happy with your changes, you "stage" them with git add.

This puts your changes in the Staging Area, like putting your finished letter in an envelope.

Example
git add index.html

To stage all changes (new, modified, and deleted files):

git add .

---

Committing Changes (git commit)

Committing saves your staged changes to your local repository.

It's like mailing your letter-you can't change it after it's sent!

Example
git commit -m "Describe your changes"

You can also use git commit -a -m "message" to stage and commit all modified and deleted files in one step (but not new files).

---

Pushing Changes (git push)

After you commit, your changes are only in your local repository.

Use git push to send your commits to a remote repository (like GitHub or Bitbucket) so others can see them.

Example
git push

---

Checking Status (git status)

Use git status to see which files are staged, unstaged, or untracked.

This helps you keep track of what you still need to add or commit.

Example
git status

---

Undoing and Amending Changes

Made a mistake? Git lets you fix things before you push!

• git restore <file> - Undo changes in your working directory (before staging).

• git restore --staged <file> - Unstage a file (move it out of the Staging Area).

• git reset HEAD~ - Undo your last commit (keeps changes in your working directory).

• git commit --amend - Change the last commit message or add files to your last commit.

  Example: Unstage a file
  git restore --staged index.html

---

Tips & Troubleshooting

• Use git status often to see what's going on.
• If you commit the wrong thing, use git reset or git commit --amend before pushing.
• Stage only what you want to commit-use git add <filename> for specific files.
• Don't forget to push after committing, or your changes won't show up for others.
• If you're not sure, ask for help or look up the error message-everyone makes mistakes!

---

---

Practical Terminal Workflow

Execute the following terminal commands to work with this concept in your workspace:

# Check repository status
git status

# View formatted log
git log --oneline -n 5

Best Practices & Pro-Tips

• Atomic Commits: Keep each commit small, focused, and dedicated to a single logical feature or bug fix.
• Imperative Commit Messages: Write commit titles in imperative mood (e.g., Fix CORS bug rather than Fixed CORS bug).
• Review Diff Before Staging: Run git diff to review unstaged modifications before adding files to the index.

Common Gotchas & Troubleshooting

• Detached HEAD State: Triggered when checking out a specific commit hash directly rather than a branch. Create a new branch with git switch -c <branch-name> to preserve edits.
• Accidentally Staged Binary Files: Run git restore --staged <filename> to remove the file from the index without altering your local workspace copy.

Self-Check Challenge

Open your terminal in a test project directory, execute git status, and verify your current working tree state. Practice running git log --oneline to review commit history.