431e2cd · git/git-reference · siGit Code & Deploy

@@ -355,6 +355,31 @@ index 2aabb6e..2ae9ba4 100644

355 end

356 </pre>

357

358 + <h4>

359 + git diff --stat

360 + show summary of changes instead of a full diff

361 + </h4>

362 +

363 + If we don't want the full diff output, but we want more than the

364 + <code>git status</code> output, we can use the <code>--stat</code>

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

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

367 +

368 +

369 +<pre>

370 +$ git status -s

371 +MM hello.rb

372 +$ git diff --stat

373 + hello.rb | 1 +

374 + 1 files changed, 1 insertions(+), 0 deletions(-)

375 +$ git diff --cached --stat

376 + hello.rb | 2 +-

377 + 1 files changed, 1 insertions(+), 1 deletions(-)

378 +$ git diff HEAD --stat

379 + hello.rb | 3 ++-

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

381 +</pre>

382 +

383

384 You can also provide a file path at the end of any of these options

385 to limit the <code>diff</code> output to a specific file or subdirectory.

@@ -372,5 +397,175 @@ index 2aabb6e..2ae9ba4 100644

397 </div>

398 </div>

399

400 +<div class="box">

401 + <h2>

402 +

403 + <a href="#">docs</a>

404 + <a href="#">book</a>

405 +

406 + <a name="commit">git commit</a>

407 + records a snapshot of the staging area

408 + </h2>

409 +

410 + <div class="block">

411 +

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

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

414 + record the snapshot. Let's stage and commit all the changes to our

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

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

417 +

418 +

419 +<pre>

420 +$ git add hello.rb

421 +$ git status -s

422 +M hello.rb

423 +$ git commit -m 'my hola mundo changes'

424 +[master 68aa034] my hola mundo changes

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

426 +</pre>

427 +

428 + Now we have recorded the snapshot. If we run <code>git status</code>

429 + again, we will see that we have a "clean working directory", which means

430 + that we have not made any changes since our last commit - there is no

431 + un-snapshotted work in our checkout.

432 +

433 +<pre>

434 +$ git status

435 +# On branch master

436 +nothing to commit (working directory clean)

437 +</pre>

438 +

439 + If you leave off the <code>-m</code> option, Git will try to open a

440 + text editor for you to write your commit message. In <code>vim</code>,

441 + which it will default to if it can find nothing else in your settings,

442 + the screen might look something like this:

443 +

444 +

445 +<pre>

446 +

447 +# Please enter the commit message for your changes. Lines starting

448 +# with '#' will be ignored, and an empty message aborts the commit.

449 +# On branch master

450 +# Changes to be committed:

451 +# (use "git reset HEAD <file>..." to unstage)

452 +#

453 +# modified: hello.rb

454 +#

455 +~

456 +~

457 +".git/COMMIT_EDITMSG" 9L, 257C

458 +</pre>

459 +

460 + At this point you add your actual commit message at the top of the

461 + document. Any lines starting with '#' will be ignored - Git will put

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

463 + a reminder of what you have modified and staged.

464 +

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

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

467 + more or less in this format:

468 +

469 +<pre>

470 +Short (50 chars or less) summary of changes

471 +

472 +More detailed explanatory text, if necessary. Wrap it to about 72

473 +characters or so. In some contexts, the first line is treated as the

474 +subject of an email and the rest of the text as the body. The blank

475 +line separating the summary from the body is critical (unless you omit

476 +the body entirely); some git tools can get confused if you run the

477 +two together.

478 +

479 +Further paragraphs come after blank lines.

480 +

481 + - Bullet points are okay, too

482 +

483 + - Typically a hyphen or asterisk is used for the bullet, preceded by a

484 + single space, with blank lines in between, but conventions vary

485 + here

486 +

487 +# Please enter the commit message for your changes. Lines starting

488 +# with '#' will be ignored, and an empty message aborts the commit.

489 +# On branch master

490 +# Changes to be committed:

491 +# (use "git reset HEAD <file>..." to unstage)

492 +#

493 +# modified: hello.rb

494 +#

495 +~

496 +~

497 +~

498 +".git/COMMIT_EDITMSG" 25L, 884C written

499 +</pre>

500 +

501 +

502 + The commit message is very important. Since much of the power of

503 + Git is this flexibility in carefully crafting commits locally and then

504 + sharing them later, it is very powerful to be able to write three or

505 + four commits of logically seperate changes so that your work may be more

506 + easily peer reviewed. Since there is a seperation between committing and

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

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

509 + seperate change in a seperate commit with a nice commit message so it

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

511 +

512 + <h4>

513 + git commit -a

514 + automatically stage all tracked, modified files before the commit

515 + </h4>

516 +

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

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

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

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

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

522 + if you want, simply editing files and then running <code>git commit -a</code>

523 + when you want to snapshot everything that has been changed. You still need

524 + to run <code>git add</code> to start tracking new files, though, just like

525 + Subversion.

526 +

527 +

528 +<pre>

529 +$ vim hello.rb

530 +$ git status -s

531 + M hello.rb

532 +$ git commit -m 'changes to hello file'

533 +# On branch master

534 +# Changed but not updated:

535 +# (use "git add <file>..." to update what will be committed)

536 +# (use "git checkout -- <file>..." to discard changes in working directory)

537 +#

538 +# modified: hello.rb

539 +#

540 +no changes added to commit (use "git add" and/or "git commit -a")

541 +$ git commit -am 'changes to hello file'

542 +[master 78b2670] changes to hello file

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

544 +</pre>

545 +

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

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

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

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

550 + is added to be committed. If you use <code>-a</code>, it will add and

551 + commit everything at once.

552 +

553 +

554 + This now lets you complete the entire snapshotting workflow - you

555 + make changes to your files, then use <code>git add</code> to stage

556 + files you want to change, <code>git status</code> and <code>git diff</code>

557 + to see what you've changed, and then finally <code>git commit</code>

558 + to actually record the snapshot forever.

559 +

560 +

561 + In a nutshell,

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

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

564 + if you need to.

565 +

566 +

567 + </div>

568 +</div>

569 +

570 <a href="/basic">On to Branching and Merging »</a>

571

done with commit