clone.txt

   1 = Cloning Around =
   2
   3 In older version control systems, the standard way to get a saved state was checkout. You'd checkout a bunch of files in the requested saved state.
   4
   5 In Git and other distributed version control systems, cloning is the standard operation. To get files you create a clone of the entire repository. In other words, you practically create a mirror of the central server. So anything the main repository can do, you can do.
   6
   7 == Sync Computers ==
   8
   9 This is the reason I first used Git. I can tolerate making tarballs or using <tt>rsync</tt> for backups and basic syncing. The problem was sometimes I'd edit on my laptop, other times on my desktop, and they may not have talked to each other in between.
  10
  11 Initialize a Git repository and commit your files as above on one machine. Then on the other:
  12
  13  $ git-clone other.computer:/path/to/files
  14
  15 to create a second copy of the files and Git respository. From now on,
  16
  17  $ git-commit -a
  18  $ git-pull other.computer:/path/to/files
  19
  20 will pull in the state of the files on the other computer into the one you're working on. If you've recently made conflicting edits in the same file, Git will let you know and you should commit again after resolving them.
  21
  22 If you have not committed any changes on the other computer, you may type
  23
  24  $ git-push other.computer:/path/to/files
  25
  26 to push the current state to the other computer. Next time you're logged in to the other computer, run
  27
  28  $ git-checkout HEAD .
  29
  30 to update the files before working on them. Be aware that you'll lose any uncommitted changes when you do this.
  31
  32 == Classic Source Control ==
  33
  34 Initialize a Git repository for your files:
  35
  36  $ git-init-db
  37  $ git add .
  38  $ git commit -m "Initial commit"
  39
  40 On the central server, initialize an empty Git repository with some name:
  41
  42  $ GIT_DIR=proj.git git-init-db
  43
  44 Some public hosts, such as [[http://repo.or.cz][repo.or.cz]], will have a different method for setting up the initially empty Git repository, such as filling in a form on a webpage.
  45
  46 Push your project to the central server with:
  47
  48  $ git-push git://central.server/path/to/proj.git HEAD
  49
  50 We're ready. To check out source, a developer types
  51
  52  $ git clone central.server:/path/to/proj.git
  53
  54 After making changes, the code is checked in to the main server by:
  55
  56  $ git commit -a
  57  $ git push
  58
  59 If the main server has been updated, the latest version needs to be checked out before the push. To sync to the latest version:
  60
  61  $ git commit -a
  62  $ git pull
  63
  64 A popular misconception is that Git is ill-suited for projects requiring an official central repository (see for example [[http://www.subversionary.org/martintomes/git][this blog post]]). Nothing could be further from the truth. Photographing someone does not cause their soul to be stolen. Similarly, cloning the master repository does not make its importance diminish.
  65
  66 A good first approximation is that anything a centralized version control system can do, Git can do better. While not strictly true, one is less likely to make erroneous comparisons with this rule of thumb.
  67
  68 You might not use most of Git's features in a small project, but there is nothing wrong with this as there is negligible overhead. And who knows, perhaps your project will grow beyond your original expectations. It's like using a Swiss army knife to mostly open bottles. On the day you desperately need a screwdriver you'll be glad you have it with you.
  69
  70 == Forking a Project ==
  71
  72 Sick of the way a project is being run? Think you could do a better job? Then on your server:
  73
  74  $ git clone main.server:/path/to/files
  75
  76 Next tell everyone to check out your fork of the project at your server.
  77
  78 At any later time, you can merge in the changes from the original project with:
  79
  80  $ git pull
  81
  82 == Ultimate Backups ==
  83
  84 Want numerous tamper-proof geographically diverse redundant archives? If your project has many developers, don't do anything! Everyone who clones your code is effectively a backup, not just of the current state of the project, but of your project's entire history. Thanks to cryptographic hashing, if someone's clone become corrupted, it will be spotted as soon as they try to communicate with others.
  85
  86 If your project is not so popular, find as many hosts as you can and clone your project there.
  87
  88 The truly paranoid should always write down the latest 20-byte SHA1 hash of the HEAD somewhere safe. It has to be safe, not private. For example, publishing it in a newspaper would work well, because it's hard for an attacker to alter every copy of a newspaper.
  89
  90 == Light-Speed Multitask ==
  91
  92 Say you want to work on several features in parallel. Then after committing your project:
  93
  94  $ git-clone --local --shared . /some/new/directory
  95
  96 The options can be written as <tt>-l -s</tt> instead, which I like to think of as an acronym for "Light Speed"!
  97
  98 Git exploits hard links and file sharing as much as possible to create this clone. Subsequently, this clone is unsuitable as a backup. However, it's ready in a flash, and you can now work on two independent features simultaneously. For example, you can edit one clone while the other is compiling.
  99
 100 At any time, you can commit and pull changes from one to the other.
 101
 102  $ git-pull one /to/the/other
 103
 104 == Guerilla Version Control ==
 105
 106 Are you working on a project that uses some other version control system, and you sorely miss Git? Then initialize a Git repository in your working directory:
 107
 108  $ git-init-db
 109  $ git add .
 110  $ git commit -m "Initial commit"
 111
 112 then clone it:
 113
 114  $ git-clone -l -s  . /some/new/directory
 115
 116 Now go to the new directory and work here instead, using Git to your heart's content. Once in a while, you'll want to sync with everyone else, in which case go to the original directory, sync using the other version control system, and type:
 117
 118  $ git add .
 119  $ git commit -m "sync with everyone else"
 120
 121 Then go to the new directory and run:
 122
 123  $ git commit -a -m "description of my changes"
 124  $ git pull
 125
 126 On the other hand, the procedure for giving your changes to everyone else varies depending on the other version control system. The new directory contains the files with your changes. Run whatever commands of the other version control system are neeeded to upload them to the central repository.