11

I would like to build specific flow on our company git.

  1. developer create a branch on his local machine and commit there some files.
  2. dev push this branch to remote repo
  3. Other devs cannot access to this branch
  4. after few rounds off pushing dev decide to publish his changes.
  5. merge his private branch into public branch
  6. push that public branch.

In the other words - is it possible to configure private remote branch in public repository?

Koziołek
  • 2,791
  • 1
  • 28
  • 48
  • Not an answer, but: Why do you want this? Is there some official requirement for secrecy? Is it just that devs are afraid to share their work? In general, it is helpful to be able to see each other's work in progress (helping each other out, picking up for someone who fell ill etc.). – sleske Jan 30 '15 at 14:27
  • 3
    Guys because my pc could crash, because code does not compile but I need to save it somehow, because I need "private" part in repository for experimental features. I met this in some project. But they use SVN and set up two "streams" private for everyday development and public to deliver complied features – Koziołek Jan 30 '15 at 14:34
  • 1
    @Koziołek: The question was: Why is it necessary to deny other devs access to the branch? Can't it be separate but public? – sleske Jan 30 '15 at 14:47
  • @sleske, we would like just copy behaviour of that SVN configuration. (personally it is stupid, but we have to) – Koziołek Jan 30 '15 at 20:49
  • @sleske A typical reason for keeping your branch private is you don't want your client to see your progress, especially if you are on a fixed-price contract, but you want to regularly merge their public branch with your changes to avoid working on an obsolete code. – romanoza Nov 04 '17 at 17:48
  • @romanoza: Yes, that makes sense. However, with Git you would maintain a personal repo on your machine anyway, and you could choose not to push your work branch, making it effectively private. – sleske Nov 04 '17 at 22:06
  • @sleske i'm guessing it's for risk management. the private repository serves as a back up for changes that are still a work-in-progress. – Xel May 03 '21 at 09:26

2 Answers2

13

The flow that is used in my team is to have complete separate repositories for each team member in addition to origin on the main git server.

  1. Dev creates local branch on local machine and commits away
  2. At the end of the day (or whenever is suitable) dev pushes to his private repo git push jdoe-private my-cool-branch
  3. Dev decides he is happy for the work to be published and possibly merged so can tidy it up and rebase it with impunity
  4. Dev pushes his branch to origin git push origin my-cool-branch

The rationale for this setup for us is to allow devs to freely rebase and avoid the problems that can arise from upstream rebasing and also to have full backups. The separate repositories are only private by convention but would be easy to add access control if required. There is a lot of duplication of data but unless your repo is really huge, this is probably not a concern.

Scott Thomson
  • 158
  • 7
3

The common solution I know is to agree on "branch namespaces", by prepending some string to branch names. For example, branches that start with "private/" are for private experiments. You'd then get branches like

  • private/JohnDoe/refactoring-taxcalculation
  • private/JohnDoe/newGUILayout
  • private/JaneJones/Java8
  • private/TKirk/build-spaceship

That keeps the branches separate, and makes it clear what their purpose is. However, that way the branches are still public, because anyone can see and pull them.

If you want to restrict access to these branches based on user, you'd need to have some kind of branch-based access control. There is no such thing in core git, but some git hosting servers allow this (Atlassian Stash for example). I don't know of any server that allows these kind of private branches, but maybe there is one that allows it or lets you script a solution.

Note, however, that what you are asking for is rather unusual. The common solution is the one I outlined above.

sleske
  • 81,358
  • 34
  • 189
  • 227
  • gitolite has conception of restricting push access for some users to some branches. Like junior developer could not push to master branch. But anyway all branches are still readable – Alexey Ten Jan 30 '15 at 15:29
  • 2
    Surely it's enough that the branch name makes it clear that it's private? If there's someone on your team who would pull a such private branch and work with it, expecting it to stay stable, then I would say the problem is elsewhere than in your git workflow. – Andrew Spencer Mar 15 '17 at 16:02