Mercurial > hg-website
comparison original/hgscm/templates/quick_start.html @ 244:4b97017259f9
Move the original site into a single folder to reduce clutter.
author | Steve Losh <steve@stevelosh.com> |
---|---|
date | Wed, 23 Sep 2009 20:05:13 -0400 |
parents | hgscm/templates/quick_start.html@c7bf003b17fd |
children | 960885d6e884 |
comparison
equal
deleted
inserted
replaced
240:85a7a53db1a5 | 244:4b97017259f9 |
---|---|
1 {% extends "base.html" %} | |
2 | |
3 {% load extras %} | |
4 {% block content %} | |
5 | |
6 <div class="row"> | |
7 <div class="col big"> | |
8 <h1>Quick Start</h1> | |
9 <p><em>How to get going at once.</em></p> | |
10 <h2>Part 0: Instant usage</h2> | |
11 <p><em>(you know this from the main page)</em></p> | |
12 <p>Clone a project and create a patch </p> | |
13 <pre><code>$ hg clone http://hg-scm.org/hello | |
14 $ cd hello | |
15 $ (edit files) | |
16 $ hg add (new files) | |
17 $ hg commit -m 'My changes' | |
18 $ hg export tip > patch.diff | |
19 | |
20 </code></pre> | |
21 <p>Create a project and commit </p> | |
22 <pre><code>$ hg init (project-directory) | |
23 $ cd (project-directory) | |
24 $ (add some files) | |
25 $ hg add | |
26 $ hg commit -m 'Initial commit' | |
27 </code></pre> | |
28 <h2>Part 1: Using Mercurial</h2> | |
29 <p>Aside from the practical Quick Start above, there are only a few commands you need to start | |
30 working. </p> | |
31 <p>Even if you stick to these basics, Mercurial is quite powerful. And they are very easy to | |
32 use, once you see the model behind them: Each repository has the whole history, and history is | |
33 not necessarily linear (part 2 explains that model in a bit more detail). </p> | |
34 <p>A quick overview of the basic commands: </p> | |
35 <ul> | |
36 <li>hg init: create a new repository | |
37 </li><li>hg commit: save your changes in the current repository | |
38 </li><li>hg log: see all changes in your repository | |
39 </li><li>hg pull: get all changes from another repository into the current one | |
40 </li><li>hg push: get all changes from your repository into another one | |
41 </li><li>hg serve: create an instant-webserver. People can see the history there and pull from it | |
42 </li><li>hg merge: join different lines of history | |
43 </li> | |
44 </ul> | |
45 <p>If you want to see a nice graph of the history, just do <hg>hg serve</hg> in your repository and then direct your browser to </p> | |
46 <pre><code> http://127.0.0.1:8000 | |
47 | |
48 </code></pre> | |
49 <p>This also helps getting a feeling for what the commands do. </p> | |
50 <p>(you can also do a lot of finegrained stuff by using different command options. Just call "hg help <command>" to see them). </p> | |
51 <p>One step you'll likely want to do is setting your username in your Mercurial config file. </p> | |
52 <p>For this you can configure a proper name and email address in ~/.hgrc (or on a Windows system in %USERPROFILE%Mercurial.ini) by adding lines such as the following: </p> | |
53 <pre><code>[ui] | |
54 username = John Doe <john@example.com> | |
55 | |
56 </code></pre> | |
57 <p>I you want more than this quick overview, please have a look at our longer <a href="{% url workflow_guide %}">practical guide</a>. </p> | |
58 <h2>Part 2: Understanding Mercurial in 6 steps</h2> | |
59 <p>Now we'll look at some of the basic concepts of Mercurial to get a better understanding of its internals: </p> | |
60 <ol class="undecorated_list"> | |
61 <li> | |
62 <p>Like in Subversion, history consists of a number of commits. They're | |
63 called changesets in Mercurial.</p> | |
64 | |
65 </li><li> | |
66 <p>Subversion requires a strict linear ordering of the commits and | |
67 gives nice linear revision numbers to them. So revision N has only | |
68 one child revision, N+1. This is simple, but it requires a central server to make sure that | |
69 everybody agrees on the revision numbers.</p> | |
70 | |
71 </li><li> | |
72 <p>Mercurial generalizes this by letting each changeset have multiple | |
73 children. If I work alone and make commits I'll make</p> | |
74 <pre><code>C1 --> C2 --> C3 | |
75 | |
76 </code></pre> | |
77 <p>by making three commits. </p> | |
78 | |
79 <p>The commit C3 with no children is a "head". | |
80 It is also the newest changeset in the repository -- called "tip". If I shared C1 with you and you started your work from that, your | |
81 commits will build a repository like this:</p> | |
82 <pre><code>C1 --> C2' --> C3' | |
83 | |
84 </code></pre> | |
85 <p>Here C3' is a head in your repository and I don't know anything | |
86 about C2' and C3' yet.</p> | |
87 | |
88 </li><li>If I pull from you, or you push to me, the two repositories are | |
89 compared. By default, all missing changesets are transferred. This | |
90 is all there is to push/pull: compare two graphs of changesets and | |
91 transfer the missing ones. | |
92 <p>After a pull from you my repository will look like this:</p> | |
93 <pre><code> /-> C2 --> C3 | |
94 C1 -< | |
95 \-> C2' --> C3' | |
96 | |
97 </code></pre> | |
98 <p>Here C1 has two child changesets, and the repository has two heads | |
99 since the development has diverged.</p> | |
100 <p>The changeset C3' will be the new tip since it is the newest | |
101 changeset in the repository. Note that tip is always a head, but a | |
102 head need not be the tip.</p> | |
103 | |
104 </li><li>Having two heads suggest that someone should merge them -- otherwise | |
105 the changes from one will never be combined with the changed made in | |
106 the other head. | |
107 <p>When merging with 'hg merge' the task is to figure out the canonical | |
108 way to combine the changesets. If the changes do not overlap this is | |
109 usually trivial, otherwise you have to do a three-way merge. The | |
110 merge must be committed and this creates a changeset which explains | |
111 to the world how you think the two heads should be combined:</p> | |
112 <pre><code> /-> C2 --> C3 -\ | |
113 C1 -< >-> M | |
114 \-> C2' --> C3' -/ | |
115 | |
116 </code></pre> | |
117 <p>Note that the merge changeset M has two parents.</p> | |
118 <p>If you do not merge C3 and C3' and try to push, you get the 'new | |
119 remote head' message and push aborts. It aborts since it is a little | |
120 "impolite" to leave the job of merging to someone else -- he who | |
121 created the two heads by pulling in some code should also normally | |
122 do the merging. | |
123 </p> | |
124 </li><li> | |
125 <p>It helped my understanding a lot to think in terms of the changeset graph. Just remember that:</p> | |
126 <ul><li> | |
127 <p>"hg commit" adds a new node. The parent changesets of the new node | |
128 is given by "hg parents"</p> | |
129 | |
130 </li><li> | |
131 <p>"hg push" and "hg pull" transfer nodes in the graph between two | |
132 repositories.</p> | |
133 | |
134 </li><li> | |
135 <p>"hg update" updates the working copy to reflect a given node in | |
136 the history graph. This also changes the parent changeset of the | |
137 next commit, see "hg parents".</p> | |
138 </li> | |
139 </ul> | |
140 </ol> | |
141 | |
142 <p>And if you want to quickly look up something, you can use one of the <a href="http://www.selenic.com/mercurial/wiki/index.cgi/QuickReferenceCardsAndCheatSheets">Mercurial cheatsheets</a>. </p> | |
143 <p><em>Compiled from a great email by Martin Geisler.</em></p> | |
144 | |
145 </div> | |
146 <div class="col"> | |
147 {% download_button %} | |
148 {% mercurial_tricks %} | |
149 {% mercurial_tricks_advanced %} | |
150 </div> | |
151 </div> | |
152 | |
153 {% endblock %} |