Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions book/01-introduction/sections/basics.asc
Original file line number Diff line number Diff line change
Expand Up @@ -42,12 +42,12 @@ This also means that there is very little you can't do if you're offline or off
If you get on an airplane or a train and want to do a little work, you can commit happily (to your _local_ copy, remember?) until you get to a network connection to upload.
If you go home and can't get your VPN client working properly, you can still work.
In many other systems, doing so is either impossible or painful.
In Perforce, for example, you can't do much when you aren't connected to the server; and in Subversion and CVS, you can edit files, but you can't commit changes to your database (because your database is offline).
In Perforce, for example, you can't do much when you aren't connected to the server; in Subversion and CVS, you can edit files, but you can't commit changes to your database (because your database is offline).
This may not seem like a huge deal, but you may be surprised what a big difference it can make.

==== Git Has Integrity

Everything in Git is check-summed before it is stored and is then referred to by that checksum.
Everything in Git is checksummed before it is stored and is then referred to by that checksum.
This means it's impossible to change the contents of any file or directory without Git knowing about it.
This functionality is built into Git at the lowest levels and is integral to its philosophy.
You can't lose information in transit or get file corruption without Git being able to detect it.
Expand Down Expand Up @@ -102,7 +102,7 @@ The basic Git workflow goes something like this:
2. You selectively stage just those changes you want to be part of your next commit, which adds _only_ those changes to the staging area.
3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

If a particular version of a file is in the Git directory, it's considered committed.
If it has been modified and was added to the staging area, it is staged.
And if it was changed since it was checked out but has not been staged, it is modified.
If a particular version of a file is in the Git directory, it's considered _committed_.
If it has been modified and was added to the staging area, it is _staged_.
And if it was changed since it was checked out but has not been staged, it is _modified_.
In <<ch02-git-basics-chapter#ch02-git-basics-chapter>>, you'll learn more about these states and how you can either take advantage of them or skip the staged part entirely.