You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: book/01-introduction/sections/basics.asc
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,12 +42,12 @@ This also means that there is very little you can't do if you're offline or off
42
42
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.
43
43
If you go home and can't get your VPN client working properly, you can still work.
44
44
In many other systems, doing so is either impossible or painful.
45
-
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).
45
+
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).
46
46
This may not seem like a huge deal, but you may be surprised what a big difference it can make.
47
47
48
48
==== Git Has Integrity
49
49
50
-
Everything in Git is check-summed before it is stored and is then referred to by that checksum.
50
+
Everything in Git is checksummed before it is stored and is then referred to by that checksum.
51
51
This means it's impossible to change the contents of any file or directory without Git knowing about it.
52
52
This functionality is built into Git at the lowest levels and is integral to its philosophy.
53
53
You can't lose information in transit or get file corruption without Git being able to detect it.
@@ -102,7 +102,7 @@ The basic Git workflow goes something like this:
102
102
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.
103
103
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.
104
104
105
-
If a particular version of a file is in the Git directory, it's considered committed.
106
-
If it has been modified and was added to the staging area, it is staged.
107
-
And if it was changed since it was checked out but has not been staged, it is modified.
105
+
If a particular version of a file is in the Git directory, it's considered _committed_.
106
+
If it has been modified and was added to the staging area, it is _staged_.
107
+
And if it was changed since it was checked out but has not been staged, it is _modified_.
108
108
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.
0 commit comments