What’s the proper full-cycle workflow?
——- LOCAL —–
git init – create repo
git add README.md
git commit -mInitial
git remote add origin
git push origin main <– pre-configured to allow push to create
git checkout -b feature/test
git add README.md
git commit -m”Updated README”
git push origin feature/test
—- REMOTE —
create pull request from feature/test -> merge to main
—- LOCAL —–
git checkout main
git fetch origin
git pull origin main
git checkout -b feature/test2
cycle repeats?
Checking the status of a local branch relative to main is a common workflow, but since Git is decentralized, your local machine doesn’t automatically “know” what happened on GitHub or GitLab until you sync up.
Here is the most reliable way to check if your branch’s work has been safely merged into main.
1. The “Merged” Command (Quickest)
The most direct way to check if a branch’s commits are already contained within your local main branch is using the --merged flag.
- Update your local view of the remote repository:
git fetch origin - Switch to your main branch:
git checkout main - List merged branches:
git branch --merged
If your local branch name appears in that list, its changes are officially part of main.
2. Using git cherry (The “Is my work there?” check)
If you want to see if the specific commits from your feature branch exist on main (even if they were squashed during the PR process), use git cherry.
- Command:
git cherry -v main <your-branch-name> - Reading the output:
- If the output is empty, all your changes are already in
main. - If you see lines starting with
+, those commits are not inmainyet.
- If the output is empty, all your changes are already in
3. Visualizing the Relationship
Sometimes it’s easier to see the “divergence” or “convergence” in a graph format.
- Command:
git log --oneline --graph --dot --decorate main.. <your-branch-name>
This shows you exactly what commits are sitting on your branch that haven’t made it to main. If it returns nothing, your branch has no unique commits left to merge.
4. Checking PR Status via CLI
If you use the GitHub CLI (gh), you can skip the git math and ask the API directly:
- Command:
gh pr status - Command:
gh pr list --state merged --head <your-branch-name>
This will tell you the literal status of the Pull Request linked to that branch.
Summary Table
| Method | Best For… |
git branch --merged | Checking if the branch is safe to delete. |
git cherry | Checking if specific work exists on main (even if squashed). |
gh pr list | Confirming the administrative status of the PR itself. |
Pro Tip: Once you’ve confirmed a branch is merged, you can clean it up and sync your local list with git fetch -p (prune), which removes references to remote branches that no longer exist.
The Refined Full-Cycle Workflow
1. The Setup (Once per project)
git initgit remote add origin <url>git push -u origin main(The-usets up “upstream” tracking so you can just typegit pushlater).
2. The Feature Cycle (The “Inner Loop”)
- Update Main first: Always start from the freshest code.
git checkout maingit pull origin main
- Branch:
git checkout -b feature/new-idea - Work:
git add/git commit - Push:
git push -u origin feature/new-idea
3. The “Sync” Step (What was missing)
If you are working on a feature for several days, main might move forward (someone else merges a PR). To avoid a mess later, pull main into your feature branch occasionally:
git fetch origingit merge origin/main(orgit rebase mainif you prefer a clean history).
4. The Remote Phase
- Create PR: Via GitHub/GitLab UI.
- Merge PR: Using the “Squash and Merge” or “Merge” button.
5. The Cleanup (What was missing)
After the PR is merged, your local machine still has that old branch. Clean it up so your git branch -vv stays readable:
git checkout maingit pull(Get the new merge commit you just created on the remote).- Delete local branch:
git branch -d feature/new-idea - Prune remote tracking:
git fetch -p(This tells your local git: “If the branch was deleted on GitHub, forget about it here too”).
Comparison: Your Workflow vs. The Pro Workflow
| Action | Your Version | The “Pro” Addition | Why? |
| New Branch | git checkout -b | git pull origin main first | Prevents starting work on an outdated version. |
| Pushing | git push | git push -u | Sets up a permanent link between local and remote. |
| Merging | PR on Remote | git fetch -p | Clears out “ghost” branches from your local list. |
| Old Branches | Keep them | git branch -d | Prevents the “left behind” branches you saw earlier. |
One Small Correction
In your example, you did:
git fetch origin
git pull origin main
Note: git pull actually performs a fetch and a merge in one command. If you are on main, you usually only need git pull origin main.
Summary Checklist for feature/test2:
git checkout maingit pullgit branch -d feature/test(Kill the old one!)git checkout -b feature/test2