4 ms·

I think private branches are just branches not pushed to remote. Isn't the problem here now that you have a critical point of failure and at risk of losing eve

I think private branches are just branches not pushed to remote. Isn't the problem here now that you have a critical point of failure and at risk of losing everything if you're not pushing things to remote nightly. I always advocate regardless of pushing branches to remote and getting things off of your local drives if possible.

philwelch 13y ago
If you're not regularly backing up the machine you work with, you're screwed. Git is not necessarily the best tool for this, but when you have nothing better, it often works to set up a "backup" remote that other people can't touch and then just do force pushes.
- angryasian 13y ago
  well most our stuff is in "the cloud" so really if we wiped everything, it be just a matter of pulling backups and go. Setting up a backup remote for something so simple of merge vs rebase sounds off to me.
  - philwelch 13y ago
    So it sounds like you don't have to push your code since your workstation is already being backed up then? We agree that you don't need to push your feature branches in that situation? I'm not sure, I feel like you just pulled some weird conversational jiu-jitsu where all of a sudden you're making my point back to me.
    - angryasian 13y ago
      no our things like documents, database backups, emails, and source code all exist in the cloud. By suggesting my employees all push to remote daily, theres no risk of ever losing anything. All it takes one stolen laptop, one hardware failure to push you back xxx days, from your private branch. I don't know how long you work on a private branch but I have seen people wait close to two weeks during a 2 week sprint.
      - philwelch 13y ago
        The Git system we use at my workplace has a private "backup" remote for each employee and a public "share" remote for each employee. So there's no problem rebasing all the time even if you push to the backup remote because it's not shared. Ultimately backups should be a totally separate concern from version control workflow anyway, even if you use Git remotes to back up your work.

philwelch 13y ago

If you're not regularly backing up the machine you work with, you're screwed. Git is not necessarily the best tool for this, but when you have nothing better, it often works to set up a "backup" remote that other people can't touch and then just do force pushes.

angryasian 13y ago
well most our stuff is in "the cloud" so really if we wiped everything, it be just a matter of pulling backups and go. Setting up a backup remote for something so simple of merge vs rebase sounds off to me.
- philwelch 13y ago
  So it sounds like you don't have to push your code since your workstation is already being backed up then? We agree that you don't need to push your feature branches in that situation? I'm not sure, I feel like you just pulled some weird conversational jiu-jitsu where all of a sudden you're making my point back to me.
  - angryasian 13y ago
    no our things like documents, database backups, emails, and source code all exist in the cloud. By suggesting my employees all push to remote daily, theres no risk of ever losing anything. All it takes one stolen laptop, one hardware failure to push you back xxx days, from your private branch. I don't know how long you work on a private branch but I have seen people wait close to two weeks during a 2 week sprint.
    - philwelch 13y ago
      The Git system we use at my workplace has a private "backup" remote for each employee and a public "share" remote for each employee. So there's no problem rebasing all the time even if you push to the backup remote because it's not shared. Ultimately backups should be a totally separate concern from version control workflow anyway, even if you use Git remotes to back up your work.