gergely/git-reference
1
0
Fork 0
Code Releases Activity

basic layout and intro content

Browse Source
This commit is contained in:
Scott Chacon
2010-06-03 14:34:35 +02:00
parent 8f9a1a345c
commit 0a2c326622
15 changed files with 2616 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

109
index.html Executable file
View File

@@ -0,0 +1,109 @@
---
layout: reference
---
<div class="box">
<h2>Introduction to the Git Reference</h2>
<div class="block">
<p>
This is the Git reference site. This is meant to be a quick
reference for learning and remembering the most important and
commonly used Git commands. The commands are organized into
sections of the type of operation you may be trying to do, and
will preset the common options and commands needed to accomplish
these common tasks.
</p>
<p>
Each section will link to the next section, so it can be used
as a tutorial. Every page will also link to the more in-depth
offical Git documentation to learn more about any of the commands.
First, we'll start with thinking about source code management like
Git does.
</p>
</div>
</div>
<div class="box">
<h2>How to Think Like Git</h2>
<div class="block">
<p>
This first thing that is important to understand about Git is
that it thinks about version control very differently than
Subversion or Perforce or whatever SCM you may be used to. It
is often easier to learn Git by trying to forget your assumptions
about how version control works and try to think about it in the
Git way.
</p>
<p>
Let's start from scratch. Assume you are designing a new source
code management system. How do you do basic version control before
you used a tool for it? Chances are that you simply copied your
project directory to save what it looked like at that point.
</p>
<pre> $ cp -R project project.bak </pre>
<p>
That way, you can easily revert files that get messed up later, or
see what you have changed by comparing what the project looks like
now to what it looked like when you copied it.
</p>
<p>
If you are really paranoid, you may do this often, maybe putting the
date in the name of the backup:
</p>
<pre> $ cp -R project project.2010-06-01.bak </pre>
<p>
In that case, you may have a bunch of snapshots of your project that
you can compare and inspect from. You can even use this model to
fairly effectively share changes with someone. If you zip up your
project at a known state and put it on your website, other developers
can download that, change it and send you a patch pretty easily.
</p>
<pre>
$ wget http://sample.com/project.2010-06-01.zip
$ unzip project.2010-06-01.zip
$ cp -R project.2010-06-01 project-my-copy
$ unzip project.2010-06-01.zip
$ cd project-my-copy
$ (change something)
$ diff project-my-copy project.2010-06-01 > change.patch
$ (email change.patch)</pre>
<p>
Now the original developer can apply that patch to their copy of the
project and they have your changes. This is how many open source
projects have been collaborated on for several years.
</p>
<p>
This actually works fairly well, so let's say we want to write a tool
to make this basic process faster and easier. Instead of writing a tool
that versions each file individually, like Subversion, we would probably
write one that makes it easier to store snapshots of our project without
having to copy the whole directory each time.
</p>
<p>
This is essentially what Git is. You tell Git you want to save a snapshot
of your project with the <code>git commit</code> command and it basically
records a manifest of what all of the files in your project look like at
that point. Then most of the commands work with those manifests to see
how they differ or pull content out of them, etc.
</p>
<p>
If you think about Git
as a tool for storing and comparing and merging snapshots of your project,
it may be easier to understand what is going on and how to do things
properly.
</p>
<p><a href="#">On to Getting and Creating Projects &#187;</a></p>
</div>
</div>