Git workflow idea to push an unfinished local branch to remote for backup purposes

Say I’m currently working on a new feature which I’ve branched off of the ‘dev’ branch and I’ve been working for several days and it’s not yet ready to be merged with ‘dev’ and pushed.

Although I have made several commits and have been pulling changes to dev and then merging dev into my feature branch to keep myself updated.

  • Make shell prompt show current head when in a VCS
  • What is the Difference Between Mercurial and Git?
  • Can 'git status' be configured so that it won't provide help text?
  • What is the best practice for pushing clean code to the main branch in Mercurial?
  • Using Git with VB6
  • hg equivalant of git revert
  • Here’s my question. Is it a good idea to push my feature branch to a new branch (with the same name as my local branch) onto origin (say GitHub) just for back-up purposes and later on when it’s merged into ‘dev’ and/or ‘master’ delete it from origin.

  • How do I maintain only the latest snapshot of my git commit history?
  • git: how to revert file which is in .gitignore
  • Additional changes in a merge commit
  • How to linearize “splintered” merging history in Git?
  • Git conflicted copy error while cloning a repository
  • git on Mac: replace Apple XCode CLI git with symbolic link to latest git install?
  • 3 Solutions collect form web for “Git workflow idea to push an unfinished local branch to remote for backup purposes”

    Each developer should have their own clone remote-repository. This way they can branch and tag and to whatever they want and have it backed up on the remote location.

    When a developer’s changes are QA’ed and approved for publish, they should be merged into the master repository, even if they’re on a different branch.

    This way you have a local/remote copy of all your changes on all branches, but only completed/approved changes make it into the production repo, because it’s a merge, all commit history is included and you get a nice workflow.

    That sounds reasonable.
    If nobody pulls from that branch, I would have recommended to rebase your feature branch on top of dev, instead of merging dev directly in feature.
    That can avoid a messy history (if several features are developed on dev)
    But aside that detail, pushing it to the GitHub repo is a viable workflow (if nobody try to pull and merge that branch, that is, so a good naming convention is in order).
    If your GitHub repo is a fork of a main project, you definitively can push your own branch and delete it later.

    I see no harm in pushing back to your own remote repository for backup purposes, but if you’re building feature branches that big, you might examine your development methodology:

    You might be building too much at once and should break the feature you’re developing in your feature branch into a number of smaller tasks. This will make merging back into your development branch a bit easier.

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