CODEWITHSUNDEEP
gitgithubbitbucket
Jan
Jan

Reputation: 1975

Branching/Forking just portion of parent repository

We have a codebase on bitbucket which has some 'confidential' libraries. Is there a way to create branch or fork for investigation purposes (for off-site workers) that will not contain chosen confidential files, but for all other files there still will be ability to push, pull, see entire history?

I've been able to achieve this in other source controls by specifying advanced mapping of files/folders between branches, but I'm not able to find similar functionality on bitbucket.

EDIT1: Here is an example of what I want to achieve:

Repo1(main):
 |-publicFolder
    |-file1
    |-file2
 |-privateFolder
    |-fileA
    |-fileB

Repo2(investigation):
 |-publicFolder
    |-file1
    |-file2

There would be unlimited possibility to push/pull public files across those repos. Remote worker works on publicFolder and can pull latest version from main repo and is able to push his changes to main repo (or some admin is able to pull from investigation repo to main repo). But worker with access to Repo2 only should never be able to view the privatFolder

Upvotes: 2

Views: 696

Answers (1)

Aaron Blenkush
Aaron Blenkush

Reputation: 3059

There's no way to do this within a single Git repository. BitBucket does not have additional functionality on top of Git that would allow some files to be restricted (it would mess with the identity of the commits which would change the checksums, etc). However, this is a common problem, and the best way is to keep sensitive data separate. I can think of a few ways to do this.

1. Configuration file

Sometimes it suffices to just keep a simple configuration file outside of source control that you can use to load in runtime values in some way: for example:

Still, your question is how to keep a part of your codebase private. There are many ways to handle this; it all depends on how your project is structured, how you manage builds, deploys, etc.

2. Multiple forks

One way is to maintain multiple forks, such that you have private and public repositories. Only place sensitive commits on a private repository. This way your codebase is still a single module, if you prefer.

3. Multiple modules

As any project grows, it often makes sense to split the software out into separate modules or repos (e.g. core, web, config, test, etc). To checkout and build the project, you would checkout the multiple modules and compile them together. Some build tools can manage this automatically for you, like maintaining snapshot builds in your local ~/.m2 repo. One of the first things you can do is separate the production configuration into a separate module that is restricted. Then you might have another repo with development configuration.

4. Don't do this...

if (file_exists('c:/windows/win.ini')) {}

Upvotes: 2

Related Questions