5 ms·

Also, any code that isn't pushed to a remote doesn't exist. Or, it won't when your hard drive unexpectedly fails and your feature branch disappears. =)

gte910h 14y ago
You should be using file backup on any system with code on it. It is so cheap to do this today, it is a no brainer. Apple Time Capsule, Crashplan Pro, etc.
- nathan_long 14y ago
  The only non-replacable thing on my development machine is the code. It makes more sense to me to always push my feature branches up to the server, which is backed up, than for each dev machine to be backed up separately.
  - philjackson 14y ago
    I suppose if you were really paranoid you could use 'git archive' to snapshot to dropbox.
    - ryanpetrich 14y ago
      Pushing to dropbox is a very common part of my workflow: https://github.com/rpetrich/git-dropbox https://github.com/rpetrich/git-dropbox It's not strictly safe to use from multiple machines, but as a simple backup it's very convenient.
    - sneak 14y ago
      All of my git repos live in a subdirectory of my dropbox as-is. I also compulsively push to remote. I also use Time Machine. I also rsync my home directory to an external drive in case Time Machine implodes. I also rsync my home directory to a server in another hemisphere. Come at me, bro.
      - imissmyjuno 14y ago
        The last point is a great idea. I've had my NAS Time Machine backup get corrupted and TM forcing me to redo a full backup a few times now to the point of me abandoning it entirely..
      - eli 14y ago
        It's been a while, but storing .git files in Dropbox didn't work out so hot for me. Make changes in two places and Dropbox resolves the conflict by renaming one file to "X (Eli's Conflicted Copy)".... Git really doesn't expect to see it's internal files renamed like that.
        sneak 14y ago
        The question then becomes "Why do I need more than one computer accessing git when computers now weigh 1kg?"
  - Davertron 14y ago
    If you rebase a lot, then you want to avoid pushing code constantly until you get it where you want it.
    - jimktrains2 14y ago
      One of the many reasons not to rebase code that's been pushed already.
      - Davertron 14y ago
        As far as I know there's only one reason not to rebase code that's been pushed. My point was that pushing constantly as a backup mechanism isn't an option if you intend to rebase frequently (unless you're the only developer on the project).
      - X-Istence 14y ago
        I have a personal clone of whatever project I am working on, any branches that I publish can be changed at any time using a push -f.
    - deleted 14y ago
      [deleted]
    - nathan_long 14y ago
      Depends on your team. I'm on a small one, and I often rebase and force push a branch I'm working on, because I know nobody else is working on it.
    - philsnow 14y ago
      So push to a remote feature branch that is named after your username, then rebase the changes in that feature branch onto the 'trunk' branch and push the result ? The D in DVCS is all well and good, but there are business reasons for having a canonical store of all source materials.
  - gte910h 14y ago
    Why don't you then just backup your dev machine's code directories to another machine? Backup is good because it's automatic. Saving somewhere else is nice too, but it's not really backup.
    - lmm 14y ago
      It'd be more effort for no gain - and it would encourage me to keep changes locally, which is bad for collaboration.
      - gte910h 14y ago
        Thrashing the index with half completed features is ALSO bad for collaboration.
        lmm 14y ago
        It's good that my colleagues can see what I'm working on. It's not going to slow them down when they don't want it to, since git only fetches those branches you ask it for. So no, I have to disagree.

gte910h 14y ago

You should be using file backup on any system with code on it. It is so cheap to do this today, it is a no brainer. Apple Time Capsule, Crashplan Pro, etc.

nathan_long 14y ago
The only non-replacable thing on my development machine is the code. It makes more sense to me to always push my feature branches up to the server, which is backed up, than for each dev machine to be backed up separately.
- philjackson 14y ago
  I suppose if you were really paranoid you could use 'git archive' to snapshot to dropbox.
  - ryanpetrich 14y ago
    Pushing to dropbox is a very common part of my workflow: https://github.com/rpetrich/git-dropbox https://github.com/rpetrich/git-dropbox It's not strictly safe to use from multiple machines, but as a simple backup it's very convenient.
  - sneak 14y ago
    All of my git repos live in a subdirectory of my dropbox as-is. I also compulsively push to remote. I also use Time Machine. I also rsync my home directory to an external drive in case Time Machine implodes. I also rsync my home directory to a server in another hemisphere. Come at me, bro.
    - imissmyjuno 14y ago
      The last point is a great idea. I've had my NAS Time Machine backup get corrupted and TM forcing me to redo a full backup a few times now to the point of me abandoning it entirely..
    - eli 14y ago
      It's been a while, but storing .git files in Dropbox didn't work out so hot for me. Make changes in two places and Dropbox resolves the conflict by renaming one file to "X (Eli's Conflicted Copy)".... Git really doesn't expect to see it's internal files renamed like that.
      - sneak 14y ago
        The question then becomes "Why do I need more than one computer accessing git when computers now weigh 1kg?"
- Davertron 14y ago
  If you rebase a lot, then you want to avoid pushing code constantly until you get it where you want it.
  - jimktrains2 14y ago
    One of the many reasons not to rebase code that's been pushed already.
    - Davertron 14y ago
      As far as I know there's only one reason not to rebase code that's been pushed. My point was that pushing constantly as a backup mechanism isn't an option if you intend to rebase frequently (unless you're the only developer on the project).
    - X-Istence 14y ago
      I have a personal clone of whatever project I am working on, any branches that I publish can be changed at any time using a push -f.
  - deleted 14y ago
    [deleted]
  - nathan_long 14y ago
    Depends on your team. I'm on a small one, and I often rebase and force push a branch I'm working on, because I know nobody else is working on it.
  - philsnow 14y ago
    So push to a remote feature branch that is named after your username, then rebase the changes in that feature branch onto the 'trunk' branch and push the result ? The D in DVCS is all well and good, but there are business reasons for having a canonical store of all source materials.
- gte910h 14y ago
  Why don't you then just backup your dev machine's code directories to another machine? Backup is good because it's automatic. Saving somewhere else is nice too, but it's not really backup.
  - lmm 14y ago
    It'd be more effort for no gain - and it would encourage me to keep changes locally, which is bad for collaboration.
    - gte910h 14y ago
      Thrashing the index with half completed features is ALSO bad for collaboration.
      - lmm 14y ago
        It's good that my colleagues can see what I'm working on. It's not going to slow them down when they don't want it to, since git only fetches those branches you ask it for. So no, I have to disagree.