OSDN Git Service

Add Git official document to help
[tortoisegit/TortoiseGitJp.git] / doc / source / en / TortoiseGit / git_doc / gittutorial.html.xml
1 <?xml version="1.0" encoding="UTF-8"?>\r
2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">\r
3 \r
4 <article lang="en" id="gittutorial(7)">\r
5 <articleinfo>\r
6     <title>gittutorial(7)</title>\r
7         <indexterm>\r
8                 <primary>gittutorial(7)</primary>\r
9         </indexterm>\r
10 </articleinfo>\r
11 <simplesect id="_name">\r
12 <title>NAME</title>\r
13 <simpara>gittutorial - A tutorial introduction to git (for version 1.5.1 or newer)</simpara>\r
14 </simplesect>\r
15 <simplesect id="_synopsis">\r
16 <title>SYNOPSIS</title>\r
17 <simpara>git *</simpara>\r
18 </simplesect>\r
19 <simplesect id="_description">\r
20 <title>DESCRIPTION</title>\r
21 <simpara>This tutorial explains how to import a new project into git, make\r
22 changes to it, and share changes with other developers.</simpara>\r
23 <simpara>If you are instead primarily interested in using git to fetch a project,\r
24 for example, to test the latest version, you may prefer to start with\r
25 the first two chapters of <ulink url="user-manual.html">The Git User&#8217;s Manual</ulink>.</simpara>\r
26 <simpara>First, note that you can get documentation for a command such as\r
27 <literal>git log --graph</literal> with:</simpara>\r
28 <literallayout>$ man git-log</literallayout>\r
29 <simpara>or:</simpara>\r
30 <literallayout>$ git help log</literallayout>\r
31 <simpara>With the latter, you can use the manual viewer of your choice; see\r
32 <xref linkend="git-help(1)"/> for more information.</simpara>\r
33 <simpara>It is a good idea to introduce yourself to git with your name and\r
34 public email address before doing any operation.  The easiest\r
35 way to do so is:</simpara>\r
36 <literallayout>$ git config --global user.name "Your Name Comes Here"\r
37 $ git config --global user.email you@yourdomain.example.com</literallayout>\r
38 </simplesect>\r
39 <simplesect id="_importing_a_new_project">\r
40 <title>Importing a new project</title>\r
41 <simpara>Assume you have a tarball project.tar.gz with your initial work.  You\r
42 can place it under git revision control as follows.</simpara>\r
43 <literallayout>$ tar xzf project.tar.gz\r
44 $ cd project\r
45 $ git init</literallayout>\r
46 <simpara>Git will reply</simpara>\r
47 <literallayout>Initialized empty Git repository in .git/</literallayout>\r
48 <simpara>You&#8217;ve now initialized the working directory&#8212;you may notice a new\r
49 directory created, named ".git".</simpara>\r
50 <simpara>Next, tell git to take a snapshot of the contents of all files under the\r
51 current directory (note the <emphasis>.</emphasis>), with <emphasis>git-add</emphasis>:</simpara>\r
52 <literallayout>$ git add .</literallayout>\r
53 <simpara>This snapshot is now stored in a temporary staging area which git calls\r
54 the "index".  You can permanently store the contents of the index in the\r
55 repository with <emphasis>git-commit</emphasis>:</simpara>\r
56 <literallayout>$ git commit</literallayout>\r
57 <simpara>This will prompt you for a commit message.  You&#8217;ve now stored the first\r
58 version of your project in git.</simpara>\r
59 </simplesect>\r
60 <simplesect id="_making_changes">\r
61 <title>Making changes</title>\r
62 <simpara>Modify some files, then add their updated contents to the index:</simpara>\r
63 <literallayout>$ git add file1 file2 file3</literallayout>\r
64 <simpara>You are now ready to commit.  You can see what is about to be committed\r
65 using <emphasis>git-diff</emphasis> with the --cached option:</simpara>\r
66 <literallayout>$ git diff --cached</literallayout>\r
67 <simpara>(Without --cached, <emphasis>git-diff</emphasis> will show you any changes that\r
68 you&#8217;ve made but not yet added to the index.)  You can also get a brief\r
69 summary of the situation with <emphasis>git-status</emphasis>:</simpara>\r
70 <literallayout>$ git status\r
71 # On branch master\r
72 # Changes to be committed:\r
73 #   (use "git reset HEAD &lt;file&gt;..." to unstage)\r
74 #\r
75 #       modified:   file1\r
76 #       modified:   file2\r
77 #       modified:   file3\r
78 #</literallayout>\r
79 <simpara>If you need to make any further adjustments, do so now, and then add any\r
80 newly modified content to the index.  Finally, commit your changes with:</simpara>\r
81 <literallayout>$ git commit</literallayout>\r
82 <simpara>This will again prompt you for a message describing the change, and then\r
83 record a new version of the project.</simpara>\r
84 <simpara>Alternatively, instead of running <emphasis>git-add</emphasis> beforehand, you can use</simpara>\r
85 <literallayout>$ git commit -a</literallayout>\r
86 <simpara>which will automatically notice any modified (but not new) files, add\r
87 them to the index, and commit, all in one step.</simpara>\r
88 <simpara>A note on commit messages: Though not required, it&#8217;s a good idea to\r
89 begin the commit message with a single short (less than 50 character)\r
90 line summarizing the change, followed by a blank line and then a more\r
91 thorough description.  Tools that turn commits into email, for\r
92 example, use the first line on the Subject: line and the rest of the\r
93 commit in the body.</simpara>\r
94 </simplesect>\r
95 <simplesect id="_git_tracks_content_not_files">\r
96 <title>Git tracks content not files</title>\r
97 <simpara>Many revision control systems provide an <literal>add</literal> command that tells the\r
98 system to start tracking changes to a new file.  Git&#8217;s <literal>add</literal> command\r
99 does something simpler and more powerful: <emphasis>git-add</emphasis> is used both for new\r
100 and newly modified files, and in both cases it takes a snapshot of the\r
101 given files and stages that content in the index, ready for inclusion in\r
102 the next commit.</simpara>\r
103 </simplesect>\r
104 <simplesect id="_viewing_project_history">\r
105 <title>Viewing project history</title>\r
106 <simpara>At any point you can view the history of your changes using</simpara>\r
107 <literallayout>$ git log</literallayout>\r
108 <simpara>If you also want to see complete diffs at each step, use</simpara>\r
109 <literallayout>$ git log -p</literallayout>\r
110 <simpara>Often the overview of the change is useful to get a feel of\r
111 each step</simpara>\r
112 <literallayout>$ git log --stat --summary</literallayout>\r
113 </simplesect>\r
114 <simplesect id="_managing_branches">\r
115 <title>Managing branches</title>\r
116 <simpara>A single git repository can maintain multiple branches of\r
117 development.  To create a new branch named "experimental", use</simpara>\r
118 <literallayout>$ git branch experimental</literallayout>\r
119 <simpara>If you now run</simpara>\r
120 <literallayout>$ git branch</literallayout>\r
121 <simpara>you&#8217;ll get a list of all existing branches:</simpara>\r
122 <literallayout>  experimental\r
123 * master</literallayout>\r
124 <simpara>The "experimental" branch is the one you just created, and the\r
125 "master" branch is a default branch that was created for you\r
126 automatically.  The asterisk marks the branch you are currently on;\r
127 type</simpara>\r
128 <literallayout>$ git checkout experimental</literallayout>\r
129 <simpara>to switch to the experimental branch.  Now edit a file, commit the\r
130 change, and switch back to the master branch:</simpara>\r
131 <literallayout>(edit file)\r
132 $ git commit -a\r
133 $ git checkout master</literallayout>\r
134 <simpara>Check that the change you made is no longer visible, since it was\r
135 made on the experimental branch and you&#8217;re back on the master branch.</simpara>\r
136 <simpara>You can make a different change on the master branch:</simpara>\r
137 <literallayout>(edit file)\r
138 $ git commit -a</literallayout>\r
139 <simpara>at this point the two branches have diverged, with different changes\r
140 made in each.  To merge the changes made in experimental into master, run</simpara>\r
141 <literallayout>$ git merge experimental</literallayout>\r
142 <simpara>If the changes don&#8217;t conflict, you&#8217;re done.  If there are conflicts,\r
143 markers will be left in the problematic files showing the conflict;</simpara>\r
144 <literallayout>$ git diff</literallayout>\r
145 <simpara>will show this.  Once you&#8217;ve edited the files to resolve the\r
146 conflicts,</simpara>\r
147 <literallayout>$ git commit -a</literallayout>\r
148 <simpara>will commit the result of the merge. Finally,</simpara>\r
149 <literallayout>$ gitk</literallayout>\r
150 <simpara>will show a nice graphical representation of the resulting history.</simpara>\r
151 <simpara>At this point you could delete the experimental branch with</simpara>\r
152 <literallayout>$ git branch -d experimental</literallayout>\r
153 <simpara>This command ensures that the changes in the experimental branch are\r
154 already in the current branch.</simpara>\r
155 <simpara>If you develop on a branch crazy-idea, then regret it, you can always\r
156 delete the branch with</simpara>\r
157 <literallayout>$ git branch -D crazy-idea</literallayout>\r
158 <simpara>Branches are cheap and easy, so this is a good way to try something\r
159 out.</simpara>\r
160 </simplesect>\r
161 <simplesect id="_using_git_for_collaboration">\r
162 <title>Using git for collaboration</title>\r
163 <simpara>Suppose that Alice has started a new project with a git repository in\r
164 /home/alice/project, and that Bob, who has a home directory on the\r
165 same machine, wants to contribute.</simpara>\r
166 <simpara>Bob begins with:</simpara>\r
167 <literallayout>bob$ git clone /home/alice/project myrepo</literallayout>\r
168 <simpara>This creates a new directory "myrepo" containing a clone of Alice&#8217;s\r
169 repository.  The clone is on an equal footing with the original\r
170 project, possessing its own copy of the original project&#8217;s history.</simpara>\r
171 <simpara>Bob then makes some changes and commits them:</simpara>\r
172 <literallayout>(edit files)\r
173 bob$ git commit -a\r
174 (repeat as necessary)</literallayout>\r
175 <simpara>When he&#8217;s ready, he tells Alice to pull changes from the repository\r
176 at /home/bob/myrepo.  She does this with:</simpara>\r
177 <literallayout>alice$ cd /home/alice/project\r
178 alice$ git pull /home/bob/myrepo master</literallayout>\r
179 <simpara>This merges the changes from Bob&#8217;s "master" branch into Alice&#8217;s\r
180 current branch.  If Alice has made her own changes in the meantime,\r
181 then she may need to manually fix any conflicts.</simpara>\r
182 <simpara>The "pull" command thus performs two operations: it fetches changes\r
183 from a remote branch, then merges them into the current branch.</simpara>\r
184 <simpara>Note that in general, Alice would want her local changes committed before\r
185 initiating this "pull".  If Bob&#8217;s work conflicts with what Alice did since\r
186 their histories forked, Alice will use her working tree and the index to\r
187 resolve conflicts, and existing local changes will interfere with the\r
188 conflict resolution process (git will still perform the fetch but will\r
189 refuse to merge --- Alice will have to get rid of her local changes in\r
190 some way and pull again when this happens).</simpara>\r
191 <simpara>Alice can peek at what Bob did without merging first, using the "fetch"\r
192 command; this allows Alice to inspect what Bob did, using a special\r
193 symbol "FETCH_HEAD", in order to determine if he has anything worth\r
194 pulling, like this:</simpara>\r
195 <literallayout>alice$ git fetch /home/bob/myrepo master\r
196 alice$ git log -p HEAD..FETCH_HEAD</literallayout>\r
197 <simpara>This operation is safe even if Alice has uncommitted local changes.\r
198 The range notation HEAD..FETCH_HEAD" means "show everything that is reachable\r
199 from the FETCH_HEAD but exclude anything that is reachable from HEAD.\r
200 Alice already knows everything that leads to her current state (HEAD),\r
201 and reviewing what Bob has in his state (FETCH_HEAD) that she has not\r
202 seen with this command</simpara>\r
203 <simpara>If Alice wants to visualize what Bob did since their histories forked\r
204 she can issue the following command:</simpara>\r
205 <literallayout>$ gitk HEAD..FETCH_HEAD</literallayout>\r
206 <simpara>This uses the same two-dot range notation we saw earlier with <emphasis>git log</emphasis>.</simpara>\r
207 <simpara>Alice may want to view what both of them did since they forked.\r
208 She can use three-dot form instead of the two-dot form:</simpara>\r
209 <literallayout>$ gitk HEAD...FETCH_HEAD</literallayout>\r
210 <simpara>This means "show everything that is reachable from either one, but\r
211 exclude anything that is reachable from both of them".</simpara>\r
212 <simpara>Please note that these range notation can be used with both gitk\r
213 and "git log".</simpara>\r
214 <simpara>After inspecting what Bob did, if there is nothing urgent, Alice may\r
215 decide to continue working without pulling from Bob.  If Bob&#8217;s history\r
216 does have something Alice would immediately need, Alice may choose to\r
217 stash her work-in-progress first, do a "pull", and then finally unstash\r
218 her work-in-progress on top of the resulting history.</simpara>\r
219 <simpara>When you are working in a small closely knit group, it is not\r
220 unusual to interact with the same repository over and over\r
221 again.  By defining <emphasis>remote</emphasis> repository shorthand, you can make\r
222 it easier:</simpara>\r
223 <literallayout>alice$ git remote add bob /home/bob/myrepo</literallayout>\r
224 <simpara>With this, Alice can perform the first part of the "pull" operation alone using the\r
225 <emphasis>git-fetch</emphasis> command without merging them with her own branch,\r
226 using:</simpara>\r
227 <literallayout>alice$ git fetch bob</literallayout>\r
228 <simpara>Unlike the longhand form, when Alice fetches from Bob using a\r
229 remote repository shorthand set up with <emphasis>git-remote</emphasis>, what was\r
230 fetched is stored in a remote tracking branch, in this case\r
231 <literal>bob/master</literal>.  So after this:</simpara>\r
232 <literallayout>alice$ git log -p master..bob/master</literallayout>\r
233 <simpara>shows a list of all the changes that Bob made since he branched from\r
234 Alice&#8217;s master branch.</simpara>\r
235 <simpara>After examining those changes, Alice\r
236 could merge the changes into her master branch:</simpara>\r
237 <literallayout>alice$ git merge bob/master</literallayout>\r
238 <simpara>This <literal>merge</literal> can also be done by <emphasis>pulling from her own remote\r
239 tracking branch</emphasis>, like this:</simpara>\r
240 <literallayout>alice$ git pull . remotes/bob/master</literallayout>\r
241 <simpara>Note that git pull always merges into the current branch,\r
242 regardless of what else is given on the command line.</simpara>\r
243 <simpara>Later, Bob can update his repo with Alice&#8217;s latest changes using</simpara>\r
244 <literallayout>bob$ git pull</literallayout>\r
245 <simpara>Note that he doesn&#8217;t need to give the path to Alice&#8217;s repository;\r
246 when Bob cloned Alice&#8217;s repository, git stored the location of her\r
247 repository in the repository configuration, and that location is\r
248 used for pulls:</simpara>\r
249 <literallayout>bob$ git config --get remote.origin.url\r
250 /home/alice/project</literallayout>\r
251 <simpara>(The complete configuration created by <emphasis>git-clone</emphasis> is visible using\r
252 <literal>git config -l</literal>, and the <xref linkend="git-config(1)"/> man page\r
253 explains the meaning of each option.)</simpara>\r
254 <simpara>Git also keeps a pristine copy of Alice&#8217;s master branch under the\r
255 name "origin/master":</simpara>\r
256 <literallayout>bob$ git branch -r\r
257   origin/master</literallayout>\r
258 <simpara>If Bob later decides to work from a different host, he can still\r
259 perform clones and pulls using the ssh protocol:</simpara>\r
260 <literallayout>bob$ git clone alice.org:/home/alice/project myrepo</literallayout>\r
261 <simpara>Alternatively, git has a native protocol, or can use rsync or http;\r
262 see <xref linkend="git-pull(1)"/> for details.</simpara>\r
263 <simpara>Git can also be used in a CVS-like mode, with a central repository\r
264 that various users push changes to; see <xref linkend="git-push(1)"/> and\r
265 <xref linkend="gitcvs-migration(7)"/>.</simpara>\r
266 </simplesect>\r
267 <simplesect id="_exploring_history">\r
268 <title>Exploring history</title>\r
269 <simpara>Git history is represented as a series of interrelated commits.  We\r
270 have already seen that the <emphasis>git-log</emphasis> command can list those commits.\r
271 Note that first line of each git log entry also gives a name for the\r
272 commit:</simpara>\r
273 <literallayout>$ git log\r
274 commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7\r
275 Author: Junio C Hamano &lt;junkio@cox.net&gt;\r
276 Date:   Tue May 16 17:18:22 2006 -0700\r
277 \r
278     merge-base: Clarify the comments on post processing.</literallayout>\r
279 <simpara>We can give this name to <emphasis>git-show</emphasis> to see the details about this\r
280 commit.</simpara>\r
281 <literallayout>$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7</literallayout>\r
282 <simpara>But there are other ways to refer to commits.  You can use any initial\r
283 part of the name that is long enough to uniquely identify the commit:</simpara>\r
284 <literallayout>$ git show c82a22c39c   # the first few characters of the name are\r
285                         # usually enough\r
286 $ git show HEAD         # the tip of the current branch\r
287 $ git show experimental # the tip of the "experimental" branch</literallayout>\r
288 <simpara>Every commit usually has one "parent" commit\r
289 which points to the previous state of the project:</simpara>\r
290 <literallayout>$ git show HEAD^  # to see the parent of HEAD\r
291 $ git show HEAD^^ # to see the grandparent of HEAD\r
292 $ git show HEAD~4 # to see the great-great grandparent of HEAD</literallayout>\r
293 <simpara>Note that merge commits may have more than one parent:</simpara>\r
294 <literallayout>$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)\r
295 $ git show HEAD^2 # show the second parent of HEAD</literallayout>\r
296 <simpara>You can also give commits names of your own; after running</simpara>\r
297 <literallayout>$ git tag v2.5 1b2e1d63ff</literallayout>\r
298 <simpara>you can refer to 1b2e1d63ff by the name "v2.5".  If you intend to\r
299 share this name with other people (for example, to identify a release\r
300 version), you should create a "tag" object, and perhaps sign it; see\r
301 <xref linkend="git-tag(1)"/> for details.</simpara>\r
302 <simpara>Any git command that needs to know a commit can take any of these\r
303 names.  For example:</simpara>\r
304 <literallayout>$ git diff v2.5 HEAD     # compare the current HEAD to v2.5\r
305 $ git branch stable v2.5 # start a new branch named "stable" based\r
306                          # at v2.5\r
307 $ git reset --hard HEAD^ # reset your current branch and working\r
308                          # directory to its state at HEAD^</literallayout>\r
309 <simpara>Be careful with that last command: in addition to losing any changes\r
310 in the working directory, it will also remove all later commits from\r
311 this branch.  If this branch is the only branch containing those\r
312 commits, they will be lost.  Also, don&#8217;t use <emphasis>git-reset</emphasis> on a\r
313 publicly-visible branch that other developers pull from, as it will\r
314 force needless merges on other developers to clean up the history.\r
315 If you need to undo changes that you have pushed, use <emphasis>git-revert</emphasis>\r
316 instead.</simpara>\r
317 <simpara>The <emphasis>git-grep</emphasis> command can search for strings in any version of your\r
318 project, so</simpara>\r
319 <literallayout>$ git grep "hello" v2.5</literallayout>\r
320 <simpara>searches for all occurrences of "hello" in v2.5.</simpara>\r
321 <simpara>If you leave out the commit name, <emphasis>git-grep</emphasis> will search any of the\r
322 files it manages in your current directory.  So</simpara>\r
323 <literallayout>$ git grep "hello"</literallayout>\r
324 <simpara>is a quick way to search just the files that are tracked by git.</simpara>\r
325 <simpara>Many git commands also take sets of commits, which can be specified\r
326 in a number of ways.  Here are some examples with <emphasis>git-log</emphasis>:</simpara>\r
327 <literallayout>$ git log v2.5..v2.6            # commits between v2.5 and v2.6\r
328 $ git log v2.5..                # commits since v2.5\r
329 $ git log --since="2 weeks ago" # commits from the last 2 weeks\r
330 $ git log v2.5.. Makefile       # commits since v2.5 which modify\r
331                                 # Makefile</literallayout>\r
332 <simpara>You can also give <emphasis>git-log</emphasis> a "range" of commits where the first is not\r
333 necessarily an ancestor of the second; for example, if the tips of\r
334 the branches "stable-release" and "master" diverged from a common\r
335 commit some time ago, then</simpara>\r
336 <literallayout>$ git log stable..experimental</literallayout>\r
337 <simpara>will list commits made in the experimental branch but not in the\r
338 stable branch, while</simpara>\r
339 <literallayout>$ git log experimental..stable</literallayout>\r
340 <simpara>will show the list of commits made on the stable branch but not\r
341 the experimental branch.</simpara>\r
342 <simpara>The <emphasis>git-log</emphasis> command has a weakness: it must present commits in a\r
343 list.  When the history has lines of development that diverged and\r
344 then merged back together, the order in which <emphasis>git-log</emphasis> presents\r
345 those commits is meaningless.</simpara>\r
346 <simpara>Most projects with multiple contributors (such as the Linux kernel,\r
347 or git itself) have frequent merges, and <emphasis>gitk</emphasis> does a better job of\r
348 visualizing their history.  For example,</simpara>\r
349 <literallayout>$ gitk --since="2 weeks ago" drivers/</literallayout>\r
350 <simpara>allows you to browse any commits from the last 2 weeks of commits\r
351 that modified files under the "drivers" directory.  (Note: you can\r
352 adjust gitk&#8217;s fonts by holding down the control key while pressing\r
353 "-" or "+".)</simpara>\r
354 <simpara>Finally, most commands that take filenames will optionally allow you\r
355 to precede any filename by a commit, to specify a particular version\r
356 of the file:</simpara>\r
357 <literallayout>$ git diff v2.5:Makefile HEAD:Makefile.in</literallayout>\r
358 <simpara>You can also use <emphasis>git-show</emphasis> to see any such file:</simpara>\r
359 <literallayout>$ git show v2.5:Makefile</literallayout>\r
360 </simplesect>\r
361 <simplesect id="_next_steps">\r
362 <title>Next Steps</title>\r
363 <simpara>This tutorial should be enough to perform basic distributed revision\r
364 control for your projects.  However, to fully understand the depth\r
365 and power of git you need to understand two simple ideas on which it\r
366 is based:</simpara>\r
367 <itemizedlist>\r
368 <listitem>\r
369 <simpara>\r
370 The object database is the rather elegant system used to\r
371     store the history of your project&#8212;files, directories, and\r
372     commits.\r
373 </simpara>\r
374 </listitem>\r
375 <listitem>\r
376 <simpara>\r
377 The index file is a cache of the state of a directory tree,\r
378     used to create commits, check out working directories, and\r
379     hold the various trees involved in a merge.\r
380 </simpara>\r
381 </listitem>\r
382 </itemizedlist>\r
383 <simpara>Part two of this tutorial explains the object\r
384 database, the index file, and a few other odds and ends that you&#8217;ll\r
385 need to make the most of git. You can find it at <xref linkend="gittutorial-2(7)"/>.</simpara>\r
386 <simpara>If you don&#8217;t want to continue with that right away, a few other\r
387 digressions that may be interesting at this point are:</simpara>\r
388 <itemizedlist>\r
389 <listitem>\r
390 <simpara>\r
391 <xref linkend="git-format-patch(1)"/>, <xref linkend="git-am(1)"/>: These convert\r
392     series of git commits into emailed patches, and vice versa,\r
393     useful for projects such as the Linux kernel which rely heavily\r
394     on emailed patches.\r
395 </simpara>\r
396 </listitem>\r
397 <listitem>\r
398 <simpara>\r
399 <xref linkend="git-bisect(1)"/>: When there is a regression in your\r
400     project, one way to track down the bug is by searching through\r
401     the history to find the exact commit that&#8217;s to blame.  Git bisect\r
402     can help you perform a binary search for that commit.  It is\r
403     smart enough to perform a close-to-optimal search even in the\r
404     case of complex non-linear history with lots of merged branches.\r
405 </simpara>\r
406 </listitem>\r
407 <listitem>\r
408 <simpara>\r
409 <ulink url="everyday.html">Everyday GIT with 20 Commands Or So</ulink>\r
410 </simpara>\r
411 </listitem>\r
412 <listitem>\r
413 <simpara>\r
414 <xref linkend="gitcvs-migration(7)"/>: Git for CVS users.\r
415 </simpara>\r
416 </listitem>\r
417 </itemizedlist>\r
418 </simplesect>\r
419 <simplesect id="_see_also">\r
420 <title>SEE ALSO</title>\r
421 <simpara><xref linkend="gittutorial-2(7)"/>,\r
422 <xref linkend="gitcvs-migration(7)"/>,\r
423 <xref linkend="gitcore-tutorial(7)"/>,\r
424 <xref linkend="gitglossary(7)"/>,\r
425 <xref linkend="git-help(1)"/>,\r
426 <ulink url="everyday.html">Everyday git</ulink>,\r
427 <ulink url="user-manual.html">The Git User&#8217;s Manual</ulink></simpara>\r
428 </simplesect>\r
429 <simplesect id="_git">\r
430 <title>GIT</title>\r
431 <simpara>Part of the <xref linkend="git(1)"/> suite.</simpara>\r
432 </simplesect>\r
433 </article>\r