How to keep a second git remote repository for selected commits (states)
I want to keep two separate git remote repositories for a project (while having one local copy). One should be the development repository and one should be the representative public repository. I want the public repository to contain only selected states, i.e. I want to commit only the stable versions without the in-between history of small commits. As far as I understand Git if I just commit every now and then to the public repository it will automatically update the whole history of commits. Is there a way around this?
4 Solutions collect form web for “How to keep a second git remote repository for selected commits (states)”
The answer to my question is based on the answer of @Andomar and the blog post recommended by @Michael Durrant.
Different branches could be used for releasing (
master), development (
development), hotfixes (
hotfix), etc. Each branch can be pushed to a different remote repository — a public one (
origin) or one for development (
The strategy should be to commit development changes to the
development branch and push them to the
dev remote repository:
$git checkout dev ...do some changes... $git commit -m "some development change" $git push -u dev development
After a new release point is reached the
development and the
master branches should be merged using
--squash, which packs all commits made to the development branch in one commit, which prevents the development history from appearing on the master branch.
$git checkout master $git merge --squash development $git commit -m "<new release message>" $git push -u origin master
This will result in a single commit on
origin that will contain all the development changes since the last release, thus hiding the development history contained in
The typical solution is to create two branches for that purpose, say
master. You can push only master to the public repository with
git push (remote) master
(remote) only track
master by default, use git remote:
git remote set-branches (remote) master
I recommend using a strategy of
Basically you have a development branch for work-in-progress and a master branch that represents production.
Further, you make branches from development for individual features, bug fixes or chores.
You then merge these branches into the development branch where you can do integrated testing and then to a release branch where you can do QA.
When ready to release you merge release into master and push to the production server.
When you need to make a hot fix you do it to the release branch.
Think “selected history” instead of “selected commits.”
git push is opt-in for branches by default, so you can choose to only push a
stable branch (for example) to a particular remote. However, you cannot push a branch without pushing all of the history leading up to it – a branch’s head commit is defined by its parent(s), content (aka “tree”) and some metadata (author, committer, message, etc).