Home/ Questions/Q 9269835
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-18T15:13:18+00:00

We use Git to manage and deploy code. I’m on the Ops team and

  • 0

We use Git to manage and deploy code. I’m on the Ops team and I do deployments. Our developers make changes and push code into Github, and we (Ops) use some managed processes to pull production code and deploy it.

The process is like this:

Background

  • Developers do stuff. That stuff ends up in Github and the Devs tell us so.
  • We have a local “staging” clone, and a local “deployment” bare git repo. The local git clone has two remotes, Github as “origin” and the local bare repo as “deploy”
  • We use chef on the web servers to actually deploy the code via the chef git resource that pulls from the “deploy” remote
  • We have the “deploy” remote so that there is a gating mechanism between Dev finishing stuff and our deployment timing. (Rather than deploying from Github directly)

Actual deploy Process

  1. cd into local clone
  2. git checkout branchname
  3. git pull origin branchname
  4. git push deploy branchname

All of this is partially automated, and is moving to full automation. As such, we are careful to not ever make local changes to the staging clone, and we expect that the output of git status in that clone will only ever be nothing to commit (working directory clean)

However, we had a weird message come up this week. The deploy clone is stating that it is 80 commits ahead of origin! Even though it also says nothing to commit.

# On branch branchname
# Your branch is ahead of 'origin/branchname' by 80 commits.
#
nothing to commit (working directory clean)

Finally, there isn’t really a problem, per se. The commit SHA256 hash matches in this clone, and on the deployed code on all of the web servers. I didn’t do an actual rsync comparison, but I’m pretty confident that the actual code itself is deployed correctly.

I want to know how this could happen, if it is bad, and how to clean it up short of deleting the local clone and starting over.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If both deploy and local repos have been cloned from the same ‘origin‘ (GitHub), your process shows that only local is doing a git pull origin.

    The repo deploy never fetches anything from origin (it only receives commits from local).
    That means deploy still believe having commit that would not be on origin (at least the origin it knows about).
    A simple git fetch origin executed from the deploy repo would make that status cleaner.

    • 0