Home/ Questions/Q 6964675
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T15:57:17+00:00

I’m following the the workflow described here , as I found many references pointing

  • 0

I’m following the the workflow described here, as I found many references pointing to this page as a good workflow. As mentioned in the article, “feature” branches are shared between developers, but do not go to the central repository.

Let’s say a developer “A” starts a new feature branch with git checkout -b newfeature develop. Now let’s say that developer “B” needs also to work on this feature. This is my problem.

What I did:

  1. developer “B” adds developer A’s machine as a remote
  2. developer “B” runs git branch remoteA/newfeature
  3. developer “B” works on this branch, commit his work and pushes the changes back to remoteA.

Step 3 is not working, right now. I get a message:

remote: error: By default, updating the current branch in a non-bare
repository is denied, because it will make the index and work tree
inconsistent with what you pushed, and will require ‘git reset –hard’
to match the work tree to HEAD.

remote: error: You can set ‘receive.denyCurrentBranch’ configuration
variable to ‘ignore’ or ‘warn’ in the remote repository to allow
pushing into its current branch; however, this is not recommended
unless you arranged to update its work tree to match what you pushed
in some other way.

remote: error: To squelch this message and still keep the default
behaviour, set receive.denyCurrentBranch’ configuration variable to
‘refuse’.

I have already set sharedRepository = true, but it did not help.

I have 2 questions:

  1. what’s the correct way to share feature branches between developers?
  2. how can I push back the changes in developer B’s repository to developer A’s original one?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You can push to a non-bare repo. What you cannot do is push to a non-bare repo that has the branch that you are pushing to checked out. The reason for this should make sense. Changing the files that someone else is possibly working on would be incorrect.

    Typically you will want to push to master or some other common shared branch. In order to avoid this conflict, the owner of the remote non-bare repo should work on a local branch or at least some other branch. Then you can push to the shared branch.

    To use your example:

    1. developer “B” adds developer A’s machine as a remote
    2. developer “B” runs git branch remoteA/newfeature
      1. developer “A” does work on a local branch. git checkout -b work-newfeature
    3. developer “B” works on this branch, commit his work and pushes the changes back to remoteA.
      1. Developer “A” rebases to get the new work: git rebase newfeature
    • 0