@git / git-reference / commits / 3de8165

Update progit.org links to git-scm.com book version

Quickening event to redirect the links that used to be at progit.org to their new home at the git-scm.com book section. Deals with the English language links only.

Soon Van committed Dec 3, 2012 at 22:56 UTC 3de81653fa7560ff5f4aa74eb87d7bd9a31ef4be

6 files changed +107 -107

basic/index.html

+72 -72

@@ -5,7 +5,7 @@ layout: reference

5 <div class="box">

6 <h2>

7

8 - <a target="new" href="http://progit.org/book/ch2-2.html">book</a>

8 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository">book</a>

9

10 Basic Snapshotting

11 </h2>

@@ -19,13 +19,13 @@ layout: reference

19

20 An important concept here is that Git has an 'index', which acts as sort

21 of a staging area for your snapshot. This allows you to build up a series

22 - of well composed snapshots from changed files in your working directory,

22 + of well composed snapshots from changed files in your working directory,

23 rather than having to commit all of the file changes at once.

24

26

27 In a nutshell, you will use <code>git add</code> to start tracking new

28 - files and also to stage changes to already tracked files, then

28 + files and also to stage changes to already tracked files, then

29 <code>git status</code> and <code>git diff</code> to see what has been

30 modified and staged and finally <code>git commit</code> to record your

31 snapshot into your history. This will be the basic workflow that you use

@@ -39,7 +39,7 @@ layout: reference

39 <h2>

40

41 <a target="new" href="http://git-scm.com/docs/git-add">docs</a>

42 - <a target="new" href="http://progit.org/book/ch2-2.html#tracking_new_files">book</a>

42 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Tracking-New-Files">book</a>

43

44 <a name="add">git add</a>

45 adds file contents to the staging area

@@ -47,7 +47,7 @@ layout: reference

48 <div class="block">

49

50 - In Git, you have to add file contents to your staging area before you

50 + In Git, you have to add file contents to your staging area before you

51 can commit them. If the file is new, you can run <code>git add</code>

52 to initially add the file to your staging area, but even if the file

53 is already "tracked" - ie, it was in your last commit - you still need

@@ -56,7 +56,7 @@ layout: reference

56

58 Going back to our Hello World example, once we've initiated the project,

59 - we would now start adding our files to it and we would do that with

59 + we would now start adding our files to it and we would do that with

60 <code>git add</code>. We can use <code>git status</code> to see what the

61 state of our project is.

62

@@ -72,7 +72,7 @@ layout: reference

72 <pre>

73 $ git add README hello.rb

74 </pre>

75 -

75 +

76 Now if we run <code>git status</code> again, we'll see that they've been

77 added.

@@ -86,8 +86,8 @@ layout: reference

86 It is also common to recursively add all files in a new project by specifying

87 the current working directory like this: <code>git add .</code>. Since Git

88 will recursively add all files under a directory you give it, if you give it

89 - the current working directory, it will simply start tracking every file

90 - there. In this case, a <code>git add .</code> would have done the same

89 + the current working directory, it will simply start tracking every file

90 + there. In this case, a <code>git add .</code> would have done the same

91 thing as a <code>git add README hello.rb</code>, or for that matter so would

92 <code>git add *</code>, but that's only because we don't have subdirectories

93 which the <code>*</code> would not recurse into.

@@ -111,15 +111,15 @@ layout: reference

111

112

113

114 - In a nutshell,

115 - you run <code>git add</code> on a file when you want to

114 + In a nutshell,

115 + you run <code>git add</code> on a file when you want to

116 include whatever changes you've made to it in your next commit snapshot.

117 Anything you've changed that is not added will not be included - this means

118 you can craft your snapshots with a bit more precision than most other SCM

119 systems.

120

121 For a very interesting example of using this flexibility to stage only

122 - parts of modified files at a time, see the '-p' option to

122 + parts of modified files at a time, see the '-p' option to

123 <code>git add</code> in the Pro Git book.

124

125

@@ -131,7 +131,7 @@ layout: reference

131 <h2>

132

133 <a target="new" href="http://git-scm.com/docs/git-status">docs</a>

134 - <a target="new" href="http://progit.org/book/ch2-2.html#checking_the_status_of_your_files">book</a>

134 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Checking-the-Status-of-Your-Files">book</a>

135

136 <a name="status">git status</a>

137 view the status of your files in the working directory and staging area

@@ -139,11 +139,11 @@ layout: reference

139

140 <div class="block">

141 As you saw in the <code>git add</code> section, in order to see what the

142 - status of your staging area is compared to the code in your working

142 + status of your staging area is compared to the code in your working

143 directory, you can run the <code>git status</code> command. I demonstrated

144 using it with the <code>-s</code> option, which gives you short output.

145 Without that flag, the <code>git status</code> command will give you more

146 - context and hints. Here is the same status output with and without the

146 + context and hints. Here is the same status output with and without the

147 <code>-s</code>. The short output looks like this:

148

149

@@ -176,11 +176,11 @@ layout: reference

176 </pre>

177

178 You can easily see how much more compact the short output is, but the

179 - long output has useful tips and hints as to what commands you may want to

179 + long output has useful tips and hints as to what commands you may want to

180 use next.

181

182

183 - Git will also tell you about files that were deleted since your last

183 + Git will also tell you about files that were deleted since your last

184 commit or files that were modified or staged since your last commit.

185

186 <pre>

@@ -192,7 +192,7 @@ layout: reference

192 You can see there are two columns in the short status output. The first

193 column is for the staging area, the second is for the working directory.

194 So for example, if you have the README file staged and then you modify

195 - it again without running <code>git add</code> a second time, you'll see

195 + it again without running <code>git add</code> a second time, you'll see

196 this:

197

198 <pre>

@@ -202,8 +202,8 @@ layout: reference

202 </pre>

203

204

205 - In a nutshell,

206 - you run <code>git status</code> to see if anything has been modified

205 + In a nutshell,

206 + you run <code>git status</code> to see if anything has been modified

207 and/or staged since your last commit so you can decide if you want to

208 commit a new snapshot and what will be recorded in it.

209

@@ -215,7 +215,7 @@ layout: reference

215 <h2>

216

217 <a target="new" href="http://git-scm.com/docs/git-diff">docs</a>

218 - <a target="new" href="http://progit.org/book/ch2-2.html#viewing_your_staged_and_unstaged_changes">book</a>

218 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Viewing-Your-Staged-and-Unstaged-Changes">book</a>

219

220 <a name="diff">git diff</a>

221 shows diff of what is staged and what is modified but unstaged

@@ -223,7 +223,7 @@ layout: reference

223

224 <div class="block">

225 There are two main uses of the <code>git diff</code> command. One use we

226 - will describe here, the other we will describe later in the

226 + will describe here, the other we will describe later in the

227 <a href="/inspect">"Inspection and Comparison"</a>

228 section. The way we're going to use it here is to describe the

229 changes that are staged or modified on disk but unstaged.

@@ -250,16 +250,16 @@ index d62ac43..8d15d50 100644

250 +++ b/hello.rb

251 @@ -1,7 +1,7 @@

252 class HelloWorld

253 -

253 +

254 def self.hello

255 - puts "hello world"

256 + puts "hola mundo"

257 end

258 -

258 +

259 end

260 </pre>

261

262 - So where <code>git status</code> will show you what files have changed

262 + So where <code>git status</code> will show you what files have changed

263 and/or been staged since your last commit, <code>git diff</code> will

264 show you what those changes actually are, line by line. It's generally

265 a good follow-up command to <code>git status</code>

@@ -271,9 +271,9 @@ index d62ac43..8d15d50 100644

271 </h4>

272

273 The <code>git diff --cached</code> command will show you what contents

274 - have been staged. That is, this will show you the changes that will

274 + have been staged. That is, this will show you the changes that will

275 currently go into the next commit snapshot. So, if you were to stage

276 - the change to <code>hello.rb</code> in the example above,

276 + the change to <code>hello.rb</code> in the example above,

277 <code>git diff</code> by itself won't show you any output because it will

278 only show you what is not yet staged.

279

@@ -288,7 +288,7 @@ index d62ac43..8d15d50 100644

288 $

289 </pre>

290

291 - If you want to see the staged changes, you can run

291 + If you want to see the staged changes, you can run

292 <code>git diff --cached</code> instead.

293

294 <pre>

@@ -303,12 +303,12 @@ index d62ac43..8d15d50 100644

303 +++ b/hello.rb

304 @@ -1,7 +1,7 @@

305 class HelloWorld

306 -

306 +

307 def self.hello

308 - puts "hello world"

309 + puts "hola mundo"

310 end

311 -

311 +

312 end

313 </pre>

314

@@ -320,7 +320,7 @@ index d62ac43..8d15d50 100644

320 If you want to see both staged and unstaged changes together, you

321 can run <code>git diff HEAD</code> - this basically means you want to

322 see the difference between your working directory and the last commit,

323 - ignoring the staging area. If we make another change to our

323 + ignoring the staging area. If we make another change to our

324 <code>hello.rb</code> file then we'll have some changes staged and some

325 changes unstaged. Here are what all three <code>diff</code> commands

326 will show you:

@@ -333,12 +333,12 @@ index 4f40006..2ae9ba4 100644

333 +++ b/hello.rb

334 @@ -1,7 +1,7 @@

335 class HelloWorld

336 -

336 +

337 + # says hello

338 def self.hello

339 puts "hola mundo"

340 end

341 -

341 +

342 end

343 $ git diff --cached

344 diff --git a/hello.rb b/hello.rb

@@ -347,12 +347,12 @@ index 2aabb6e..4f40006 100644

347 +++ b/hello.rb

348 @@ -1,7 +1,7 @@

349 class HelloWorld

350 -

350 +

351 def self.hello

352 - puts "hello world"

353 + puts "hola mundo"

354 end

355 -

355 +

356 end

357 $ git diff HEAD

358 diff --git a/hello.rb b/hello.rb

@@ -361,13 +361,13 @@ index 2aabb6e..2ae9ba4 100644

361 +++ b/hello.rb

362 @@ -1,7 +1,8 @@

363 class HelloWorld

364 -

364 +

365 + # says hello

366 def self.hello

367 - puts "hello world"

368 + puts "hola mundo"

369 end

370 -

370 +

371 end

372 </pre>

373

@@ -381,7 +381,7 @@ index 2aabb6e..2ae9ba4 100644

381 option, which will give us a summary of changes instead. Here is the

382 same example as above, but using the <code>--stat</code> option instead.

383

384 -

384 +

385 <pre>

386 $ git status -s

387 MM hello.rb

@@ -403,10 +403,10 @@ index 2aabb6e..2ae9ba4 100644

403

404

405

406 - In a nutshell,

406 + In a nutshell,

407 you run <code>git diff</code> to see details of the <code>git status</code>

408 command - how files have been modified or staged on a line by line

409 - basis.

409 + basis.

410

411

412

@@ -417,7 +417,7 @@ index 2aabb6e..2ae9ba4 100644

417 <h2>

418

419 <a target="new" href="http://git-scm.com/docs/git-commit">docs</a>

420 - <a target="new" href="http://progit.org/book/ch2-2.html#committing_your_changes">book</a>

420 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Committing-Your-Changes">book</a>

421

422 <a name="commit">git commit</a>

423 records a snapshot of the staging area

@@ -425,7 +425,7 @@ index 2aabb6e..2ae9ba4 100644

425

426 <div class="block">

427

428 - Now that you have staged the content you want to snapshot with the

428 + Now that you have staged the content you want to snapshot with the

429 <code>git add</code> command, you run <code>git commit</code> to actually

430 record the snapshot.

431 Git records your name and email address with every commit you make,

@@ -438,7 +438,7 @@ index 2aabb6e..2ae9ba4 100644

438 </pre>

439

440 Let's stage and commit all the changes to our

441 - <code>hello.rb</code> file. In this first example, we'll use the

441 + <code>hello.rb</code> file. In this first example, we'll use the

442 <code>-m</code> option to provide the commit message on the command line.

443

444

@@ -488,10 +488,10 @@ nothing to commit (working directory clean)

488 the output of the <code>git status</code> command in there for you as

489 a reminder of what you have modified and staged.

490

491 - In general, it's very important to write a good commit message.

491 + In general, it's very important to write a good commit message.

492 For open source projects, it's generally a rule to write your message

493 more or less in this format:

494 -

494 +

495 <pre>

496 Short (50 chars or less) summary of changes

497

@@ -531,7 +531,7 @@ Further paragraphs come after blank lines.

531 four commits of logically separate changes so that your work may be more

532 easily peer reviewed. Since there is a separation between committing and

533 pushing those changes, do take the time to make it easier for the people

534 - you are working with to see what you've done by putting each logically

534 + you are working with to see what you've done by putting each logically

535 separate change in a separate commit with a nice commit message so it

536 is easier for them to see what you are doing and why.

537

@@ -540,8 +540,8 @@ Further paragraphs come after blank lines.

540 automatically stage all tracked, modified files before the commit

541 </h4>

542

543 - If you think the <code>git add</code> stage of the workflow is too

544 - cumbersome, Git allows you to skip that part with the <code>-a</code>

543 + If you think the <code>git add</code> stage of the workflow is too

544 + cumbersome, Git allows you to skip that part with the <code>-a</code>

545 option. This basically tells Git to run <code>git add</code> on any file

546 that is "tracked" - that is, any file that was in your last commit and

547 has been modified. This allows you to do a more Subversion style workflow

@@ -569,7 +569,7 @@ Further paragraphs come after blank lines.

569 1 files changed, 2 insertions(+), 1 deletions(-)

570 </pre>

571

572 - Notice how if you don't stage any changes and then run

572 + Notice how if you don't stage any changes and then run

573 <code>git commit</code>, Git will simply give you the output of the

574 <code>git status</code> command, reminding you that nothing is staged.

575 I've highlighted the important part of that message, saying that nothing

@@ -584,7 +584,7 @@ Further paragraphs come after blank lines.

584 to actually record the snapshot forever.

585

586

587 - In a nutshell,

587 + In a nutshell,

588 you run <code>git commit</code> to record the snapshot of your staged

589 content. This snapshot can then be compared, shared and reverted to

590 if you need to.

@@ -597,7 +597,7 @@ Further paragraphs come after blank lines.

597 <h2>

598

599 <a target="new" href="http://git-scm.com/docs/git-reset">docs</a>

600 - <a target="new" href="http://progit.org/book/ch2-4.html#unstaging_a_staged_file">book</a>

600 + <a target="new" href="http://git-scm.com/book/ch2-4.html#Unstaging-a-Staged-File">book</a>

601

602 <a name="reset">git reset HEAD</a>

603 unstage changes that you have staged

@@ -605,18 +605,18 @@ Further paragraphs come after blank lines.

605

606 <div class="block">

607 <code>git reset</code> is probably the most confusing command written

608 - by humans. I've been using Git for years, even wrote a book on it and I

609 - still get confused by what it is going to do at times. So, I'll just

610 - tell you the three specific invocations of it that are generally

611 - helpful and ask you to blindly use it as I do - because it can be

608 + by humans. I've been using Git for years, even wrote a book on it and I

609 + still get confused by what it is going to do at times. So, I'll just

610 + tell you the three specific invocations of it that are generally

611 + helpful and ask you to blindly use it as I do - because it can be

612 very useful.

613

614

615 - In this case, we can use it to unstage something that you have

615 + In this case, we can use it to unstage something that you have

616 accidentally staged. Let's say that you have modified two files and want

617 to record them into two different commits. You should stage and commit

618 one, then stage and commit the other. If you accidentally stage both of

619 - them, how do you un-stage one? You do it with

619 + them, how do you un-stage one? You do it with

620 <code>git reset HEAD -- file</code>. Technically here you don't have to

621 add the <code>--</code> - it is used to tell Git when you have stopped

622 listing options and are now listing file paths, but it's probably good to

@@ -659,9 +659,9 @@ M hello.rb

659

660

661 If you want to be able to just run <code>git unstage</code>, you can easily

662 - setup an alias in Git. Just run

663 - <code>git config --global alias.unstage "reset HEAD"</code>.

664 - Once you have run that, you can then just run

662 + setup an alias in Git. Just run

663 + <code>git config --global alias.unstage "reset HEAD"</code>.

664 + Once you have run that, you can then just run

665 <code>git unstage [file]</code> instead.

666

667

@@ -683,7 +683,7 @@ M hello.rb

683 </pre>

684

685

686 - In a nutshell,

686 + In a nutshell,

687 you run <code>git reset HEAD</code> to unstage files that you previously

688 ran <code>git add</code> on and wish to not include in the next commit

689 snapshot

@@ -695,7 +695,7 @@ M hello.rb

695 <h2>

696

697 <a href="http://git-scm.com/docs/git-rm">docs</a>

698 - <a href="http://progit.org/book/ch2-2.html#removing_files">book</a>

698 + <a href="http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository#Removing-Files">book</a>

699

700 <a name="rm-mv">git rm</a>

701 remove files from the staging area

@@ -703,18 +703,18 @@ M hello.rb

703

704 <div class="block">

705

706 - <code>git rm</code> will remove entries from the staging area.

707 - This is a bit different from <code>git reset HEAD</code> which "unstages"

708 - files. By "unstage" I mean it reverts the staging area to what was

709 - there before we started modifying things. <code>git rm</code> on the

710 - other hand just kicks the file off the stage entirely, so that it's not

706 + <code>git rm</code> will remove entries from the staging area.

707 + This is a bit different from <code>git reset HEAD</code> which "unstages"

708 + files. By "unstage" I mean it reverts the staging area to what was

709 + there before we started modifying things. <code>git rm</code> on the

710 + other hand just kicks the file off the stage entirely, so that it's not

711 included in the next commit snapshot, thereby effectively deleting it.

712

713 - By default, a <code>git rm file</code> will remove the file from the

713 + By default, a <code>git rm file</code> will remove the file from the

714 staging area entirely and also off your disk (the working directory). To

715 leave the file in the working directory, you can use <code>git rm --cached

716 </code>.

717 -

717 +

718 <h4>

719 git mv

720 git rm --cached orig; mv orig new; git add new

@@ -725,7 +725,7 @@ M hello.rb

725 Instead, it just tracks the snapshots and then figures out what files were

726 likely renamed by comparing snapshots. If a file was removed from one

727 snapshot and another file was added to the next one and the contents are

728 - similar, Git figures it was most likely a rename. So, although the

728 + similar, Git figures it was most likely a rename. So, although the

729 <code>git mv</code> command exists, it is superfluous - all it does is a

730 <code>git rm --cached</code>, moves the file on disk, then runs a

731 <code>git add</code> on the new file. You don't really need to use it, but

@@ -739,8 +739,8 @@ M hello.rb

739 from your index, too.

740

741

742 - In a nutshell,

743 - you run <code>git rm</code> to remove files from being tracked in Git. It

742 + In a nutshell,

743 + you run <code>git rm</code> to remove files from being tracked in Git. It

744 will also remove them from your working directory.

745

746

branching/index.html

+7 -7

@@ -5,7 +5,7 @@ layout: reference

5 <div class="box">

6 <h2>

7

8 - <a target="new" href="http://progit.org/book/ch3-0.html">book</a>

8 + <a target="new" href="http://git-scm.com/book/en/Git-Branching">book</a>

9

10 Branching and Merging

11 </h2>

@@ -39,7 +39,7 @@ layout: reference

39 <h2>

40

41 <a target="new" href="http://git-scm.com/docs/git-branch">docs</a>

42 - <a target="new" href="http://progit.org/book/ch3-2.html">book</a>

42 + <a target="new" href="http://git-scm.com/book/en/Git-Branching-What-a-Branch-Is">book</a>

43

44 <a name="branch">git branch</a>

45 list, create and manage working contexts

@@ -50,7 +50,7 @@ layout: reference

50 <h2>

51

52 <a target="new" href="http://git-scm.com/docs/git-checkout">docs</a>

53 - <a target="new" href="http://progit.org/book/ch3-2.html">book</a>

53 + <a target="new" href="http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging">book</a>

54

55 <a name="checkout">git checkout</a>

56 switch to a new branch context

@@ -72,7 +72,7 @@ layout: reference

72 Without arguments, <code>git branch</code> will list out the local

73 branches that you have. The branch that you are currently working on will

74 have a star next to it and if you have

75 - <a href="http://progit.org/book/ch7-1.html#colors_in_git">coloring turned on</a>,

75 + <a href="http://git-scm.com/book/en/Customizing-Git-Git-Configuration#Colors-in-Git">coloring turned on</a>,

76 will show the current branch in green.

77

@@ -227,7 +227,7 @@ Deleted branch testing (was 78b2670).

227 <h2>

228

229 <a target="new" href="http://git-scm.com/docs/git-merge">docs</a>

230 - <a target="new" href="http://progit.org/book/ch3-2.html#basic_merging">book</a>

230 + <a target="new" href="http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging#Basic-Merging">book</a>

231

232 <a name="merge">git merge</a>

233 merge a branch context into your current one

@@ -473,7 +473,7 @@ M README

473 <h2>

474

475 <a target="new" href="http://git-scm.com/docs/git-log">docs</a>

476 - <a target="new" href="http://progit.org/book/ch6-1.html#commit_ranges">book</a>

476 + <a target="new" href="http://git-scm.com/book/en/Git-Tools-Revision-Selection#Commit-Ranges">book</a>

477

478 <a name="log">git log</a>

479 show commit history of a branch

@@ -696,7 +696,7 @@ ab5ab4c added erlang

696 <h2>

697

698 <a target="new" href="http://git-scm.com/docs/git-tag">docs</a>

699 - <a target="new" href="http://progit.org/book/ch2-6.html">book</a>

699 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Tagging">book</a>

700

701 <a name="tag">git tag</a>

702 tag a point in history as important

creating/index.html

+5 -5

@@ -24,7 +24,7 @@ layout: reference

24 <h2>

25

26 <a target="new" href="http://git-scm.com/docs/git-init">docs</a>

27 - <a target="new" href="http://progit.org/book/ch2-1.html#initializing_a_repository_in_an_existing_directory">book</a>

27 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository#Initializing-a-Repository-in-an-Existing-Directory">book</a>

28

29 <a name="init">git init</a>

30 initializes a directory as a Git repository

@@ -75,7 +75,7 @@ Initialized empty Git repository in /opt/konichiwa/.git/

75 <h2>

76

77 <a target="new" href="http://git-scm.com/docs/git-clone">docs</a>

78 - <a target="new" href="http://progit.org/book/ch2-1.html#cloning_an_existing_repository">book</a>

78 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository#Cloning-an-Existing-Repository">book</a>

79

80 <a name="clone">git clone</a>

81 copy a git repository so you can add to it

@@ -84,7 +84,7 @@ Initialized empty Git repository in /opt/konichiwa/.git/

84

85 If you need to collaborate with someone on a project, or if you want to

86 get a copy of a project so you can look at or use the code, you will

87 - clone it. You simply run the <code>git clone [url]</code> command with

87 + clone it. You simply run the <code>git clone [url]</code> command with

88 the URL of the project you want to copy.

89

@@ -120,14 +120,14 @@ config index objects

120 </pre>

121

122

123 - By default, Git will create a directory that is the same name as the

123 + By default, Git will create a directory that is the same name as the

124 project in the URL you give it - basically whatever is after the last slash

125 of the URL. If you want something different, you can just put it at the

126 end of the command, after the URL.

127

128

129

130 - In a nutshell, you use <code>git clone</code> to get a

130 + In a nutshell, you use <code>git clone</code> to get a

131 local copy of a Git repository so you can look at it or start modifying

132 it.

133

index.html

+14 -14

@@ -16,9 +16,9 @@ layout: reference

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://progit.org">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

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

24 </div>

@@ -29,7 +29,7 @@ layout: reference

29 <div class="block">

30

31 The first thing that is important to understand about Git is

32 - that it thinks about version control very differently than

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

@@ -37,16 +37,16 @@ layout: reference

37

39

40 - Let's start from scratch. Assume you are designing a new source

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

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

46 <pre> $ cp -R project project.bak </pre>

48

49 - That way, you can easily revert files that get messed up later, or

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

@@ -59,8 +59,8 @@ layout: reference

59 <pre> $ cp -R project project.2010-06-01.bak </pre>

61

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

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.

@@ -77,7 +77,7 @@ layout: reference

78

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

80 + project and they have your changes. This is how many open source

81 projects have been collaborated on for several years.

82

@@ -91,10 +91,10 @@ layout: reference

92

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

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.

97 + how they differ or pull content out of them, etc.

98

100 <center><img src="./images/snapshots.png"/></center>

@@ -102,7 +102,7 @@ layout: reference

102

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

105 + it may be easier to understand what is going on and how to do things

106 properly.

107

108

inspect/index.html

+4 -4

@@ -5,7 +5,7 @@ layout: reference

5 <div class="box">

6 <h2>

7

8 - <a target="new" href="http://progit.org/book/ch2-3.html">book</a>

8 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-History">book</a>

9

10 Inspection and Comparison

11 </h2>

@@ -31,7 +31,7 @@ layout: reference

31 <h2>

32

33 <a target="new" href="http://git-scm.com/docs/git-log">docs</a>

34 - <a target="new" href="http://progit.org/book/ch2-3.html">book</a>

34 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Viewing-the-Commit-History#Limiting-Log-Output">book</a>

35

36 <a name="log">git log</a>

37 filter your commit history

@@ -310,7 +310,7 @@ Date: Fri Jun 4 12:58:53 2010 +0200

310 <h2>

311

312 <a target="new" href="http://git-scm.com/docs/git-diff">docs</a>

313 - <a target="new" href="http://progit.org/book/ch5-3.html#determining_what_is_introduced">book</a>

313 + <a target="new" href="http://git-scm.com/book/en/Distributed-Git-Maintaining-a-Project#Determining-What-Is-Introduced">book</a>

314

315 <a name="diff">git diff</a>

316

@@ -471,4 +471,4 @@ index bb86f00..192151c 100644

471 </div>

472

473 And that's it! For more information, try reading the

474 -<a href="http://progit.org">Pro Git book</a>.

474 +<a href="http://git-scm.com/book/">Pro Git book</a>.

remotes/index.html

+5 -5

@@ -5,7 +5,7 @@ layout: reference

5 <div class="box">

6 <h2>

7

8 - <a target="new" href="http://progit.org/book/ch2-5.html">book</a>

8 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Working-with-Remotes">book</a>

9

10 Sharing and Updating Projects

11 </h2>

@@ -44,7 +44,7 @@ layout: reference

44 <h2>

45

46 <a target="new" href="http://git-scm.com/docs/git-remote">docs</a>

47 - <a target="new" href="http://progit.org/book/ch2-5.html#showing_your_remotes">book</a>

47 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Working-with-Remotes#Showing-Your-Remotes">book</a>

48

49 <a name="remote">git remote</a>

50 list, add and delete remote repository aliases

@@ -160,7 +160,7 @@ github git@github.com:schacon/hw.git (push)

160 <h2>

161

162 <a target="new" href="http://git-scm.com/docs/git-fetch">docs</a>

163 - <a target="new" href="http://progit.org/book/ch2-5.html#fetching_and_pulling_from_your_remotes">book</a>

163 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Working-with-Remotes#Fetching-and-Pulling-from-Your-Remotes">book</a>

164

165 <a name="fetch">git fetch</a>

166 download new branches and data from a remote repository

@@ -171,7 +171,7 @@ github git@github.com:schacon/hw.git (push)

171 <h2>

172

173 <a target="new" href="http://git-scm.com/docs/git-pull">docs</a>

174 - <a target="new" href="http://progit.org/book/">book</a>

174 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Working-with-Remotes#Fetching-and-Pulling-from-Your-Remotes">book</a>

175

176 <a name="pull">git pull</a>

177 fetch from a remote repo and try to merge into the current branch

@@ -255,7 +255,7 @@ From github.com:schacon/hw

255 <h2>

256

257 <a target="new" href="http://git-scm.com/docs/git-push">docs</a>

258 - <a target="new" href="http://progit.org/book/ch2-5.html#pushing_to_your_remotes">book</a>

258 + <a target="new" href="http://git-scm.com/book/en/Git-Basics-Working-with-Remotes#Pushing-to-Your-Remotes">book</a>

259

260 <a name="push">git push</a>

261 push your new branches and data to a remote repository