Git Workflow: Create a Branch, Commit, Push, and Create a Pull Request

Git works best when the workflow is simple and repeatable. A clean branch, a focused commit, and a clear pull request make it easier for reviewers to understand what changed and why.

This guide turns a common development flow into a practical checklist: create a feature branch, review changes, stage only what you intend to commit, push the branch, create a pull request for review, and merge approved work back to develop.

Quick Answer

Use a feature branch for every meaningful change. Start from the correct base branch, create a clear branch name, review your local changes, stage only the right files, commit once with a useful message, push the branch to the remote repository, and then create a pull request.

The safest Git workflow is not about typing many commands. It is about adding review checkpoints before the change reaches the main branch.

Key Takeaways

• Start from the correct branch before creating new work.
• Use a feature branch so changes stay isolated.
• Run git status before staging and committing.
• Stage only the files that belong to the change.
• Review staged files before creating a commit.
• Use a clear commit message that explains the purpose.
• Push the branch and create a pull request for review.
• Do not commit secrets, credentials, build output, or temporary files.

Step 1: Confirm The Current Branch

Before creating a new branch, confirm where you are starting from.

git branch --show-current

Most teams expect feature work to start from main, master, or a release branch. If you start from the wrong branch, your pull request may include unrelated commits or older changes.

This simple check prevents a common mistake: creating a feature branch from another unfinished feature branch.

Step 2: Create A Feature Branch

Create a branch that describes the work.

git checkout -b feature/precommit-hardening

A good branch name should be short but meaningful. Examples:

• feature/precommit-hardening
• fix/login-timeout
• docs/git-workflow-guide
• refactor/terraform-layout

Avoid vague branch names such as changes, update, or test. A reviewer should be able to understand the purpose before opening the pull request.

Step 3: Confirm The New Branch

After creating the branch, confirm that Git switched to it.

git branch --show-current

You should see the new branch name:

feature/precommit-hardening

This matters because all future commits will be attached to the active branch. It is a small checkpoint, but it can prevent accidental commits to the main branch.

Step 4: Review Repository Status

After making changes, check what Git sees.

git status

This shows modified files, untracked files, deleted files, and staged files. Use it before staging so you do not accidentally include unrelated work.

Look carefully for:

• files from another task,
• temporary files,
• generated output,
• local environment files,
• secrets or credentials,
• large files that should not be committed.

Step 5: Stage The Right Files

Stage only the files that belong to the change.

git add terraform

If the change is limited to one folder, staging that folder is cleaner than staging the entire repository. git add . can be useful, but it also makes it easier to include files you did not intend to commit.

For a safer workflow, stage deliberately:

git add path/to/file
git add path/to/folder

Step 6: Review Staged Files

Before committing, check exactly which files are staged.

git diff --staged --name-only

This command gives a clean list of files that will be included in the commit. If something does not belong, unstage it before committing.

Use this checkpoint to confirm:

• required files are included,
• unrelated files are not included,
• generated files are intentional,
• no secret or environment file is staged,
• the staged files match the pull request purpose.

Step 7: Commit With A Useful Message

Create the commit after staged changes look correct.

git commit -m "refactor(terraform): enterprise env layout and RG map-based deployment"

A useful commit message explains the type of change, the area affected, and the purpose. This format works well:

type(scope): short description

Common types:

The goal is not to make the message long. The goal is to make the history useful later.

Step 8: Push The Branch

Push the branch to the remote repository.

git push -u origin feature/precommit-hardening

The -u option sets upstream tracking. After that, future pushes from the same branch can usually be done with:

git push

Pushing the branch makes it visible to your remote platform, such as GitHub, Azure DevOps, GitLab, or Bitbucket.

Step 9: Create The Pull Request

After the branch is pushed, open your remote repository and create a pull request.

A good pull request should include:

• a clear title,
• a short summary of the change,
• why the change was made,
• files or areas affected,
• testing performed,
• screenshots or logs when useful,
• any risks or follow-up work,
• reviewers who understand the area.

The pull request is not just a merge button. It is the review point where teammates can check code quality, security, test coverage, naming, design, and deployment risk.

Pull Request Checklist

Before requesting review, confirm:

Step 10: Merge Back To Develop

After the pull request is reviewed and approved, the next step is to bring the approved feature work into the shared development branch.

Your command capture included this idea:

git pull origin develop
git branch --show-current
git checkout develop
git branch --show-current
git merge feature/precommit-hardening
git push -u origin develop

The important idea is simple: update the target branch, switch to it, merge the feature branch, then push the updated target branch. In practice, the safer order is to switch to develop first and then pull the latest develop changes.

git checkout develop
git pull origin develop
git branch --show-current
git merge feature/precommit-hardening
git push -u origin develop

What These Commands Do

In many teams, the merge happens inside the pull request interface instead of the command line. That is often safer because branch policies, required reviewers, and automated checks are enforced by the platform.

If your team merges manually from the terminal, make sure the pull request has already been reviewed and all checks have passed.

Common Mistakes

One common mistake is committing directly to the main branch. This makes review harder and can bypass normal team controls.

Another mistake is staging everything with git add . without checking what changed. That can include logs, generated files, local settings, or unrelated work.

A third mistake is using vague commit messages such as update or fix. These messages may feel quick now, but they are not helpful when someone reviews history later.

The final mistake is pushing a branch and forgetting to create the pull request. Pushing shares the branch, but the pull request creates the review workflow.

Another mistake is merging into develop before pulling the latest remote changes. That can create avoidable conflicts or cause the local branch to miss recent team updates.

Best Practice Workflow

1. Start from the correct base branch.
2. Create a feature branch.
3. Make the change.
4. Review git status.
5. Stage only related files.
6. Review staged files.
7. Commit with a clear message.
8. Push the branch.
9. Create a pull request.
10. Wait for review and checks.
11. Refresh develop.
12. Merge the approved feature branch.
13. Push the updated develop branch.

Official Resources

• Git documentation: git branch
• Git documentation: git checkout
• Git documentation: git status
• Git documentation: git commit
• GitHub Docs: About pull requests

Related AI Charcha Reading

• Cursor Setup Guide for Developers
• How to Create an AI Usage Policy
• How to Review AI Outputs Before Publishing

Bottom Line

A good Git workflow gives every change a clean path: branch, review, stage, commit, push, pull request, approval, and merge.

The commands are simple, but the discipline matters. Review before staging, review again before committing, use the pull request as the quality checkpoint, and merge into develop only after the target branch is current and the change is approved.

Final Command Reference

Feature branch workflow:

git branch --show-current
git checkout -b feature/precommit-hardening
git branch --show-current
git status
git add terraform
git diff --staged --name-only
git commit -m "refactor(terraform): enterprise env layout and RG map-based deployment"
git push -u origin feature/precommit-hardening

Merge approved feature work into develop:

git checkout develop
git pull origin develop
git branch --show-current
git merge feature/precommit-hardening
git push -u origin develop