en/clone.txt

   1 == Cloning Around ==
   2
   3 In older version control systems, checkout is the standard operation to get files. You retrieve 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 mirror the central server. 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 *rsync* for backups and basic syncing. But sometimes I edit on my laptop, other times on my desktop, and the two may not have talked to each other in between.
  10
  11 Initialize a Git repository and commit your files 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 repository. From now on,
  16
  17  $ git commit -a
  18  $ git pull other.computer:/path/to/files HEAD
  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 === Classic Source Control ===
  23
  24 Initialize a Git repository for your files:
  25
  26  $ git init
  27  $ git add .
  28  $ git commit -m "Initial commit"
  29
  30 On the central server, initialize an empty Git repository with some name,
  31 and start the Git daemon if necessary:
  32
  33  $ GIT_DIR=proj.git git init
  34  $ git daemon --detach  # it might already be running
  35
  36 For Git hosting services, follow the instructions to setup the initially
  37 empty Git repository. Typically one fills in a form on a webpage.
  38
  39 Push your project to the central server with:
  40
  41  $ git push git://central.server/path/to/proj.git HEAD
  42
  43 We're ready. To check out source, a developer types
  44
  45  $ git clone git://central.server/path/to/proj.git
  46
  47 After making changes, the code is checked in to the main server by:
  48
  49  $ git commit -a
  50  $ git push
  51
  52 If the main server has been updated, the latest version needs to be checked out before the push. To sync to the latest version:
  53
  54  $ git commit -a
  55  $ git pull
  56
  57 ==== Push versus pull ====
  58
  59 We mostly avoid pushing into a repository, because confusion can ensue
  60 if the destination has a working directory with changes. However, pushing into
  61 a bare repository is a straightforward operation and more suitable than a pull
  62 in this case.
  63
  64 Pulling from the server requires shelling into the server, and also
  65 knowing the network address of the machine you happen to be working on.
  66 Furthermore, firewalls may interfere.
  67
  68 === Forking a Project ===
  69
  70 Sick of the way a project is being run? Think you could do a better job? Then on your server:
  71
  72  $ git clone git://main.server/path/to/files
  73
  74 Next tell everyone about your fork of the project at your server.
  75
  76 At any later time, you can merge in the changes from the original project with:
  77
  78  $ git pull
  79
  80 === Ultimate Backups ===
  81
  82 Want numerous tamper-proof geographically diverse redundant archives? If your project has many developers, don't do anything! Every clone of your code is effectively a backup. Not just of the current state, but of your project's entire history. Thanks to cryptographic hashing, if anyone's clone becomes corrupted, it will be spotted as soon as they try to communicate with others.
  83
  84 If your project is not so popular, find as many servers as you can to host clones.
  85
  86 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.
  87
  88 === Light-Speed Multitask ===
  89
  90 Say you want to work on several features in parallel. Then commit your project and run:
  91
  92  $ git clone . /some/new/directory
  93
  94 Git exploits hard links and file sharing as much as safely possible to create this clone, so it will be 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.
  95
  96 At any time, you can commit and pull changes from the other clone.
  97
  98  $ git pull /the/other/clone HEAD
  99
 100 === Guerilla Version Control ===
 101
 102 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:
 103
 104  $ git init
 105  $ git add .
 106  $ git commit -m "Initial commit"
 107
 108 then clone it:
 109
 110  $ git clone . /some/new/directory
 111
 112 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:
 113
 114  $ git add .
 115  $ git commit -m "Sync with everyone else"
 116
 117 Then go to the new directory and run:
 118
 119  $ git commit -a -m "Description of my changes"
 120  $ git pull
 121
 122 The procedure for giving your changes to everyone else depends 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 needed to upload them to the central repository.
 123
 124 The *git svn* command automates the above for Subversion repositories, and can
 125 also be used to
 126 http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[export a Git project to a Subversion repository].