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.

  • Retrieve old version of a file without changing working copy parent
  • What is a practical workflow for keeping local changes uncommited in git?
  • Is a DVCS useful for one developer?
  • GitHubs Process for Initial Commit
  • Source Control - Distributed Systems vs. Non Distributed - What's the difference?
  • Is it true in Mercurial (hg), the same as Git, that a revision you committed may only have code not modified by you? (a merge)
  • 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.

  • Updating the Git index failed, LF will be replaced by CRLF?
  • What is this grey git icon?
  • How to find the N largest files in a git repository?
  • Webstorm uses wrong git user
  • How to fix permission denied for .git/ directory when performing git push?
  • Is there an equivalent of git-walk next / git-walk prev in hg?
  • 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.