Menu
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.
230
It's a good idea to push the feature branch up to the central repository. This serves as a convenient backup, when collaborating with other developers, this would give them access to view commits to the new branch.
In case of git push origin, it explicitly specifies to be pushed into a repository called origin. Git push origin is usually used only where there are multiple remote repository and you want to specify which remote repository should be used for the push.
The more tangled it gets with branches and code, the better. Ten years later, feature branching is a standard in most teams, when in fact it doesn't bring any benefits to your bottom line: release quality software to production. Not only do feature branches provide zero benefits, they actually slow you down!
Pushing changes to the remote makes your commits accessible to others who you may be collaborating with. This will also update any open pull requests with the branch that you're working on. As best practice, it's important to run the git pull command before you push any new changes to the remote branch.
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.
107
For small sized features its optional. I would recommend pushing medium-big sized features on a daily-basis for backup purposes. Your company will hate to hear that your developer wasted 2 weeks of work when his PC died.
29
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
