13 ms·
We've been fine using rebase on already pushed branches. This comes from the understanding that a feature branch belongs to one developer, ever, and that no one
by Jacqued 11y ago
We've been fine using rebase on already pushed branches. This comes from the understanding that a feature branch belongs to one developer, ever, and that no one else is supposed to work off of it (or at their own peril).
Everyone knows that it's "my branch" and that they're absolutely not supposed to use it for anything until it's merged back into master or whatever authoritative branch.
- aoeuasdf1 11y agoOk, that makes sense... but then why bother pushing the branch in the first place?
- zastrowm 11y agoIt allows builds off of that branch, so you can get test feedback etc. It also acts as sort of a backup or a sync if you switch machines.
- davidp 11y agoCode reviews -- you can create a PR on the pushed code, make fixes in response to the comments, rebase, and re-push.
- sopooneo 11y agoWe have a rule that you never go home at night without pushing your work, even if it's garbage. Put it in a super-short-term feature branch if needed, and push that, but don't leave it imprisoned on your machine.
- goostavos 11y agoThere are people who follow this rule, and there are people that think disk failures are what happen to other people. Few things sting as bad as loosing hours or days worth of work.
- icebraining 11y agoAnd there are people who have good backup systems.
- yellowapple 11y agoFor me, it's because I hop between development machines, and pushing/pulling a branch is much easier than the alternative of synchronizing files manually among said machines. Also, so that if something goes awry with my dev machine for whatever reason, at least my work is saved. Also, to make it easier for a colleague to review my code before it gets merged into something. Also, becuase it means I can use GitHub's PR system instead of doing it on my machine (thus providing some additional record that my code got merged in, and providing an avenue for the merge itself to be reviewed and commented on).
- mbesto 11y agoImmediate backup (I hope I'm not alone in saying this...)
- afarrell 11y agoYou are not
- mikeash 11y agoI kinda hope you are, because backup and source control really should be separate functions. Obviously your source control repository should be backed up, and pushing stuff into it acts to create a backup, but you really should have a separate backup system at work as well, to cover unpushed code as well as all the other useful info contained on your computer.
- Jacqued 11y agoI use it the same way too. I do not really see why backup should be separate from source control as there is no valuable information on my (work) computer apart from the source code, and I never spend more than a few hours without pushing.
- mikeash 11y agoBackups of your work computer would close that hours-long window between pushes.
- girvo 11y agoI work on multiple machines. Pushing my branch up even if it's busted code means I can continue work easily on other computers.
- seanp2k2 11y agoIf you're having a person own a branch, implementing it in their fork would probably make more sense: https://www.atlassian.com/git/tutorials/comparing-workflows https://www.atlassian.com/git/tutorials/comparing-workflows We using the forking model for bigger projects with more developers, and the branching model for smaller projects. It works out very nicely.