Basic Git Workflow

Basic Git Workflow

Understanding Git commands individually is useful, but what really builds confidence is knowing how those commands fit together into a repeatable process. The basic Git workflow is that process. It is the cycle that every developer follows every time they make a change to a project, from editing a single line of code to shipping a complete feature. Once this cycle becomes familiar, working with Git starts to feel natural rather than mechanical.

This workflow applies whether you are working alone on a personal project or contributing to a shared codebase with dozens of developers. The same fundamental steps repeat continuously throughout the life of any Git-managed project. If you are not yet comfortable with the underlying ideas behind these steps, revisiting Git core concepts will help everything here make more sense.

The Workflow at a Glance

The Git workflow moves through a predictable sequence of stages. You make changes in your working directory, prepare those changes in the staging area, save them permanently with a commit, and optionally synchronize with a remote repository. Each stage has a clear purpose, and understanding why each one exists is just as important as knowing how to execute it.

1. Edit files in your working directory
2. Stage selected changes using git add
3. Commit staged changes using git commit
4. Push commits to a remote repository using git push
5. Pull updates from collaborators using git pull

This cycle repeats continuously as your project grows. Each iteration produces a new permanent snapshot in the project history that can be inspected, compared, or restored at any time.

Step 1: Editing Files in the Working Directory

Every workflow iteration begins in the working directory, which is the actual folder on your computer containing your project files. You open files, write code, fix bugs, update content, or delete things that are no longer needed. This is ordinary file editing with no Git-specific behavior required. Git observes the folder passively and notices what has changed compared to the last committed state, but it does not record anything automatically.

At any point during this stage, you can ask Git for a summary of what it has detected using the status command.

git status

The output will show which files have been modified since the last commit, which new files exist that Git has not seen before, and which files have been deleted. Running git status frequently is a good habit because it always gives you an accurate picture of where things stand before moving to the next step.

Step 2: Staging Changes

Once you have made some changes you are ready to save, the next step is to move them into the staging area. The staging area is an intermediate zone where you assemble exactly what you want to include in the next commit. This step exists because real development work is rarely perfectly organized. You might have edited three different files for three different reasons, and the staging area lets you separate those changes into distinct, focused commits rather than bundling them all together.

You stage changes using git add. You can stage a specific file by name or stage everything that has changed at once.

# Stage a specific file
git add file.txt

# Stage all changes in the current directory
git add .

After staging, running git status again will show your changes listed under the staged section, confirming they are ready to be committed. Anything not staged yet remains in the working directory and will not be included in the next commit until you stage it explicitly.

Step 3: Committing Changes

With your changes staged, you are ready to commit. A commit takes everything currently in the staging area and saves it as a permanent, uniquely identified snapshot in the repository's history. Every commit requires a message that describes what the change does. That message becomes part of the permanent record and will be read by you and your collaborators when reviewing the project history later.

git commit -m "Fix broken navigation link on homepage"

A good commit message is specific enough to understand the change without reading the code. Vague messages like "update" or "fix stuff" make the history harder to navigate, especially when you are trying to find the source of a bug weeks later. Writing meaningful commit messages is one of the most valuable habits you can develop and is discussed in detail in Git best practices.

Step 4: Pushing Changes to a Remote Repository

Commits made locally exist only on your machine until you push them to a remote repository. Pushing uploads your local commits to the remote, making them visible to collaborators and creating an off-machine backup of your work. If your repository is connected to a remote named origin, which is the default name assigned when you clone a repository, you push your current branch like this.

git push origin main

You do not need to push after every single commit. It is perfectly normal to accumulate several local commits before pushing them all at once. However, pushing regularly means your work is backed up and your collaborators can see your progress. The details of working with remotes are covered in working with remote repositories.

Step 5: Pulling Updates from Others

When you are working with a team, other developers are pushing their commits to the same remote repository while you are working locally. To bring those changes into your local repository, you use git pull. Pulling fetches the latest commits from the remote and merges them into your current branch, keeping your local copy in sync with the shared state of the project.

git pull origin main

A common practice is to pull before you start working each day and before you push your changes, so that your local branch reflects the most recent shared state. This reduces the chance of conflicts and makes merging smoother. The distinction between fetching and pulling, and when each is appropriate, is explained in fetching and pulling changes.

A Typical Day Using This Workflow

Seeing all five steps together in a realistic sequence makes the workflow easier to internalize. Here is what a typical development session might look like from start to finish.

# Check the current state of your working directory
git status

# Pull the latest changes before starting work
git pull origin main

# Make your edits, then stage them
git add .

# Commit with a clear message
git commit -m "Add form validation to the contact page"

# Push your changes to the remote
git push origin main

This sequence becomes second nature with practice. The entire cycle takes only a few seconds to execute once you know what each command does and why it belongs in the sequence.

Branches and the Workflow

In real projects, you rarely work directly on the main branch for every change. Instead, professional workflows involve creating a dedicated branch for each feature, bug fix, or experiment. You follow the same add, commit, and push cycle on that branch, and when the work is complete and reviewed, the branch is merged back into the main branch.

Working on branches keeps the main branch stable and deployable at all times while development continues in parallel. This is a small addition to the basic workflow that makes a significant difference in how organized and safe your project history becomes. Branching is covered fully in Git branching fundamentals.

Common Workflow Mistakes to Avoid

Several common mistakes can disrupt the flow or create problems that take time to untangle. Knowing them in advance helps you avoid them.

• Committing without staging: Running git commit without first running git add will either produce an empty commit or not behave as expected. Changes must be staged before they can be committed.
• Writing vague commit messages: Messages like "fix" or "changes" are not useful when you are reviewing history later. Specific messages like "Fix null pointer error in user login function" tell you exactly what happened at that point.
• Pushing without pulling first: If collaborators have pushed changes to the remote since your last pull, pushing without pulling first will likely result in a rejected push. Pulling first keeps things in sync.
• Working entirely on the main branch: Making all changes directly on the main branch bypasses the safety that branches provide. If something goes wrong, the entire main branch is affected rather than an isolated feature branch.

If mistakes do happen, Git provides a range of tools for recovering from them. These are explained in undoing changes in Git.

Frequently Asked Questions

1. Do I need to push after every commit?
   No. You can accumulate multiple local commits and push them all at once. Pushing regularly is good practice for backup and collaboration, but there is no requirement to push immediately after each commit.
2. Can I commit directly without using git add?
   You can use git commit -a to automatically stage and commit all tracked modified files in one step, but this skips the staging area and does not include new untracked files. Using git add deliberately gives you better control over exactly what each commit contains.
3. What happens if I forget to pull before pushing?
   Git will reject the push if the remote has commits that your local branch does not have. You will need to pull first, resolve any conflicts if they exist, and then push again.
4. How often should I commit?
   Committing frequently is generally better than committing rarely. Small, focused commits are easier to understand, easier to review, and easier to revert if something goes wrong. A useful rule of thumb is to commit whenever you complete a small, logical unit of work.
5. What should I learn after this workflow?
   The natural next step is understanding how to inspect what you have done. Visit viewing history and changes to learn how to read the commit log, compare file versions, and understand the full record of your project's evolution.

Conclusion

The basic Git workflow is the core loop that everything else in Git builds around. Edit, stage, commit, push, and pull. These five actions, repeated consistently and deliberately, give you a clean and trustworthy project history, reliable collaboration with others, and the confidence to make changes knowing that nothing is ever truly lost.

As you grow more comfortable with this cycle, you can begin layering in more advanced techniques. Explore viewing history and changes to deepen your understanding of what Git has recorded, and then move on to branching and merging to see how parallel development fits into this same foundational workflow.