Git: make a branch as master on Github while keeping real master on BitBucket

Question

I have a project that is hosted on bitbucket as a private project. The project is now public by trimming many source codes and configurations from the root project. I have put the public project on github.

Since it is an internal project, I keep working on the project in git manner, then push any public appropriate changes to the project on github. I have been managing two projects using SVN on both since SVN was the tool that had been used originally before Git. As I push more stuffs from internal to public, I feel this is really stupid way to do it.

I think the public project should be the master, since internal project has many additions on top of what is public, but I want to stay away from github for the internal project.

theProject(on github)

   ->(branch)theProject_INTERNAL(on bitbucket)

I want to continue working on 'theProject_INTERNAL' and only merge some changes to 'theProject' while keeping the internal project absolutely forbidden to the public.

How can I achieve this without much headaches with Git?

Answer 1

Use a tracking branches. Suposing master branch of BitBucket has the changes you'll release to public, on GitHub repository:

$ git checkout -b master_of_bitbucket_on_github remote_bitbucket/master

This will create master_of_bitbucket_on_github branch on GitHub repository, that will track master branch of BitBucket.

If it isn't done, you'll need to configure remote branch remote_bitbucket.

Or you can do the opposite: create a tracking branch on BitBucket repository tracking a branch of GitHub if you want no reference to your private repository on GitHub repository.

Answer 2

Develop every feature on a seperate INTERNAL feature branch (which you just push there) and when you feel, that your code is fine for public rebase that branch on top of the public branch (see: http://git-scm.com/book/de/Git-Branching-Rebasing) and push

the advantage is, that you do not need to push everything.. and you can do a dry - run locally before publicly doing sth wrong..

but what I dont get is, what do you need svn for? (which is good, because svn is really bad anyway)

Answer 3

You can always have as many public and private branches as you want. What makes them private is correct settings of remotes.

If it was a new project, I'd go about something like:

1. Create public project on GitHub

2. Clone it to a private machine (my workstation)

   Hint: rename "origin" to something else to minimize confusion

3. Add another remote: bitbucket

4. Create a local branch based on master

5. Push the branch to bitbucket

(I'm using similar system for my dotfiles collection: I have a "private" branch that only exists in a bare repo on my station, and I clone it to the station and a few virtuals.)

When working, you want to be sure:

• obviously, that you don't accidentally commit + push something private to the public branch

• that the private branch is set up correctly to follow the bitbucket remote, not the "origin", i.e. GitHub

If you want use different machines to work on the project, consider creating own bare repository (maybe somewhere in your private network) where you can add as many pre-commit checks and hooks as needed (you can even grep content of source files).

That will make it easier to deploy the repo on another machine, plus can help reduce dependency on network or bring some access control in place.

---

Here's the final schema including the proxy:

.------------------------------------------------------------------------------.
:                              .                            .                  :
:   [github.com] ----------.   .   [bitbucket.org]-.        .                  :
:       branches:          :   .       branches:   :        .                  :
:           master         :   .           private :        .                  :
:                          :                       :             the internets :
:--------------------------:-----------------------:---------------------------:
:                          :                       :             all your base :
:   [local_git_proxy]      '.....................  :                           :
:       remotes:                                :  :                           :
:           public   git://github.com/...or.so..'  :                           :
:           private  git://bitbucket.org/...or.so..'                           :
:       branches:                                                              :
:           master set up to follow public/master                              :
:           private set up to follow private/private                           :
:           any other team branches                                            :
:       hooks:                                                                 :
:           hooks to prevent you from leaking data to public                   :
:           maybe some hooks to automate pushing/fetching                      :
:                                                                              :
:   [actual_dev_machine]                                                       :
:       remotes:                                                               :
:           origin:  git://local_git_proxy/...or.so...                         :
:       branches:                                                              :
:           master set up to follow origin/master                              :
:           private set up to follow origin/private                            :
:           your own "crazy" branches                                          :
:                                                                              :
'------------------------------------------------------------------------------'