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.
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.
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.