问题
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
回答1:
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:
- set environment variables
- pass arguments via command line
- run some script which replaces tokens with the configuration values
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...
来源：https://stackoverflow.com/questions/33132092/branching-forking-just-portion-of-parent-repository