Is Pushing Feature Branches to Origin Good Practice?
design-patterns, git
Solution
It depends.
If someone is working on a feature and want to share it with other devs it makes total sense. But if it's a feature that you are working on alone, why push that to the server if you don't need to share it? It will eventually get merged in to some other branch, like master or develop when the feature is done.
Share branches that need to be shared, keep other branches locally. Don't mess up the main repo if there is no need. Besides, other devs will have to manually clean their repos of references when the branches are removed from the main repository, via git remote prune origin.
Problem
We recently switched from SVN to Git and we're still kind of in the learning process when it comes to best practices, etc. I'm following this guide as a launching pad for managing our branches and releases. The document suggests that feature branches are generally local to the developer which is pretty much on par with what I've read elsewhere. However, some of the engineers are working on features that won't be in the next release. These features are 2 to 3 iterations ahead of our release cycle. The concern I hear from my engineers is that they are concerned about keeping so much code local. Even with their backup processes in place, it is still a concern. And I tend to agree with their concerns. So my question is, is it standard that branches that aren't slated for more immediate releases be pushed to origin? At some point these branches are merged into the develop branch and then deleted from origin. As an example, one engineer is working on a fulfillment piece which is rather large. We don't want his code pushed into the develop branch (always our next release candidate). So we created a fulfullment branch for him and pushed that to origin. The document I linked to and others I've read don't make is clear as to whether this is good or bad practice. If there is a better practice here please let me know or confirm my speculation.