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?

  • Maintaining two code bases that are 90% the same installed on two different servers that must be isolated from each other?
  • How do I use Git and Git Extensions?
  • XCode Workspace Integrity Error
  • Git: How to push a subdirectory to a separate branch of the same repository
  • using git to maintain a shared codebase
  • Master branch of the repository didn't keep all the changes - How is it possible?
  • Trimming Git Commits/Squashing Git History
  • Vim: Show current git branch in lightline status line without fugitive
  • How do I recover a repo after a Github for Windows crash?
  • Git pull error: “fatal: Couldn't find remote ref master” from Heroku
  • Do a wildcard filter of branch names
  • Git merge after hard reset
  • 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 (dev).

    The strategy should be to commit development changes to the development branch and push them to the dev remote repository:

    $git checkout dev 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 dev.

    The typical solution is to create two branches for that purpose, say development and master. You can push only master to the public repository with git push:

    git push (remote) master

    To make (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).

    Git Baby is a git and github fan, let's start git clone.