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:
git branch remoteA/newfeatureStep 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:
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:
git branch remoteA/newfeature
git checkout -b work-newfeaturegit rebase newfeature