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-en/01-introduction/sections/about-version-control.asc
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,21 +19,21 @@ 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 diagram
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.
26
-
https://www.gnu.org/software/rcs/[RCS] works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.
26
+
https://www.gnu.org/software/rcs/[RCS^] works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.
27
27
28
28
==== Centralized Version Control Systems
29
29
30
30
(((version control,centralized)))
31
31
The next major issue that people encounter is that they need to collaborate with developers on other systems.
32
32
To deal with this problem, Centralized Version Control Systems (CVCSs) were developed.
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)))
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 diagram
37
37
image::images/centralized.png[Centralized version control diagram]
38
38
39
39
This setup offers many advantages, especially over local VCSs.
@@ -50,11 +50,11 @@ Local VCSs suffer from this same problem -- whenever you have the entire history
50
50
51
51
(((version control,distributed)))
52
52
This is where Distributed Version Control Systems (DVCSs) step in.
53
-
In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don't just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history.
53
+
In a DVCS (such as Git, Mercurial or Darcs), clients don't just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history.
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 diagram
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-en/01-introduction/sections/first-time-setup.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
@@ -21,8 +21,7 @@ Each level overrides values in the previous level, so values in `.git/config` tr
21
21
22
22
On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Users\$USER` for most people).
23
23
It also still looks for `[path]/etc/gitconfig`, although it's relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer.
24
-
If you are using version 2.x or later of Git for Windows, there is also a system-level config file at
25
-
`C:\Documents and Settings\All Users\Application Data\Git\config` on Windows XP, and in `C:\ProgramData\Git\config` on Windows Vista and newer.
24
+
If you are using version 2.x or later of Git for Windows, there is also a system-level config file at `C:\Documents and Settings\All Users\Application Data\Git\config` on Windows XP, and in `C:\ProgramData\Git\config` on Windows Vista and newer.
26
25
This config file can only be changed by `git config -f <file>` as an admin.
27
26
28
27
You can view all of your settings and where they are coming from using:
Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system.
45
+
Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for your user on that system.
47
46
If you want to override this with a different name or email address for specific projects, you can run the command without the `--global` option when you're in that project.
48
47
49
48
Many of the GUI tools will help you do this when you first run them.
@@ -84,6 +83,7 @@ You may find, if you don't setup your editor like this, you get into a really co
84
83
An example on a Windows system may include a prematurely terminated Git operation during a Git initiated edit.
85
84
====
86
85
86
+
[[_new_default_branch]]
87
87
==== Your default branch name
88
88
89
89
By default Git will create a branch called _master_ when you create a new repository with `git init`.
Copy file name to clipboardExpand all lines: book-en/01-introduction/sections/help.asc
+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
@@ -18,7 +18,7 @@ $ git help config
18
18
----
19
19
20
20
These commands are nice because you can access them anywhere, even offline.
21
-
If the manpages and this book aren't enough and you need in-person help, you can try the `#git`, `#github`, or `#gitlab` channels on the Libera Chat IRC server, which can be found at https://libera.chat/[].
21
+
If the manpages and this book aren't enough and you need in-person help, you can try the `#git`, `#github`, or `#gitlab` channels on the Libera Chat IRC server, which can be found at https://libera.chat/[^].
22
22
These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.(((IRC)))
23
23
24
24
In addition, if you don't need the full-blown manpage help, but just need a quick refresher on the available options for a Git command, you can ask for the more concise "`help`" output with the `-h` option, as in:
Copy file name to clipboardExpand all lines: book-en/01-introduction/sections/history.asc
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,11 +10,11 @@ In 2005, the relationship between the community that developed the Linux kernel
10
10
This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper.(((Linus Torvalds)))
11
11
Some of the goals of the new system were as follows:
12
12
13
-
* Speed
14
-
* Simple design
15
-
* Strong support for non-linear development (thousands of parallel branches)
16
-
* Fully distributed
17
-
* Able to handle large projects like the Linux kernel efficiently (speed and data size)
13
+
* Speed
14
+
* Simple design
15
+
* Strong support for non-linear development (thousands of parallel branches)
16
+
* Fully distributed
17
+
* Able to handle large projects like the Linux kernel efficiently (speed and data size)
18
18
19
19
Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities.
20
-
It's amazingly fast, it's very efficient with large projects, and it has an incredible branching system for non-linear development (See <<ch03-git-branching#ch03-git-branching>>).
20
+
It's amazingly fast, it's very efficient with large projects, and it has an incredible branching system for non-linear development (see <<ch03-git-branching#ch03-git-branching>>).
Copy file name to clipboardExpand all lines: book-en/01-introduction/sections/installing.asc
+13-13Lines changed: 13 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,9 +6,9 @@ You can either install it as a package or via another installer, or download the
6
6
7
7
[NOTE]
8
8
====
9
-
This book was written using Git version *2.8.0*.
10
-
Though most of the commands we use should work even in ancient versions of Git, some of them might not or might act slightly differently if you're using an older version.
11
-
Since Git is quite excellent at preserving backwards compatibility, any version after 2.8 should work just fine.
9
+
This book was written using Git version 2.
10
+
Since Git is quite excellent at preserving backwards compatibility, any recent version should work just fine.
11
+
Though most of the commands we use should work even in ancient versions of Git, some of them might not or might act slightly differently.
12
12
====
13
13
14
14
==== Installing on Linux
@@ -29,12 +29,12 @@ If you're on a Debian-based distribution, such as Ubuntu, try `apt`:
29
29
$ sudo apt install git-all
30
30
----
31
31
32
-
For more options, there are instructions for installing on several different Unix distributions on the Git website, at https://git-scm.com/download/linux[].
32
+
For more options, there are instructions for installing on several different Unix distributions on the Git website, at https://git-scm.com/download/linux[^].
33
33
34
34
==== Installing on macOS
35
35
36
36
(((macOS, installing)))
37
-
There are several ways to install Git on a Mac.
37
+
There are several ways to install Git on macOS.
38
38
The easiest is probably to install the Xcode Command Line Tools.(((Xcode)))
39
39
On Mavericks (10.9) or above you can do this simply by trying to run `git` from the Terminal the very first time.
40
40
@@ -46,19 +46,19 @@ $ git --version
46
46
If you don't have it installed already, it will prompt you to install it.
47
47
48
48
If you want a more up to date version, you can also install it via a binary installer.
49
-
A macOS Git installer is maintained and available for download at the Git website, at https://git-scm.com/download/mac[].
49
+
A macOS Git installer is maintained and available for download at the Git website, at https://git-scm.com/download/mac[^].
Users of RHEL and RHEL-derivatives like CentOS and Scientific Linux will have to https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F[enable the EPEL repository] to download the `docbook2X` package.
90
+
Users of RHEL and RHEL-derivatives like CentOS and Scientific Linux will have to https://docs.fedoraproject.org/en-US/epel/#how_can_i_use_these_extra_packages[enable the EPEL repository^] to download the `docbook2X` package.
91
91
====
92
92
93
93
If you're using a Debian-based distribution (Debian/Ubuntu/Ubuntu-derivatives), you also need the `install-info` package:
When you have all the necessary dependencies, you can go ahead and grab the latest tagged release tarball from several places.
117
-
You can get it via the kernel.org site, at https://www.kernel.org/pub/software/scm/git[], or the mirror on the GitHub website, at https://github.com/git/git/releases[].
117
+
You can get it via the kernel.org site, at https://www.kernel.org/pub/software/scm/git[^], or the mirror on the GitHub website, at https://github.com/git/git/tags[^].
118
118
It's generally a little clearer what the latest version is on the GitHub page, but the kernel.org page also has release signatures if you want to verify your download.
119
119
120
120
Then, compile and install:
@@ -133,5 +133,5 @@ After this is done, you can also get Git via Git itself for updates:
Copy file name to clipboardExpand all lines: book-en/01-introduction/sections/what-is-git.asc
+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
@@ -10,7 +10,7 @@ Even though Git's user interface is fairly similar to these other VCSs, Git stor
10
10
11
11
The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data.
12
12
Conceptually, most other systems store information as a list of file-based changes.
13
-
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
+
These other systems (CVS, Subversion, Perforce, 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).
14
14
15
15
.Storing data as changes to a base version of each file
16
16
image::images/deltas.png[Storing data as changes to a base version of each file]
@@ -86,7 +86,7 @@ Git has three main states that your files can reside in: _modified_, _staged_, a
86
86
This leads us to the three main sections of a Git project: the working tree, the staging area, and the Git directory.
87
87
88
88
.Working tree, staging area, and Git directory
89
-
image::images/areas.png["Working tree, staging area, and Git directory."]
89
+
image::images/areas.png["Working tree, staging area, and Git directory"]
90
90
91
91
The working tree is a single checkout of one version of the project.
92
92
These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
Copy file name to clipboardExpand all lines: book-en/02-git-basics/sections/recording-changes.asc
+16-7Lines changed: 16 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,6 +36,15 @@ Finally, the command tells you which branch you're on and informs you that it ha
36
36
For now, that branch is always `master`, which is the default; you won't worry about it here.
37
37
<<ch03-git-branching#ch03-git-branching>> will go over branches and references in detail.
38
38
39
+
[NOTE]
40
+
====
41
+
GitHub changed the default branch name from `master` to `main` in mid-2020, and other Git hosts followed suit.
42
+
So you may find that the default branch name in some newly created repositories is `main` and not `master`.
43
+
In addition, the default branch name can be changed (as you have seen in <<ch01-getting-started#_new_default_branch>>), so you may see a different name for the default branch.
44
+
45
+
However, Git itself still uses `master` as the default, so we will use it throughout the book.
46
+
====
47
+
39
48
Let's say you add a new file to your project, a simple `README` file.
40
49
If the file didn't exist before, and you run `git status`, you see your untracked file like so:
41
50
@@ -219,11 +228,11 @@ Setting up a `.gitignore` file for your new repository before you get going is g
219
228
220
229
The rules for the patterns you can put in the `.gitignore` file are as follows:
221
230
222
-
* Blank lines or lines starting with `#` are ignored.
223
-
* Standard glob patterns work, and will be applied recursively throughout the entire working tree.
224
-
* You can start patterns with a forward slash (`/`) to avoid recursivity.
225
-
* You can end patterns with a forward slash (`/`) to specify a directory.
226
-
* You can negate a pattern by starting it with an exclamation point (`!`).
231
+
* Blank lines or lines starting with `#` are ignored.
232
+
* Standard glob patterns work, and will be applied recursively throughout the entire working tree.
233
+
* You can start patterns with a forward slash (`/`) to avoid recursivity.
234
+
* You can end patterns with a forward slash (`/`) to specify a directory.
235
+
* You can negate a pattern by starting it with an exclamation point (`!`).
227
236
228
237
Glob patterns are like simplified regular expressions that shells use.
229
238
An asterisk (`\*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen (`[0-9]`) matches any character between them (in this case 0 through 9).
@@ -254,7 +263,7 @@ doc/**/*.pdf
254
263
255
264
[TIP]
256
265
====
257
-
GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[] if you want a starting point for your project.
266
+
GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[^] if you want a starting point for your project.
258
267
====
259
268
260
269
[NOTE]
@@ -617,4 +626,4 @@ $ git add README
617
626
618
627
Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command.
619
628
The only real difference is that `git mv` is one command instead of three -- it's a convenience function.
620
-
More importantly, you can use any tool you like to rename a file, and address the add/rm later, before you commit.
629
+
More importantly, you can use any tool you like to rename a file, and address the `add`/`rm` later, before you commit.
0 commit comments