Question

I’m writing an open source library. I’m using two remotes: one private repo for personal testbed and backup, and another one public hosted on github.

On the private repo, this is where I save and do a lot of commits and pushes with all the little changes like “fixed spelling” or “still working on bug #123!”. This is fine, and I’d like to keep it this way. Private repo will never be shared to anyone.

On the public repo on github, I want my git commit history to be clean. Merging several commits into one commit, e.g. “Fixed bug #123”.

The question is, how do I maintain two separate git history on two different remote repos?

I have been reading articles on git rebase. Would rebase change the entire history of that branch? If I rebase the history for the public repo, does the private repo also get rebased?

Would it be better if I maintain two branches? Is it possible that the public server only see one branch (as master), while the other sees both branches with detailed commits?

I’m not sure what would be the best practices are for this situation. Thank you for your time.

Answer 1

The question is, how do I maintain two separate git history on two different remote repos?

I wanna beware you, that branch should not be long-living. Long-living branch will become a mess one day because it should be synced with develop branch (or branch where your branch start from) that why you are encouraged to all that git rebase develop and so on.

Actually, it is hard to understand what is a benefit of having two versions of one branch in different remotes. What is a point of having this branch in your public repo which will contains single commit and have always been force updated? As for me it sounds like unusable nonsense.

How things is going on in real life:

• You publish your branch with all commits you have done;

• When feature is done and everybody is agree with merging this branch into a develop (or where it was created from) branch could be squashed into a single commit or could merged as is.

• Remote feature branch that you were working in should be deleted since it is merged to another branch and it will be not supplemented with any commits.

So, there is nothing to maintain at all except the branch that your branch is start from.

Answering a question literal:

If you wanna have a branch with single commit with all changes you have done in your current branch, you could do something like that:

• Get all changes that you have done in current branch. git diff ${SHA}, where ${SHA} is a last commit of a branch that your branch is start from.
• Redirect this diff to patch file > patch.diff.
• Checkout to ${SHA} with git checkout ${SHA}.
• Apply a patch with patch -p1 < patch.diff.
• Make a commit with git commit -m '...'.
• Rename branch whatever you want with git branch -m.
• Push it to remote with git push ${REMOTE_NAME} ${BRANCH_NAME}.
• Reset this commit before next pushing to public remote with git reset HEAD~1.

But all this looks bunch of ugly kludges that normal developer would never use :[