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?

  • Can't switch branch: untracked working tree file because of case-insensitivity?
  • git branch --merged using plumbing commands
  • In Visual Studio Code How do I merge between two local branches?
  • .gitignore won't ignore the directory
  • Specific GIT app as PIP package install requirement
  • What are currently the problems with Git on Windows
  • What kind of Git workflow suits our case?
  • Cloning a Single File from Github Repo
  • Is it possible to set a git commit to have a timestamp prior to 1970?
  • Is there any test GIT repository available?
  • git checkout — . vs git checkout
  • How do I check for valid Git branch names?
  • 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
    ...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 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

    http://nvie.com/posts/a-successful-git-branching-model/

    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.