Should ALL locally created GIT branches be pushed to the central-repository on a daily basis? What is best-pracice workflow concerning this?
We created a GIT repository to manage our large e-commerce site, which is under continual development by a large team.
The central repository is at 'Beanstalk' and we have three primary branches, 'prestaging' (master), 'staging' and 'production'. All development should be merged into prestaging when it is completed locally and ready to be published.
I can see pushing long-running branches to Beanstalk as well. However some of our team advocates pushing ALL local development branches to Beanstalk on a daily basis in-progress or not; to create redundancy. I think this would clutter the repository with hundreds of branches over time. What is best practice?
I prefer not polluting the central repo with all branches of all users.
Don't mix:
- publication workflow: what you choose to publish (push/pull to an upstream repo)
- backup need: use a bundle (See "Backup a Local Git Repository"), that way you have only one file to copy to any remote drive you want.
You can always have the user clean up their remote branches when they are done with it. It's not a bad idea to have them push their local branches up just for safe keeping (especially if there is no backup solution on their box). Otherwise if their machine dies their local branch is gone.
I agree with you, using a central repo for backup of daily work is a bad idea. It should hold commits meant to be shared, tested or released.
Backup of daily work should either happen to another repo, more permissive, with optionally an automated git push --force --all backup-repo
task on each dev machine, or have them a more classic backup tool.