Setting up Git collaboration workflow on remote server via SSH

Other Questions workflow
1

My colleague and I are collaborating on a coding project using a shared server that we access through SSH. We’ve set up Git repositories but I’m running into some warnings that I’m not sure about.

Here’s our current setup:

  • My colleague initialized a bare repository called project.colleague.git using git --bare init
  • I created my own copy by cloning their repo to project.myname.git on the same server
  • Then I cloned my server repository to my local workstation with git clone myname@server:/repos/project.myname.git
  • I develop locally and push changes back to my server repo using git push origin master
  • To get my colleague’s updates, I pull from their repository with pull myname@server:/repos/project.colleague.git

The workflow functions correctly, but now I’m getting this warning message when pushing:

warning: updating the current branch
warning: Updating the currently checked out branch may cause confusion,
warning: as the index and work tree do not reflect changes that are in HEAD.
warning: You can set 'receive.denyCurrentBranch' configuration variable to
warning: 'refuse' in the remote repository to forbid pushing into its
warning: current branch.

Should I be concerned about this warning? Everything appears to work fine and my colleague can still pull my changes. Is there a better way to structure our Git workflow on the shared server?

2

The warning you’re encountering indicates that you’re pushing to a checked-out repository rather than a bare one, which can lead to confusion regarding the current branch’s state since the working directory doesn’t reflect the latest changes. It would be more effective to convert your server repository into a bare repository by running git config --bool core.bare true and removing the current working files. This approach simplifies collaboration and avoids potential issues. Alternatively, you could use git config receive.denyCurrentBranch updateInstead, but bare repositories are typically the recommended practice for such scenarios.

3

Yeah that warning shows up constantly when teams try this. I hit the same issue on a project a few years back.

You’re mixing bare and non-bare repos. Your colleague set up a bare repo correctly, but you cloned it as regular instead of keeping it bare.

Delete your project.myname.git on the server and recreate it as bare:

rm -rf project.myname.git
git clone --bare project.colleague.git project.myname.git

Then update your local remote to point to the new bare repo.

Both server repos will be bare and the warnings disappear. Way cleaner too - server repos should just store code, not have working directories.

Workflow becomes: develop locally, push to your bare repo, colleague pulls from yours. No more server working directory headaches.

4

This warning shows up because your server repo isn’t bare - it’s got both a working directory and the git database. When you push to a non-bare repo with a checked out branch, Git can’t figure out what’s going on with the files. I’ve hit this same issue setting up shared repos. The cleanest fix is making both server repos bare from the start. For now, you can run git config receive.denyCurrentBranch ignore in your server repo as a quick fix, but I’d just recreate it as a proper bare repo with git clone --bare. That kills the working directory completely and turns it into pure git storage, which is what you want for collaboration anyway.