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: .github/ISSUE_TEMPLATE/bug_report.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ assignees: ''
12
12
<!-- * This bug report is about a single actionable bug. -->
13
13
<!-- * This bug is about the Pro Git book, version 2, English language. -->
14
14
<!-- * This bug is about the book as found on the [website](https://www.git-scm.com/book/en/v2) or the pdf. -->
15
-
<!-- * If you found a issue in the pdf/epub/mobi files, you've checked if the problem is also present in the Pro Git book on the [website](https://www.git-scm.com/book/en/v2). -->
15
+
<!-- * If you found an issue in the pdf/epub/mobi files, you've checked if the problem is also present in the Pro Git book on the [website](https://www.git-scm.com/book/en/v2). -->
16
16
<!-- * This bug is **not** about a translation, if so please file a bug with the translation project. You can find a table of translation projects here: [progit2/TRANSLATING.md](https://github.com/progit/progit2/blob/master/TRANSLATING.md) -->
17
17
<!-- * This bug is **not** about the git-scm.com site, if so please file a bug here: [git-scm.com/issues/new](https://github.com/git/git-scm.com/issues/new) -->
18
18
<!-- * This bug is **not** about git the program itself, if so please file a bug here: [git-scm.com/community](https://git-scm.com/community) -->
@@ -58,7 +58,7 @@ assignees: ''
58
58
- Browser/application version:
59
59
60
60
**E-book reader:**
61
-
<!-- If you've used a e-book reader to access the content, please fill in this form. -->
61
+
<!-- If you've used an e-book reader to access the content, please fill in this form. -->
Copy file name to clipboardExpand all lines: book/01-introduction/sections/about-version-control.asc
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,7 +19,7 @@ It is easy to forget which directory you're in and accidentally write to the wro
19
19
20
20
To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.
21
21
22
-
.Local version control.
22
+
.Local version control
23
23
image::images/local.png[Local version control diagram]
24
24
25
25
One of the most popular VCS tools was a system called RCS, which is still distributed with many computers today.
@@ -33,7 +33,7 @@ To deal with this problem, Centralized Version Control Systems (CVCSs) were deve
33
33
These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place. (((CVS)))(((Subversion)))(((Perforce)))
34
34
For many years, this has been the standard for version control.
35
35
36
-
.Centralized version control.
36
+
.Centralized version control
37
37
image::images/centralized.png[Centralized version control diagram]
38
38
39
39
This setup offers many advantages, especially over local VCSs.
@@ -54,7 +54,7 @@ In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don't just check ou
54
54
Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it.
55
55
Every clone is really a full backup of all the data.
56
56
57
-
.Distributed version control.
57
+
.Distributed version control
58
58
image::images/distributed.png[Distributed version control diagram]
59
59
60
60
Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project.
Copy file name to clipboardExpand all lines: book/01-introduction/sections/what-is-git.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
@@ -11,17 +11,17 @@ The major difference between Git and any other VCS (Subversion and friends inclu
11
11
Conceptually, most other systems store information as a list of file-based changes.
12
12
These other systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they store as a set of files and the changes made to each file over time (this is commonly described as _delta-based_ version control).
13
13
14
-
.Storing data as changes to a base version of each file.
15
-
image::images/deltas.png[Storing data as changes to a base version of each file.]
14
+
.Storing data as changes to a base version of each file
15
+
image::images/deltas.png[Storing data as changes to a base version of each file]
16
16
17
17
Git doesn't think of or store its data this way.
18
18
Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem.
19
19
With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
20
20
To be efficient, if files have not changed, Git doesn't store the file again, just a link to the previous identical file it has already stored.
21
21
Git thinks about its data more like a *stream of snapshots*.
22
22
23
-
.Storing data as snapshots of the project over time.
24
-
image::images/snapshots.png[Git stores data as snapshots of the project over time.]
23
+
.Storing data as snapshots of the project over time
24
+
image::images/snapshots.png[Git stores data as snapshots of the project over time]
25
25
26
26
This is an important distinction between Git and nearly all other VCSs.
27
27
It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation.
@@ -84,7 +84,7 @@ Git has three main states that your files can reside in: _modified_, _staged_, a
84
84
85
85
This leads us to the three main sections of a Git project: the working tree, the staging area, and the Git directory.
86
86
87
-
.Working tree, staging area, and Git directory.
87
+
.Working tree, staging area, and Git directory
88
88
image::images/areas.png["Working tree, staging area, and Git directory."]
89
89
90
90
The working tree is a single checkout of one version of the project.
You've decided that you're going to work on issue #53 in whatever issue-tracking system your company uses.
28
28
To create a new branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:
@@ -42,7 +42,7 @@ $ git checkout iss53
42
42
----
43
43
44
44
.Creating a new branch pointer
45
-
image::images/basic-branching-2.png[Creating a new branch pointer.]
45
+
image::images/basic-branching-2.png[Creating a new branch pointer]
46
46
47
47
You work on your website and do some commits.
48
48
Doing so moves the `iss53` branch forward, because you have it checked out (that is, your `HEAD` is pointing to it):
@@ -54,7 +54,7 @@ $ git commit -a -m 'Create new footer [issue 53]'
54
54
----
55
55
56
56
.The `iss53` branch has moved forward with your work
57
-
image::images/basic-branching-3.png[The `iss53` branch has moved forward with your work.]
57
+
image::images/basic-branching-3.png[The `iss53` branch has moved forward with your work]
58
58
59
59
Now you get the call that there is an issue with the website, and you need to fix it immediately.
60
60
With Git, you don't have to deploy your fix along with the `iss53` changes you've made, and you don't have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production.
image::images/basic-branching-4.png[Hotfix branch based on `master`.]
92
+
image::images/basic-branching-4.png[Hotfix branch based on `master`]
93
93
94
94
You can run your tests, make sure the hotfix is what you want, and finally merge the `hotfix` branch back into your `master` branch to deploy to production.
95
95
You do this with the `git merge` command:(((git commands, merge)))
@@ -111,7 +111,7 @@ To phrase that another way, when you try to merge one commit with a commit that
111
111
Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix.
112
112
113
113
.`master` is fast-forwarded to `hotfix`
114
-
image::images/basic-branching-5.png[`master` is fast-forwarded to `hotfix`.]
114
+
image::images/basic-branching-5.png[`master` is fast-forwarded to `hotfix`]
115
115
116
116
After your super-important fix is deployed, you're ready to switch back to the work you were doing before you were interrupted.
117
117
However, first you'll delete the `hotfix` branch, because you no longer need it -- the `master` branch points at the same place.
@@ -136,7 +136,7 @@ $ git commit -a -m 'Finish the new footer [issue 53]'
136
136
----
137
137
138
138
.Work continues on `iss53`
139
-
image::images/basic-branching-6.png[Work continues on `iss53`.]
139
+
image::images/basic-branching-6.png[Work continues on `iss53`]
140
140
141
141
It's worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch.
142
142
If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later.
@@ -165,13 +165,13 @@ Because the commit on the branch you're on isn't a direct ancestor of the branch
165
165
In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two.
166
166
167
167
.Three snapshots used in a typical merge
168
-
image::images/basic-merging-1.png[Three snapshots used in a typical merge.]
168
+
image::images/basic-merging-1.png[Three snapshots used in a typical merge]
169
169
170
170
Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it.
171
171
This is referred to as a merge commit, and is special in that it has more than one parent.
Copy file name to clipboardExpand all lines: book/03-git-branching/sections/nutshell.asc
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,12 +23,12 @@ Git then creates a commit object that has the metadata and a pointer to the root
23
23
Your Git repository now contains five objects: three _blobs_ (each representing the contents of one of the three files), one _tree_ that lists the contents of the directory and specifies which file names are stored as which blobs, and one _commit_ with the pointer to that root tree and all the commit metadata.
24
24
25
25
.A commit and its tree
26
-
image::images/commit-and-tree.png[A commit and its tree.]
26
+
image::images/commit-and-tree.png[A commit and its tree]
27
27
28
28
If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it.
29
29
30
30
.Commits and their parents
31
-
image::images/commits-and-parents.png[Commits and their parents.]
31
+
image::images/commits-and-parents.png[Commits and their parents]
32
32
33
33
A branch in Git is simply a lightweight movable pointer to one of these commits.
34
34
The default branch name in Git is `master`.
@@ -43,7 +43,7 @@ The only reason nearly every repository has one is that the `git init` command c
43
43
====
44
44
45
45
.A branch and its commit history
46
-
image::images/branch-and-history.png[A branch and its commit history.]
46
+
image::images/branch-and-history.png[A branch and its commit history]
47
47
48
48
[[_create_new_branch]]
49
49
==== Creating a New Branch
@@ -62,7 +62,7 @@ $ git branch testing
62
62
This creates a new pointer to the same commit you're currently on.
63
63
64
64
.Two branches pointing into the same series of commits
65
-
image::images/two-branches.png[Two branches pointing into the same series of commits.]
65
+
image::images/two-branches.png[Two branches pointing into the same series of commits]
66
66
67
67
How does Git know what branch you're currently on?
68
68
It keeps a special pointer called `HEAD`.
@@ -72,7 +72,7 @@ In this case, you're still on `master`.
72
72
The `git branch` command only _created_ a new branch -- it didn't switch to that branch.
73
73
74
74
.HEAD pointing to a branch
75
-
image::images/head-to-master.png[HEAD pointing to a branch.]
75
+
image::images/head-to-master.png[HEAD pointing to a branch]
76
76
77
77
You can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing.
78
78
This option is called `--decorate`.
@@ -102,7 +102,7 @@ $ git checkout testing
102
102
This moves `HEAD` to point to the `testing` branch.
103
103
104
104
.HEAD points to the current branch
105
-
image::images/head-to-testing.png[HEAD points to the current branch.]
105
+
image::images/head-to-testing.png[HEAD points to the current branch]
106
106
107
107
What is the significance of that?
108
108
Well, let's do another commit:
@@ -114,7 +114,7 @@ $ git commit -a -m 'made a change'
114
114
----
115
115
116
116
.The HEAD branch moves forward when a commit is made
117
-
image::images/advance-testing.png[The HEAD branch moves forward when a commit is made.]
117
+
image::images/advance-testing.png[The HEAD branch moves forward when a commit is made]
118
118
119
119
This is interesting, because now your `testing` branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches.
120
120
Let's switch back to the `master` branch:
@@ -137,7 +137,7 @@ To show all of the branches, add `--all` to your `git log` command.
137
137
====
138
138
139
139
.HEAD moves when you checkout
140
-
image::images/checkout-master.png[HEAD moves when you checkout.]
140
+
image::images/checkout-master.png[HEAD moves when you checkout]
141
141
142
142
That command did two things.
143
143
It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to.
@@ -167,7 +167,7 @@ And you did all that with simple `branch`, `checkout`, and `commit` commands.
You can also see this easily with the `git log` command.
173
173
If you run `git log --oneline --decorate --graph --all` it will print out the history of your commits, showing where your branch pointers are and how your history has diverged.
0 commit comments