| 1 | --- |
| 2 | layout: reference |
| 3 | --- |
| 4 | <div class="box"> |
| 5 | <h2>Introduction to the Git Reference</h2> |
| 6 | <div class="block"> |
| 7 | <p> |
| 8 | This is the Git reference site. It is meant to be a quick |
| 9 | reference for learning and remembering the most important and |
| 10 | commonly used Git commands. The commands are organized into |
| 11 | sections of the type of operation you may be trying to do, and |
| 12 | will present the common options and commands needed to accomplish |
| 13 | these common tasks. |
| 14 | </p> |
| 15 | <p> |
| 16 | Each section will link to the next section, so it can be used |
| 17 | as a tutorial. Every page will also link to more in-depth |
| 18 | Git documentation such as the official manual pages and relevant |
| 19 | sections in the <a href="http://git-scm.com/book">Pro Git book</a>, |
| 20 | so you can learn more about any of |
| 21 | the commands. First, we'll start with thinking about source code |
| 22 | management like Git does. |
| 23 | </p> |
| 24 | </div> |
| 25 | </div> |
| 26 | |
| 27 | <div class="box"> |
| 28 | <h2>How to Think Like Git</h2> |
| 29 | <div class="block"> |
| 30 | <p> |
| 31 | The first important thing to understand about Git is |
| 32 | that it thinks about version control very differently than |
| 33 | Subversion or Perforce or whatever SCM you may be used to. It |
| 34 | is often easier to learn Git by trying to forget your assumptions |
| 35 | about how version control works and try to think about it in the |
| 36 | Git way. |
| 37 | </p> |
| 38 | |
| 39 | <p> |
| 40 | Let's start from scratch. Assume you are designing a new source |
| 41 | code management system. How did you do basic version control before |
| 42 | you used a tool for it? Chances are that you simply copied your |
| 43 | project directory to save what it looked like at that point. |
| 44 | </p> |
| 45 | |
| 46 | <pre> $ cp -R project project.bak </pre> |
| 47 | |
| 48 | <p> |
| 49 | That way, you can easily revert files that get messed up later, or |
| 50 | see what you have changed by comparing what the project looks like |
| 51 | now to what it looked like when you copied it. |
| 52 | </p> |
| 53 | |
| 54 | <p> |
| 55 | If you are really paranoid, you may do this often, maybe putting the |
| 56 | date in the name of the backup: |
| 57 | </p> |
| 58 | |
| 59 | <pre> $ cp -R project project.2010-06-01.bak </pre> |
| 60 | |
| 61 | <p> |
| 62 | In that case, you may have a bunch of snapshots of your project that |
| 63 | you can compare and inspect from. You can even use this model to |
| 64 | fairly effectively share changes with someone. If you zip up your |
| 65 | project at a known state and put it on your website, other developers |
| 66 | can download that, change it and send you a patch pretty easily. |
| 67 | </p> |
| 68 | |
| 69 | <pre> |
| 70 | $ wget http://example.com/project.2010-06-01.zip |
| 71 | $ unzip project.2010-06-01.zip |
| 72 | $ cp -R project.2010-06-01 project-my-copy |
| 73 | $ cd project-my-copy |
| 74 | $ (change something) |
| 75 | $ diff project-my-copy project.2010-06-01 > change.patch |
| 76 | $ (email change.patch)</pre> |
| 77 | |
| 78 | <p> |
| 79 | Now the original developer can apply that patch to their copy of the |
| 80 | project and they have your changes. This is how many open source |
| 81 | projects have been collaborated on for several years. |
| 82 | </p> |
| 83 | |
| 84 | <p> |
| 85 | This actually works fairly well, so let's say we want to write a tool |
| 86 | to make this basic process faster and easier. Instead of writing a tool |
| 87 | that versions each file individually, like Subversion, we would probably |
| 88 | write one that makes it easier to store snapshots of our project without |
| 89 | having to copy the whole directory each time. |
| 90 | </p> |
| 91 | |
| 92 | <p> |
| 93 | This is essentially what Git is. You tell Git you want to save a snapshot |
| 94 | of your project with the <code>git commit</code> command and it basically |
| 95 | records a manifest of what all of the files in your project look like at |
| 96 | that point. Then most of the commands work with those manifests to see |
| 97 | how they differ or pull content out of them, etc. |
| 98 | </p> |
| 99 | |
| 100 | <center><img src="./images/snapshots.png"/></center> |
| 101 | |
| 102 | <p> |
| 103 | If you think about Git |
| 104 | as a tool for storing and comparing and merging snapshots of your project, |
| 105 | it may be easier to understand what is going on and how to do things |
| 106 | properly. |
| 107 | </p> |
| 108 | |
| 109 | </div> |
| 110 | </div> |
| 111 | |
| 112 | <p><a class="page-button next-page" href="{{ site.baseurl }}/creating">On to Getting and Creating Projects »</a></p> |