PUSH all local GIT branches? Best Practice?

Question

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?

score 8 · Accepted Answer · edited May 23 '17 at 12:14

8

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.

edited May 23 '17 at 12:14

Community

1
1

answered May 10 '12 at 15:31

VonC

1,262,500
529
4,410
5,250

Thanks all for the great answers, and for the further instructions on how to do a proper backup! This is the route we will go. – Garrick May 14 '12 at 16:01

score 2 · Answer 2 · answered May 10 '12 at 15:17

2

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.

answered May 10 '12 at 15:17

Steve Ross

1,228
10
21

1

This is the argument put forth by others on my team. I can understand where you're coming from but disagree with this workflow. I think it is confusing 'version-control' with 'backup' which are two separate tasks. Previous to Distributed version control you would never have pushed changes to multiple repositories as a form of backup. If we were going to go this route I guess we would create a second 'working' master-repository to contain these additional branches as well as asking people to close them when done. I don't think we're going to do this though. – Garrick May 15 '12 at 20:35
1

fwiw i voted for the answer above... I only push stuff to remote when I need to share it with others – Steve Ross May 18 '12 at 15:42

score 2 · Answer 3 · answered May 10 '12 at 15:29

2

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.

answered May 10 '12 at 15:29

CharlesB

86,532
28
194
218

1

There's also `git push --mirror ` which might come in handy for the "backup" task as it also carries out deletion of locally deleted branches. – kostix May 10 '12 at 21:52
Good answer also, Thank you CharlesB and kostix – Garrick May 14 '12 at 16:02

PUSH all local GIT branches? Best Practice?

3 Answers3

Linked