diff --git a/rys-git-tutorial.md b/Home.md
similarity index 89%
rename from rys-git-tutorial.md
rename to Home.md
index 6c7ade1..473c202 100644
--- a/rys-git-tutorial.md
+++ b/Home.md
@@ -1,20 +1,23 @@
-
+
[]{#navigation-document.xhtml}
:::: {#navigation-document.xhtml_page}
::: {#navigation-document.xhtml_content}
+
```{=html}
```
+
:::
::::
@@ -22,6 +25,7 @@
:::: {#introduction.xhtml_page}
::: {#introduction.xhtml_content}
+
# Introduction {#introduction.xhtml_introduction}
Git is a version control system (VCS) created for a single task:
@@ -44,7 +48,7 @@ the entire project and give it a new name. Just think about how many
times you've saved a "backup" called `my-term-paper-2.doc`. This is the
simplest form of version control.
-
+
But, it's easy to see how copying files from folder to folder could
prove disastrous for software developers. What happens if you mis-label
@@ -62,9 +66,9 @@ way, you would only have a single "checked out" copy of the project at
any given time, eliminating the possibility of mixing up or losing
revisions.
-
+
-At this point, versioning only took place on the developer's *local*
+At this point, versioning only took place on the developer's _local_
computer---there was no way to efficiently share code amongst several
programmers.
@@ -77,7 +81,7 @@ them back into the project over a network. This setup let several
programmers collaborate on a project by giving them a single point of
entry.
-
+
While a big improvement on local VCS, centralized systems presented a
new set of problems: how do multiple users work on the same files at the
@@ -98,12 +102,12 @@ team.
The next generation of revision control programs shifted away from the
idea of a single centralized repository, opting instead to give every
-developer their own *local* copy of the entire project. The resulting
-*distributed* network of repositories let each developer work in
+developer their own _local_ copy of the entire project. The resulting
+_distributed_ network of repositories let each developer work in
isolation, much like a local VCS---but now the conflict resolution
problem of CVCS had a much more elegant solution.
-
+
Since there was no longer a central repository, everyone could develop
at their own pace, store the updates locally, and put off merging
@@ -129,10 +133,10 @@ of a new open-source DVCS as a replacement. This was the birth of Git.
As a source code manager for the entire Linux kernel, Git had several
unique constraints, including:
-- Reliability
-- Efficient management of large projects
-- Support for distributed development
-- Support for non-linear development
+- Reliability
+- Efficient management of large projects
+- Support for distributed development
+- Support for non-linear development
While other DVCSs did exist at the time (e.g., GNU's Arch or David
Roundy's Darcs), none of them could satisfy this combination of
@@ -155,8 +159,8 @@ real-world scenarios. But first, you'll need a working Git installation
to experiment with. Downloads for all supported platforms are available
via the [official Git website](http://git-scm.com).
-For Windows users, this will install a special command shell called *Git
-Bash*. You should be using this shell instead of the native command
+For Windows users, this will install a special command shell called _Git
+Bash_. You should be using this shell instead of the native command
prompt to run Git commands. OS X and Linux users can access Git from a
normal shell. To test your installation, open a new command prompt and
run `git --version`. It should output something like
@@ -164,7 +168,7 @@ run `git --version`. It should output something like
## Get Ready! {#introduction.xhtml_get-ready}
-Remember that *Ry's Git Tutorial* is designed to *demonstrate* Git's
+Remember that _Ry's Git Tutorial_ is designed to _demonstrate_ Git's
feature set, not just give you a superficial overview of the most common
commands. To get the most out of this tutorial, it's important to
actually execute the commands you're reading about. So, make sure you're
@@ -176,6 +180,7 @@ sitting in front of a computer, and let's get to it!
:::: {#the-basics.xhtml_page}
::: {#the-basics.xhtml_content}
+
# The Basics {#the-basics.xhtml_the-basics}
Now that you have a basic understanding of version control systems in
@@ -207,7 +212,7 @@ project. Create a new folder called `my-git-repo` to store the project,
then add a file called `index.html` to it. Open `index.html` in your
favorite text editor and add the following HTML.
-``` cp
+```cp
@@ -216,8 +221,8 @@ favorite text editor and add the following HTML.
A Colorful Website
-
This is a website about color!
-
+
This is a website about color!
+
News
Nothing going on (yet)
@@ -237,7 +242,7 @@ Now, we're ready to create our first Git repository. Open a command
prompt (or Git Bash for Windows users) and navigate to the project
directory by executing:
-``` k
+```k
cd /path/to/my-git-repo
```
@@ -245,14 +250,14 @@ where `/path/to/my-git-repo` is a path to the folder created in the
previous step. For example, if you created `my-git-repo` on your
desktop, you would execute:
-``` k
+```k
cd ~/Desktop/my-git-repo
```
Next, run the following command to turn the directory into a Git
repository.
-``` k
+```k
git init
```
@@ -270,13 +275,13 @@ Before we try to start creating revisions, it would be helpful to view
the status of our new repository. Execute the following in your command
prompt.
-``` k
+```k
git status
```
This should output something like:
-``` c
+```c
# On branch master
#
# Initial commit
@@ -297,8 +302,8 @@ doesn't automatically track files because there are often project files
that we don't want to keep under revision control. These include
binaries created by a C program, compiled Python modules (`.pyc` files),
and any other content that would unnecessarily bloat the repository. To
-keep a project small and efficient, you should only track *source* files
-and omit anything that can be *generated* from those files. This latter
+keep a project small and efficient, you should only track _source_ files
+and omit anything that can be _generated_ from those files. This latter
content is part of the build process---not revision control.
## Stage a Snapshot {#the-basics.xhtml_stage-a-snapshot}
@@ -307,7 +312,7 @@ So, we need to explicitly tell Git to add `index.html` to the
repository. The aptly named `git add` command tells Git to start
tracking `index.html`:
-``` k
+```k
git add index.html
git status
```
@@ -315,7 +320,7 @@ git status
In place of the "Untracked files" list, you should see the following
status.
-``` c
+```c
# Changes to be committed:
# (use "git rm --cached ..." to unstage)
#
@@ -333,7 +338,7 @@ Git's term for creating a snapshot is called **staging** because we can
add or remove multiple files before actually committing it to the
project history. Staging gives us the opportunity to group related
changes into distinct snapshots---a practice that makes it possible to
-track the *meaningful* progression of a software project (instead of
+track the _meaningful_ progression of a software project (instead of
just arbitrary lines of code).
## Commit the Snapshot {#the-basics.xhtml_commit-the-snapshot}
@@ -342,7 +347,7 @@ We have staged a snapshot, but we still need to **commit** it to the
project history. The next command will open a text editor and prompt you
to enter a message for the commit.
-``` k
+```k
git commit
```
@@ -354,8 +359,8 @@ file is our `index.html`.
As we just demonstrated, saving a version of your project is a two step
process:
-1. **Staging.** Telling Git what files to include in the next commit.
-2. **Committing.** Recording the staged snapshot with a descriptive
+1. **Staging.** Telling Git what files to include in the next commit.
+2. **Committing.** Recording the staged snapshot with a descriptive
message.
Staging files with the `git add` command doesn't actually affect the
@@ -367,23 +372,23 @@ means you can do almost anything you want to your project without losing
those "safe" revisions. This is the principal goal of any version
control system.
-
+
## View the Repository History {#the-basics.xhtml_view-the-repository-history}
Note that `git status` now tells us that there is `nothing to commit`,
which means our current state matches what is stored in the repository.
-The `git status` command will *only* show us uncommitted changes---to
+The `git status` command will _only_ show us uncommitted changes---to
view our project history, we need a new command:
-``` k
+```k
git log
```
When you execute this command, Git will output information about our one
and only commit, which should look something like this:
-``` k
+```k
commit b650e4bd831aba05fa62d6f6d064e7ca02b5ee1b
Author: unknown
Date: Wed Jan 11 00:45:10 2012 -0600
@@ -410,7 +415,7 @@ in the previous step.
Before committing any more snapshots, we should probably tell Git who we
are. We can do this with the `git config` command:
-``` k
+```k
git config --global user.name "Your Name"
git config --global user.email your.email@example.com
```
@@ -426,7 +431,7 @@ which will come in handy later on.
Let's continue developing our website a bit. Start by creating a file
called `orange.html` with the following content.
-``` cp
+```cp
@@ -443,7 +448,7 @@ called `orange.html` with the following content.
Then, add a `blue.html` page:
-``` cp
+```cp
@@ -461,7 +466,7 @@ Then, add a `blue.html` page:
Next, we can stage the files the same way we created the first snapshot.
-``` k
+```k
git add orange.html blue.html
git status
```
@@ -469,7 +474,7 @@ git status
Notice that we can pass more than one file to `git add`. After adding
the files, your status output should look like the following:
-``` c
+```c
# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
@@ -480,17 +485,17 @@ the files, your status output should look like the following:
Try running `git log`. It only outputs the first commit, which tells us
that `blue.html` and `orange.html` have not yet been added to the
-repository's history. Remember, we can see *staged* changes with
+repository's history. Remember, we can see _staged_ changes with
`git status`, but not with `git log`. The latter is used only for
-*committed* changes.
+_committed_ changes.
-
+
## Commit the New Files {#the-basics.xhtml_commit-the-new-files}
Let's commit our staged snapshot:
-``` k
+```k
git commit
```
@@ -499,7 +504,7 @@ close the file. Now, `git log` should output two commits, the second of
which reflects our name/email configuration. This project history can be
visualized as:
-
+
Each circle represents a commit, the red circle designates the commit
we're currently viewing, and the arrow points to the preceding commit.
@@ -510,11 +515,11 @@ this tutorial.
## Modify the HTML Pages {#the-basics.xhtml_modify-the-html-pages}
-The `git add` command we've been using to stage *new* files can also be
-used to stage *modified* files. Add the following to the bottom of
+The `git add` command we've been using to stage _new_ files can also be
+used to stage _modified_ files. Add the following to the bottom of
`index.html`, right before the closing `` tag:
-``` nt
+```nt
Navigation
@@ -529,7 +534,7 @@ used to stage *modified* files. Add the following to the bottom of
Next, add a home page link to the bottom of `orange.html` and
`blue.html` (again, before the `` line):
-``` nt
+```nt
```
@@ -539,7 +544,7 @@ You can now navigate between pages when viewing them in a web browser.
Once again, we'll stage the modifications, then commit the snapshot.
-``` k
+```k
git status
git add index.html orange.html blue.html
git status
@@ -554,7 +559,7 @@ Our history can now be represented as the following. Note that the red
circle, which represents the current commit, automatically moves forward
every time we commit a new snapshot.
-
+
## Explore the Repository[']{.apo}s History {#the-basics.xhtml_explore-the-repository}
@@ -562,7 +567,7 @@ The `git log` command comes with a lot of formatting options, a few of
which will be introduced throughout this tutorial. For now, we'll just
use the convenient `--oneline` flag:
-``` k
+```k
git log --oneline
```
@@ -570,7 +575,7 @@ Condensing output to a single line is a great way to get a high-level
overview of a repository. Another useful configuration is to pass a
filename to `git log`:
-``` k
+```k
git log --oneline blue.html
```
@@ -584,7 +589,7 @@ In this module, we introduced the fundamental Git workflow: edit files,
stage a snapshot, and commit the snapshot. We also had some hands-on
experience with the components involved in this process:
-
+
The distinction between the working directory, the staged snapshot, and
committed snapshots is at the very core of Git version control. Nearly
@@ -599,25 +604,25 @@ simple versioning tool for your own projects.
## Quick Reference {#the-basics.xhtml_quick-reference}
`git init`
-: Create a Git repository in the current folder.
+: Create a Git repository in the current folder.
`git status`
-: View the status of each file in a repository.
+: View the status of each file in a repository.
`git add `
-: Stage a file for the next commit.
+: Stage a file for the next commit.
`git commit`
-: Commit the staged files with a descriptive message.
+: Commit the staged files with a descriptive message.
`git log`
-: View a repository's commit history.
+: View a repository's commit history.
`git config --global user.name ""`
-: Define the author name to be used in all repositories.
+: Define the author name to be used in all repositories.
`git config --global user.email `
-: Define the author email to be used in all repositories.
+: Define the author email to be used in all repositories.
:::
::::
@@ -625,6 +630,7 @@ simple versioning tool for your own projects.
:::::: {#undoing-changes.xhtml_page}
::::: {#undoing-changes.xhtml_content}
+
# Undoing Changes {#undoing-changes.xhtml_undoing-changes}
In the last module, we learned how to record versions of a project into
@@ -638,7 +644,7 @@ to restore them. Our next task is to learn how to view the previous
states of a project, revert back to them, and reset uncommitted changes.
::: {.icon-text .download-icon-text}
-{style="max-width: 45px"}
+{style="max-width: 45px"}
[Download the repository for this
module](http://rypress.com/tutorials/git/media/repo-zips/undoing-changes.zip)
@@ -657,14 +663,14 @@ As a quick review, let's display our repository's history. Navigate a
command prompt (or Git Bash) to the `my-git-repo` folder and run the
following.
-``` k
+```k
git log --oneline
```
The output for this should look similar to the following, but contain
different commit checksums.
-``` s
+```s
1c310d2 Add navigation links
54650a3 Create blue and orange pages
b650e4b Create index page
@@ -679,9 +685,9 @@ commit.
Using the new `git checkout` command, we can view the contents of a
previous snapshot. Make sure to change `54650a3` in the following
-command to the ID of your *second* commit.
+command to the ID of your _second_ commit.
-``` k
+```k
git checkout 54650a3
```
@@ -697,40 +703,40 @@ the project. After checking out the second commit, our repository
history looks like the following (the red circle represents the current
commit).
-
+
## View an Older Revision {#undoing-changes.xhtml_view-an-older-revision}
Let's go even farther back in our history. Be sure to change `b650e4b`
-to the ID of your *first* commit.
+to the ID of your _first_ commit.
-``` k
+```k
git checkout b650e4b
```
Now, the `blue.html` and `orange.html` files are gone, as is the rest of
the `git log` history.
-
+
In the last module, we said that Git was designed to never lose a
committed snapshot. So, where did our second and third snapshots go? A
simple `git status` will answer that question for us. It should return
the following message:
-``` c
+```c
# Not currently on any branch.
nothing to commit (working directory clean)
```
Compare this with the status output from the previous module:
-``` c
+```c
# On branch master
nothing to commit (working directory clean)
```
-All of our actions in *The Basics* took place on the `master` branch,
+All of our actions in _The Basics_ took place on the `master` branch,
which is where our second and third commits still reside. To retrieve
our complete history, we just have to check out this branch. This is a
very brief introduction to branches, but it's all we need to know to
@@ -742,7 +748,7 @@ detail.
We can use the same `git checkout` command to return to the `master`
branch.
-``` k
+```k
git checkout master
```
@@ -752,14 +758,14 @@ This makes Git update our working directory to reflect the state of the
as well. We're now back to the current state of the project, and our
history looks like:
-
+
## Tag a Release {#undoing-changes.xhtml_tag-a-release}
Let's call this a stable version of the example website. We can make it
official by **tagging** the most recent commit with a version number.
-``` k
+```k
git tag -a v1.0 -m "Stable version of the website"
```
@@ -780,7 +786,7 @@ We're now free to add experimental changes to the example site without
affecting any committed content. Create a new file called `crazy.html`
and add the following HTML.
-``` cp
+```cp
@@ -791,7 +797,7 @@ and add the following HTML.
@@ -801,7 +807,7 @@ and add the following HTML.
Stage and commit the new file as usual.
-``` k
+```k
git add crazy.html
git status
git commit -m "Add a crazzzy experiment"
@@ -824,7 +830,7 @@ Let's go back and take a look at our stable revision. Remember that the
`v1.0` tag now serves as a user-friendly shortcut to the third commit's
ID.
-``` k
+```k
git checkout v1.0
```
@@ -834,14 +840,14 @@ the `master` branch. If we didn't, all of our updates would be on some
non-existent branch. As we'll discover next module, you should never
make changes directly to a previous revision.
-``` k
+```k
git checkout master
git log --oneline
```
At this point, our history should look like the following:
-``` s
+```s
514fbe7 Add a crazzzy experiment
1c310d2 Add navigation links
54650a3 Create blue and orange pages
@@ -851,10 +857,10 @@ b650e4b Create index page
## Undo Committed Changes {#undoing-changes.xhtml_undo-committed-changes}
We're ready to restore our stable tag by removing the most recent
-commit. Make sure to change `514fbe7` to the ID of the *crazy
-experiment's commit* before running the next command.
+commit. Make sure to change `514fbe7` to the ID of the _crazy
+experiment's commit_ before running the next command.
-``` k
+```k
git revert 514fbe7
```
@@ -863,7 +869,7 @@ This will prompt you for a commit message with a default of
message and close the file. After verifying that `crazy.html` is gone,
take a look at your history with `git log --oneline`.
-``` s
+```s
506bb9b Revert "Add a crazzzy experiment"
514fbe7 Add a crazzzy experiment
1c310d2 Add navigation links
@@ -875,10 +881,10 @@ Notice that instead of deleting the "crazzzy experiment" commit, Git
figures out how to undo the changes it contains, then tacks on another
commit with the resulting content. So, our fifth commit and our third
commit represent the exact same snapshot, as shown below. Again, Git is
-designed to *never* lose history: the fourth snapshot is still
+designed to _never_ lose history: the fourth snapshot is still
accessible, just in case we want to continue developing it.
-
+
When using `git revert`, remember to specify the commit that you want to
undo---not the stable commit that you want to return to. It helps to
@@ -891,7 +897,7 @@ Let's try a smaller experiment this time. Create `dummy.html` and leave
it as a blank file. Then, add a link in the "Navigation" section of
`index.html` so that it resembles the following.
-``` nt
+```nt
Navigation
@@ -915,18 +921,18 @@ can't use the method discussed above.
Before we start undoing things, let's take a look at the status of our
repository.
-``` k
+```k
git status
```
We have a tracked file and an untracked file that need to be changed.
First, we'll take care of `index.html`:
-``` k
+```k
git reset --hard
```
-This changes all *tracked* files to match the most recent commit. Note
+This changes all _tracked_ files to match the most recent commit. Note
that the `--hard` flag is what actually updates the file. Running
`git reset` without any flags will simply unstage `index.html`, leaving
its contents as is. In either case, `git reset` only operates on the
@@ -937,17 +943,17 @@ Next, let's remove the `dummy.html` file. Of course, we could manually
delete it, but using Git to reset changes eliminates human errors when
working with several files in large teams. Run the following command.
-``` k
+```k
git clean -f
```
-This will remove all *untracked* files. With `dummy.html` gone,
+This will remove all _untracked_ files. With `dummy.html` gone,
`git status` should now tell us that we have a "clean" working
directory, meaning our project matches the most recent commit.
-***Be careful*** with `git reset` and `git clean`. Both operate on the
+**_Be careful_** with `git reset` and `git clean`. Both operate on the
working directory, not on the committed snapshots. Unlike `git revert`,
-they ***permanently*** undo changes, so make sure you really want to
+they **_permanently_** undo changes, so make sure you really want to
trash what you're working on before you use them.
## Conclusion {#undoing-changes.xhtml_conclusion}
@@ -960,7 +966,7 @@ undoes changes to the working directory and the staged snapshot, while
surprisingly, `git status` and `git log` directly parallel this
behavior.
-
+
I mentioned that instead of completely removing a commit, `git revert`
saves the commit in case you want to come back to it later. This is only
@@ -978,22 +984,22 @@ cover the basic Git branch commands.
## Quick Reference {#undoing-changes.xhtml_quick-reference}
`git checkout `
-: View a previous commit.
+: View a previous commit.
`git tag -a -m ""`
-: Create an annotated tag pointing to the most recent commit.
+: Create an annotated tag pointing to the most recent commit.
`git revert `
-: Undo the specified commit by applying a new commit.
+: Undo the specified commit by applying a new commit.
`git reset --hard`
-: Reset *tracked* files to match the most recent commit.
+: Reset _tracked_ files to match the most recent commit.
`git clean -f`
-: Remove *untracked* files.
+: Remove _untracked_ files.
-`git reset --hard` / ` git clean -f`
-: Permanently undo uncommitted changes.
+`git reset --hard` / `git clean -f`
+: Permanently undo uncommitted changes.
:::::
::::::
@@ -1001,18 +1007,19 @@ cover the basic Git branch commands.
:::::: {#branches-1.xhtml_page}
::::: {#branches-1.xhtml_content}
+
# Branches, Part I {#branches-1.xhtml_branches-part-i}
Branches are the final component of Git version control. This gives us
four core elements to work with throughout the rest of this tutorial:
-- The Working Directory
-- The Staged Snapshot
-- Committed Snapshots
-- Development Branches
+- The Working Directory
+- The Staged Snapshot
+- Committed Snapshots
+- Development Branches
In Git, a **branch** is an independent line of development. For example,
-if you wanted to experiment with a new idea *without* using Git, you
+if you wanted to experiment with a new idea _without_ using Git, you
might copy all of your project files into another directory and start
making your changes. If you liked the result, you could copy the
affected files back into the original project. Otherwise, you would
@@ -1028,7 +1035,7 @@ collaborative development, which will be explored in the latter half of
the tutorial.
::: {.icon-text .download-icon-text}
-{style="max-width: 45px"}
+{style="max-width: 45px"}
[Download the repository for this
module](http://rypress.com/tutorials/git/media/repo-zips/branches-1.zip)
@@ -1046,7 +1053,7 @@ from the above link, uncompress it, and you're good to go.
Let's start our exploration by listing the existing branches for our
project.
-``` k
+```k
git branch
```
@@ -1055,7 +1062,7 @@ branch is Git's default branch, and the asterisk next to it tells us
that it's currently checked out. This means that the most recent
snapshot in the `master` branch resides in the working directory:
-
+
Notice that since there's only one working directory for each project,
only one branch can be checked out at a time.
@@ -1066,13 +1073,13 @@ The previous module left out some details about how checking out
previous commits actually works. We're now ready to tackle this topic in
depth. First, we need the checksums of our committed snapshots.
-``` k
+```k
git log --oneline
```
This outputs the following history.
-``` s
+```s
506bb9b Revert "Add a crazzzy experiment"
514fbe7 Add a crazzzy experiment
1c310d2 Add navigation links
@@ -1083,7 +1090,7 @@ b650e4b Create index page
Check out the crazy experiment from the last module, remembering to
change `514fbe7` to the ID of your fourth commit.
-``` k
+```k
git checkout 514fbe7
```
@@ -1095,7 +1102,7 @@ diagrams actually represents Git's `HEAD`. The following figure shows
the state of our repository before and after we checked out an old
commit.
-
+
As shown in the "before" diagram, the `HEAD` normally resides on the tip
of a development branch. But when we checked out the previous commit,
@@ -1110,24 +1117,24 @@ We can't add new commits when we're not on a branch, so let's create one
now. This will take our current working directory and fork it into a new
branch.
-``` k
+```k
git branch crazy
```
Note that `git branch` is a versatile command that can be used to either
-list branches or create them. However, the above command only *creates*
+list branches or create them. However, the above command only _creates_
the `crazy` branch---it doesn't check it out.
-``` k
+```k
git checkout crazy
```
We're now free to experiment in the working directory without disturbing
-anything in the `master` branch. The `crazy` branch is a *completely
-isolated* development environment that can be visualized as the
+anything in the `master` branch. The `crazy` branch is a _completely
+isolated_ development environment that can be visualized as the
following.
-
+
Right now, the `crazy` branch, `HEAD`, and working directory are the
exact same as the fourth commit. But as soon as we add another snapshot,
@@ -1138,7 +1145,7 @@ we'll see a fork in our project history.
We'll continue developing our crazy experiment by changing `crazy.html`
to the following.
-``` cp
+```cp
@@ -1158,7 +1165,7 @@ to the following.
@@ -1169,7 +1176,7 @@ to the following.
Hopefully, you're relatively familiar with staging and committing
snapshots by now:
-``` k
+```k
git add crazy.html
git status
git commit -m "Add a rainbow to crazy.html"
@@ -1178,7 +1185,7 @@ git commit -m "Add a rainbow to crazy.html"
After committing on the `crazy` branch, we can see two independent lines
of development in our project:
-
+
Also notice that the `HEAD` (designated by the red circle) automatically
moved forward to the new commit, which is intuitively what we would
@@ -1187,7 +1194,7 @@ expect when developing a project.
The above diagram represents the complete state of our repository, but
`git log` only displays the history of the current branch:
-``` s
+```s
677e0e0 Add a rainbow to crazy.html
514fbe7 Add a crazzzy experiment
*1c310d2 Add navigation links
@@ -1195,14 +1202,14 @@ The above diagram represents the complete state of our repository, but
*b650e4b Create index page
```
-Note that the history *before* the fork is considered part of the new
+Note that the history _before_ the fork is considered part of the new
branch (marked with asterisks above). That is to say, the `crazy`
history spans all the way back to the first commit:
-
+
The project as a whole now has a complex history; however, each
-individual branch still has a *linear* history (snapshots occur one
+individual branch still has a _linear_ history (snapshots occur one
after another). This means that we can interact with branches in the
exact same way as we learned in the first two modules.
@@ -1212,7 +1219,7 @@ Let's add one more snapshot to the `crazy` branch. Rename `crazy.html`
to `rainbow.html`, then use the following Git commands to update the
repository.
-``` k
+```k
git status
git rm crazy.html
git status
@@ -1228,7 +1235,7 @@ file.
Our snapshot is staged and ready to be committed:
-``` k
+```k
git commit -m "Rename crazy.html to rainbow.html"
git log --oneline
```
@@ -1237,13 +1244,13 @@ After this addition, our complete repository history looks like the
following. Remember that the `crazy` branch doesn't include any commits
in `master` after the fork.
-
+
## Return to the Master Branch {#branches-1.xhtml_return-to-the-master-branch}
Let's switch back to the `master` branch:
-``` k
+```k
git checkout master
git branch
git log --oneline
@@ -1251,12 +1258,12 @@ git log --oneline
After the checkout, `crazy.html` doesn't exist in the working directory,
and the commits from the last few steps don't appear in the history.
-These two branches became *completely independent* development
+These two branches became _completely independent_ development
environments after they forked. You can think of them as separate
project folders that you switch between with `git checkout`. They do,
however, share their first four commits.
-
+
## Create a CSS Branch {#branches-1.xhtml_create-a-css-branch}
@@ -1268,7 +1275,7 @@ the Git commands used to manage them.
Let's create and check out a new branch called `css`.
-``` k
+```k
git branch css
git checkout css
```
@@ -1276,14 +1283,14 @@ git checkout css
The new branch points to the currently checked out snapshot, which
happens to coincide with the `master` branch:
-
+
## Add a CSS Stylesheet {#branches-1.xhtml_add-a-css-stylesheet}
Next, create a file called `style.css` with the following content. This
CSS is used to apply formatting to the HTML in our other files.
-``` nt
+```nt
body {
padding: 20px;
font-family: Verdana, Arial, Helvetica, sans-serif;
@@ -1302,7 +1309,7 @@ ul {
Commit the stylesheet in the usual fashion.
-``` k
+```k
git add style.css
git status
git commit -m "Add CSS stylesheet"
@@ -1317,13 +1324,13 @@ We still need to tell the HTML pages to use the formatting in
should be able to see the CSS formatting by opening `index.html` in a
web browser.
-``` nt
+```nt
```
Commit the changes.
-``` k
+```k
git add index.html blue.html orange.html
git status
git commit -m "Link HTML pages to stylesheet"
@@ -1332,7 +1339,7 @@ git log --oneline
This results in a repository history that looks like:
-
+
## Return to the Master Branch (Again) {#branches-1.xhtml_return-to-the-master-branch-again}
@@ -1341,7 +1348,7 @@ threatening the stability of the `master` branch. But, now we need to
merge these changes into the main project. Before we attempt the merge,
we need to return to the `master` branch.
-``` k
+```k
git checkout master
```
@@ -1349,11 +1356,11 @@ Verify that `style.css` doesn't exist and that HTML pages aren't linked
to it. Our repository history remains unchanged, but the working
directory now matches the snapshot pointed to by the `master` branch.
-
+
Take a look at the `git log --oneline` output as well.
-``` s
+```s
af23ff4 Revert "Add a crazzzy experiment"
a50819f Add a crazzzy experiment
4cd95d9 Add navigation links
@@ -1369,7 +1376,7 @@ As expected, there is no mention of the CSS additions in the history of
Use the `git merge` command to take the snapshots from the `css` branch
and add them to the `master` branch.
-``` k
+```k
git merge css
```
@@ -1377,13 +1384,13 @@ Notice that this command always merges into the current branch: `css`
remains unchanged. Check the history to make sure that the `css` history
has been added to `master`.
-``` k
+```k
git log --oneline
```
The following diagram visualizes the merge.
-
+
Instead of re-creating the commits in `css` and adding them to the
history of `master`, Git reuses the existing snapshots and simply moves
@@ -1399,7 +1406,7 @@ we're free to get rid of it.
We can safely delete a branch by passing the `-d` flag to `git branch`.
-``` k
+```k
git branch -d css
git branch
```
@@ -1409,7 +1416,7 @@ the same, though the `css` branch has been removed. I've also put the
`master` branch's commits in a straight line in the following
visualization, making it easier to track during the upcoming modules.
-
+
Deleting branches is a relatively "safe" operation in the sense that Git
will warn you if you're deleting an unmerged branch. This is just
@@ -1439,24 +1446,24 @@ complicated merges than the fast-forward merge introduced above.
## Quick Reference {#branches-1.xhtml_quick-reference}
`git branch`
-: List all branches.
+: List all branches.
`git branch `
-: Create a new branch using the current working directory as its base.
+: Create a new branch using the current working directory as its base.
`git checkout `
-: Make the working directory and the `HEAD` match the specified
- branch.
+: Make the working directory and the `HEAD` match the specified
+branch.
`git merge `
-: Merge a branch into the checked-out branch.
+: Merge a branch into the checked-out branch.
`git branch -d `
-: Delete a branch.
+: Delete a branch.
`git rm `
-: Remove a file from the working directory (if applicable) and stop
- tracking the file.
+: Remove a file from the working directory (if applicable) and stop
+tracking the file.
:::::
::::::
@@ -1464,6 +1471,7 @@ complicated merges than the fast-forward merge introduced above.
:::::: {#branches-2.xhtml_page}
::::: {#branches-2.xhtml_content}
+
# Branches, Part II {#branches-2.xhtml_branches-part-ii}
Now that we've covered the mechanics behind Git branches, we can discuss
@@ -1487,7 +1495,7 @@ situation may also give rise to a merge conflict, which must be manually
resolved before anything can be committed to the repository.
::: {.icon-text .download-icon-text}
-{style="max-width: 45px"}
+{style="max-width: 45px"}
[Download the repository for this
module](http://rypress.com/tutorials/git/media/repo-zips/branches-2.zip)
@@ -1504,7 +1512,7 @@ from the above link, uncompress it, and you're good to go.
Let's start by checking out the `crazy` branch.
-``` k
+```k
git branch
git checkout crazy
git log --oneline
@@ -1512,15 +1520,15 @@ git log --oneline
The `crazy` branch is a longer-running type of topic branch called a
**feature branch**. This is fitting, as it was created with the
-intention of developing a specific *feature*. It's also a term that
+intention of developing a specific _feature_. It's also a term that
makes Git's contribution to the development workflow readily apparent:
branches enable you to focus on developing one clearly defined feature
at a time.
This brings us to my rule-of-thumb for using Git branches:
-- Create a new branch for each major addition to your project.
-- *Don't* create a branch if you can't give it a specific name.
+- Create a new branch for each major addition to your project.
+- _Don't_ create a branch if you can't give it a specific name.
Following these simple guidelines will have a dramatic impact on your
programming efficiency.
@@ -1530,11 +1538,11 @@ programming efficiency.
Note that the CSS formatting we merged into `master` is nowhere to be
found. This presents a bit of a problem if we want our experiment to
reflect these updates. Conveniently, Git lets us merge changes into
-*any* branch (not just the `master` branch). So, we can pull the updates
+_any_ branch (not just the `master` branch). So, we can pull the updates
in with the familiar `git merge` command. Remember that merging only
affects the checked-out branch.
-``` k
+```k
git merge master
git log --oneline
```
@@ -1547,7 +1555,7 @@ first merge didn't add any new commits; it just "fast-forwarded" the tip
of the `master` branch. This was not the case for our new merge, which
is shown below.
-
+
Take a moment to examine why the current merge couldn't be a
fast-forward one. How could Git have walked the `crazy` pointer over to
@@ -1557,14 +1565,14 @@ new way to combine branches: the **3-way merge**.
A 3-way merge occurs when you try to merge two branches whose history
has diverged. It creates an extra **merge commit** to function as a link
-between the two branches. As a result, it has *two* parent commits. The
+between the two branches. As a result, it has _two_ parent commits. The
above figure visualizes this with two arrows originating from the tip of
`crazy`. It's like saying "this commit comes from both the `crazy`
-branch *and* from `master`." After the merge, the `crazy` branch has
+branch _and_ from `master`." After the merge, the `crazy` branch has
access to both its history and the `master` history.
The name comes from the internal method used to create the merge commit.
-Git looks at *three* commits (numbered in the above figure) to generate
+Git looks at _three_ commits (numbered in the above figure) to generate
the final state of the merge.
This kind of branch interaction is a big part of what makes Git such a
@@ -1579,14 +1587,14 @@ continue developing our crazy experiment. Link the CSS stylesheet to
`rainbow.html` by adding the following HTML on the line after the
`` element.
-``` nt
+```nt
<link rel="stylesheet" href="style.css" />
```
Stage and commit the update, then check that it's reflected in the
history.
-``` k
+```k
git status
git commit -a -m "Add CSS stylesheet to rainbow.html"
git log --oneline
@@ -1594,7 +1602,7 @@ git log --oneline
Notice that we skipped the staging step this time around. Instead of
using `git add`, we passed the `-a` flag to `git commit`. This
-convenient parameter tells Git to automatically include *all* tracked
+convenient parameter tells Git to automatically include _all_ tracked
files in the staged snapshot. Combined with the `-m` flag, we can stage
and commit snapshots with a single command. However, be careful not to
include unintended files when using the `-a` flag.
@@ -1604,7 +1612,7 @@ include unintended files when using the `-a` flag.
We still need to add a navigation link to the home page. Change the
"Navigation" section of `index.html` to the following.
-``` nt
+```nt
<h2>Navigation</h2>
<ul>
<li style="color: #F90">
@@ -1621,7 +1629,7 @@ We still need to add a navigation link to the home page. Change the
As usual, stage and commit the snapshot.
-``` k
+```k
git commit -a -m "Link index.html to rainbow.html"
git log --oneline
```
@@ -1632,7 +1640,7 @@ Next, we're going to brainstorm an alternative to the current
`rainbow.html` page. This is a perfect time to create another topic
branch:
-``` k
+```k
git branch crazy-alt
git checkout crazy-alt
```
@@ -1644,13 +1652,13 @@ we begin with the same files as `crazy` (if we called `git branch` from
`master`, we would have had to re-create `rainbow.html`). After creating
the new branch, our repository's history looks like:
-
+
## Change the Rainbow {#branches-2.xhtml_change-the-rainbow}
Change the colorful list in `rainbow.html` from:
-``` nt
+```nt
<ul>
<li style="color: red">Red</li>
<li style="color: orange">Orange</li>
@@ -1664,7 +1672,7 @@ Change the colorful list in `rainbow.html` from:
to the following:
-``` nt
+```nt
<div style="background-color: red"></div>
<div style="background-color: orange"></div>
<div style="background-color: yellow"></div>
@@ -1677,7 +1685,7 @@ to the following:
Then, add some CSS formatting to `<head>` on the line after the `<meta>`
element:
-``` nt
+```nt
<style>
div {
width: 300px;
@@ -1690,18 +1698,18 @@ If you open `rainbow.html` in a browser, you should now see colorful
blocks in place of the colorful text. Don't forget to commit the
changes:
-``` k
+```k
git commit -a -m "Make a REAL rainbow"
```
The resulting project history is show below, with the first four commits
omitted for the sake of presentation.
-
+
## Emergency Update! {#branches-2.xhtml_emergency-update}
-*Our boss called in with some breaking news!* He needs us to update the
+_Our boss called in with some breaking news!_ He needs us to update the
site immediately, but what do we do with our `rainbow.html`
developments? Well, the beauty of Git branches is that we can just leave
them where they are and add the breaking news to `master`.
@@ -1714,7 +1722,7 @@ bug in a public software project. This distinction is useful for
demonstrating when it's appropriate to create a new branch, but it is
purely conceptual---a branch is a branch according to Git.
-``` k
+```k
git checkout master
git branch news-hotfix
git checkout news-hotfix
@@ -1722,7 +1730,7 @@ git checkout news-hotfix
Change the "News" list in `index.html` to match the following.
-``` nt
+```nt
<h2 style="color: #C00">News</h2>
<ul>
<li><a href="news-1.html">Blue Is The New Hue</a></li>
@@ -1732,7 +1740,7 @@ Change the "News" list in `index.html` to match the following.
And, create a new HTML page called `news-1.html` with the following
content.
-``` cp
+```cp
<!DOCTYPE html>
<html lang="en">
<head>
@@ -1745,17 +1753,17 @@ content.
<p>European designers have just announced that
<span style="color: #079">Blue</span> will be this year's
hot color.</p>
-
+
<p><a href="index.html">Return to home page</a></p>
</body>
</html>
```
We can't use `git commit -a` to automatically stage `news-1.html`
-because it's an *untracked* file (as shown in `git status`). So, let's
+because it's an _untracked_ file (as shown in `git status`). So, let's
use an explicit `git add`:
-``` k
+```k
git add index.html news-1.html
git status
git commit -m "Add 1st news item"
@@ -1773,7 +1781,7 @@ without touching your stable project.
Remember that to merge into the `master` branch, we first need to check
it out.
-``` k
+```k
git checkout master
git merge news-hotfix
```
@@ -1781,7 +1789,7 @@ git merge news-hotfix
Since `master` now contains the news update, we can delete the hotfix
branch:
-``` k
+```k
git branch -d news-hotfix
git branch
```
@@ -1790,7 +1798,7 @@ The following diagram reflects our repository's history before and after
the merge. Can you figure out why was this a fast-forward merge instead
of a 3-way merge?
-
+
Also notice that we have another fork in our history (the commit before
`master` branches in two directions), which means we should expect to
@@ -1800,7 +1808,7 @@ see another merge commit in the near future.
Ok, let's finish up our crazy experiment with one more commit.
-``` k
+```k
git checkout crazy
```
@@ -1810,7 +1818,7 @@ Note that the news article is nowhere to be found, as should be expected
We'll finish up our crazy experiment by adding a news item for it on the
home page. Change the news list in `index.html` to the following:
-``` nt
+```nt
<h2 style="color: #C00">News</h2>
<ul>
<li><a href="rainbow.html">Our New Rainbow</a></li>
@@ -1818,7 +1826,7 @@ home page. Change the news list in `index.html` to the following:
```
Astute readers have probably observed that this directly conflicts with
-what we changed in the `news-hotfix` branch. We should *not* manually
+what we changed in the `news-hotfix` branch. We should _not_ manually
add in the other news item because it has no relationship with the
current branch. In addition, there would be no way to make sure the link
works because `news-1.html` doesn't exist in this branch. This may seem
@@ -1828,14 +1836,14 @@ trivial, but imagine the errors that could be introduced had
We'll simply stage and commit the snapshot as if there were no
conflicts:
-``` k
+```k
git commit -a -m "Add news item for rainbow"
git log --oneline
```
Look at all those experimental commits (marked with asterisks below)!
-``` s
+```s
*42fa173 Add news item for rainbow
*7147cc5 Link index.html to rainbow.html
*6aa4b3b Add CSS stylesheet to rainbow.html
@@ -1855,7 +1863,7 @@ b650e4b Create index page
We're finally ready to merge our `crazy` branch back into `master`.
-``` k
+```k
git checkout master
git merge crazy
```
@@ -1871,7 +1879,7 @@ merge branches that have edited the same content. Git doesn't know how
to combine the two changes, so it stops to ask us what to do. We can see
exactly what went wrong with the familiar `git status` command:
-``` c
+```c
# On branch master
# Changes to be committed:
#
@@ -1910,7 +1918,7 @@ We can change the affected lines to whatever we want in order to resolve
the conflict. Edit the news section of `index.html` to keep changes from
both versions:
-``` nt
+```nt
<h2 style="color: #C00">News</h2>
<ul>
<li><a href="news-1.html">Blue Is The New Hue</a></li>
@@ -1922,7 +1930,7 @@ The `<<<<<<<`, `=======`, and `>>>>>>>` markers are only used to show us
the conflict and should be deleted. Next, we need to tell Git that we're
done resolving the conflict:
-``` k
+```k
git add index.html
git status
```
@@ -1930,7 +1938,7 @@ git status
That's right, all you have to do is add `index.html` to the staged
snapshot to mark it as resolved. Finally, complete the 3-way merge:
-``` k
+```k
git commit
```
@@ -1942,14 +1950,14 @@ create the merge commit.
The final state of our project looks like the following.
-
+
## Cleanup the Feature Branches {#branches-2.xhtml_cleanup-the-feature-branches}
Since our crazy experiment has been successfully merged, we can get rid
of our feature branches.
-``` k
+```k
git branch -d crazy
git branch -d crazy-alt
```
@@ -1959,7 +1967,7 @@ delete a branch that contains unmerged changes. But, we really do want
to scrap the alternative experiment, so we'll follow the error message's
instructions for overriding this behavior:
-``` k
+```k
git branch -D crazy-alt
```
@@ -1969,9 +1977,9 @@ which are now reachable via the `master` branch. That is to say, it is
still part of the structure of the repository's history, even though we
deleted our reference to it.
-
+
-Fast-forward merges are *not* reflected in the project history. This is
+Fast-forward merges are _not_ reflected in the project history. This is
the tangible distinction between fast-forward merges and 3-way merges.
The next module will discuss the appropriate usage of both and the
potential complications of a non-linear history.
@@ -1980,11 +1988,11 @@ potential complications of a non-linear history.
This module demonstrated the three most common uses of Git branches:
-- To develop long-running features (`crazy`)
-- To apply quick updates (`news-hotfix`)
-- To record the evolution of a project (`master`)
+- To develop long-running features (`crazy`)
+- To apply quick updates (`news-hotfix`)
+- To record the evolution of a project (`master`)
-In the first two cases, we needed an *isolated* environment to test some
+In the first two cases, we needed an _isolated_ environment to test some
changes before integrating them with our stable code. As you get more
comfortable with Git, you should find yourself doing virtually
everything in an isolated topic branch, then merging it into a stable
@@ -1995,7 +2003,7 @@ We used the permanent `master` branch as the foundation for all of these
temporary branches, effectively making it the historian for our entire
project. In addition to `master`, many programmers often add a second
permanent branch called `develop`. This lets them use `master` to record
-*really* stable snapshots (e.g., public releases) and use `develop` as
+_really_ stable snapshots (e.g., public releases) and use `develop` as
more of a preparation area for `master`.
This module also introduced the 3-way merge, which combines two branches
@@ -2010,12 +2018,12 @@ our history is easy to navigate.
## Quick Reference {#branches-2.xhtml_quick-reference}
`git commit -a -m "<message>"`
-: Stage all tracked files and commit the snapshot using the specified
- message.
+: Stage all tracked files and commit the snapshot using the specified
+message.
`git branch -D <branch-name>`
-: Force the removal of an unmerged branch (*be careful*: it will be
- lost forever).
+: Force the removal of an unmerged branch (_be careful_: it will be
+lost forever).
:::::
::::::
@@ -2023,6 +2031,7 @@ our history is easy to navigate.
:::::: {#rebasing.xhtml_page}
::::: {#rebasing.xhtml_content}
+
# Rebasing {#rebasing.xhtml_rebasing}
Let's start this module by taking an in-depth look at our history. The
@@ -2032,7 +2041,7 @@ interspersed with commits from other branches, along with a superfluous
merge commit (`b9ae1bc`). In other words, our repository's history is
kind of messy:
-``` s
+```s
ec1b8cb Merge branch 'crazy'
*42fa173 Add news item for rainbow
3db88e1 Add 1st news item
@@ -2052,15 +2061,15 @@ b650e4b Create index page
Fortunately, Git includes a tool to help us clean up our commits:
`git rebase`. Rebasing lets us move branches around by changing the
-commit that they are *based* on. Conceptually, this is what it allows us
+commit that they are _based_ on. Conceptually, this is what it allows us
to do:
-
+
After rebasing, the `feature` branch has a new parent commit, which is
the same commit pointed to by `master`. Instead of joining the branches
with a merge commit, rebasing integrates the `feature` branch by
-building *on top of* `master`. The result is a perfectly linear history
+building _on top of_ `master`. The result is a perfectly linear history
that reads more like a story than the hodgepodge of unrelated edits
shown above.
@@ -2069,7 +2078,7 @@ example project so that we have something to work with. Then, we'll go
back and rewrite history using `git rebase`.
::: {.icon-text .download-icon-text}
-{style="max-width: 45px"}
+{style="max-width: 45px"}
[Download the repository for this
module](http://rypress.com/tutorials/git/media/repo-zips/rebasing.zip)
@@ -2088,7 +2097,7 @@ We'll begin by creating an about page for the website. Remember, we
should be doing all of our work in isolated branches so that we don't
cause any unintended changes to the stable version of the project.
-``` k
+```k
git branch about
git checkout about
```
@@ -2098,7 +2107,7 @@ commits so that we can see the effects of a rebase. First, make a new
directory in `my-git-repo` called `about`. Then, create the empty file
`about/index.html`. Stage and commit a snapshot.
-``` k
+```k
git add about
git status
git commit -m "Add empty page in about section"
@@ -2110,7 +2119,7 @@ Note that `git add` can also add entire directories to the staging area.
Next, we'll add some HTML to `about/index.html`:
-``` cp
+```cp
<!DOCTYPE html>
<html lang="en">
<head>
@@ -2126,7 +2135,7 @@ Next, we'll add some HTML to `about/index.html`:
<li><a href="me.html">Me: The Developer</a></li>
<li><a href="mary.html">Mary: The Graphic Designer</a></li>
</ul>
-
+
<p><a href="../index.html">Return to home page</a></p>
</body>
</html>
@@ -2134,7 +2143,7 @@ Next, we'll add some HTML to `about/index.html`:
Stage and commit the snapshot.
-``` k
+```k
git status
git commit -a -m "Add contents to about page"
```
@@ -2142,16 +2151,16 @@ git commit -a -m "Add contents to about page"
After a few commits on this branch, our history looks like the
following.
-
+
## Another Emergency Update! {#rebasing.xhtml_another-emergency-update}
-*Our boss just gave us some more breaking news!* Again, we'll use a
+_Our boss just gave us some more breaking news!_ Again, we'll use a
hotfix branch to update the site without affecting our about page
developments. Make sure to base the updates on `master`, not the `about`
branch:
-``` k
+```k
git checkout master
git branch news-hotfix
git checkout news-hotfix
@@ -2160,7 +2169,7 @@ git branch
Change the "News" section in `index.html` to:
-``` nt
+```nt
<h2 style="color: #C00">News</h2>
<ul>
<li><a href="news-1.html">Blue Is The New Hue</a></li>
@@ -2171,14 +2180,14 @@ Change the "News" section in `index.html` to:
Commit a snapshot:
-``` k
+```k
git status
git commit -a -m "Add 2nd news item to index page"
```
Then, create a new page called `news-2.html`:
-``` cp
+```cp
<!DOCTYPE html>
<html lang="en">
<head>
@@ -2188,12 +2197,12 @@ Then, create a new page called `news-2.html`:
</head>
<body>
<h1 style="color: #C03">A Red Rebellion</h1>
-
+
<p>Earlier today, several American design firms
announced that they have completely rejected the use
of blue in any commercial ventures. They have
opted instead for <span style="color: #C03">Red</span>.</p>
-
+
<p><a href="index.html">Return to home page</a></p>
</body>
</html>
@@ -2201,7 +2210,7 @@ Then, create a new page called `news-2.html`:
Stage and commit another snapshot:
-``` k
+```k
git add news-2.html
git status
git commit -m "Add article for 2nd news item"
@@ -2211,7 +2220,7 @@ git commit -m "Add article for 2nd news item"
We're ready to merge the news update back into `master`.
-``` k
+```k
git checkout master
git merge news-hotfix
git branch -d news-hotfix
@@ -2221,7 +2230,7 @@ The `master` branch hasn't been altered since we created `news-hotfix`,
so Git can perform a fast-forward merge. Our repository now looks like
the following.
-
+
## Rebase the About Branch {#rebasing.xhtml_rebase-the-about-branch}
@@ -2229,7 +2238,7 @@ This puts us in the exact same position as we were in before our first
3-way merge. We want to pull changes from `master` into a feature
branch, only this time we'll do it with a rebase instead of a merge.
-``` k
+```k
git checkout about
git rebase master
git log --oneline
@@ -2237,17 +2246,17 @@ git log --oneline
Originally, the `about` branch was based on the
`Merge branch 'crazy-experiment'` commit. The rebase took the entire
-`about` branch and plopped it onto the *tip* of the `master` branch,
+`about` branch and plopped it onto the _tip_ of the `master` branch,
which is visualized in the following diagram. Also notice that, like the
`git merge` command, `git rebase` requires you to be on the branch that
you want to move.
-
+
After the rebase, `about` is a linear extension of the `master` branch,
enabling us to do a fast-forward merge later on. Rebasing also allowed
-us to integrate the most up-to-date version of `master` *without a merge
-commit*.
+us to integrate the most up-to-date version of `master` _without a merge
+commit_.
## Add a Personal Bio {#rebasing.xhtml_add-a-personal-bio}
@@ -2255,7 +2264,7 @@ With our news hotfix out of the way, we can now continue work on our
about section. Create the file `about/me.html` with the following
contents:
-``` cp
+```cp
<!DOCTYPE html>
<html lang="en">
<head>
@@ -2281,7 +2290,7 @@ contents:
Then, commit the changes to the repository.
-``` k
+```k
git add about/me.html
git commit -m "Add HTML page for personal bio"
git log --oneline
@@ -2295,13 +2304,13 @@ an unnecessary fork in our project history.
## Add Dummy Page for Mary {#rebasing.xhtml_add-dummy-page-for-mary}
Once again, the next two snapshots are unnecessarily trivial. However,
-we'll use an *interactive* rebase to combine them into a single commit
+we'll use an _interactive_ rebase to combine them into a single commit
later on. That's right, `git rebase` not only lets you move branches
around, it enables you to manipulate individual commits as you do so.
Create a new empty file in the about section: `about/mary.html`.
-``` k
+```k
git add about
git status
git commit -m "Add empty HTML page for Mary's bio"
@@ -2312,7 +2321,7 @@ git commit -m "Add empty HTML page for Mary's bio"
Then, add a link to the about page in `index.html` so that its
"Navigation" section looks like the following.
-``` nt
+```nt
<h2>Navigation</h2>
<ul>
<li>
@@ -2332,7 +2341,7 @@ Then, add a link to the about page in `index.html` so that its
Don't forget to commit the change:
-``` k
+```k
git commit -a -m "Add link to about section in home page"
```
@@ -2340,11 +2349,11 @@ git commit -a -m "Add link to about section in home page"
Before we merge into the `master` branch, we should make sure we have a
clean, meaningful history in our feature branch. By rebasing
-interactively, we can choose *how* each commit is transferred to the new
+interactively, we can choose _how_ each commit is transferred to the new
base. Specify an interactive rebase by passing the `-i` flag to the
rebase command:
-``` k
+```k
git rebase -i master
```
@@ -2361,7 +2370,7 @@ only need the `squash` command. This will condense our unnecessarily
small commits into a single, meaningful snapshot. Change your listing to
match the following:
-``` k
+```k
pick 5cf316e Add empty page in about section
squash 964e013 Add contents to about page
pick 89db9ab Add HTML page for personal bio
@@ -2373,25 +2382,25 @@ Then, begin the rebase by saving and closing the editor. The following
list describes the rebasing process in-depth and tells you what you need
to change along the way.
-1. Git moves the `5cf316e` commit to the tip of `master`.
-2. Git combines the snapshots of `964e013` and `5cf316e`.
-3. Git stops to ask you what commit message to use for the combined
+1. Git moves the `5cf316e` commit to the tip of `master`.
+2. Git combines the snapshots of `964e013` and `5cf316e`.
+3. Git stops to ask you what commit message to use for the combined
snapshot. It automatically includes the messages of both commits,
but you can delete that and simplify it to just
`Create the about page`. Save and exit the text editor to continue.
-4. Git repeats this process for commits `89db9ab` and `2bda8e5`. Use
+4. Git repeats this process for commits `89db9ab` and `2bda8e5`. Use
`Begin creating bio pages` for the message.
-5. Git adds the final commit (`915466f`) on top of the commits created
+5. Git adds the final commit (`915466f`) on top of the commits created
in the previous steps.
You can see the result of all this activity with `git log --oneline`, as
well as in the diagram below. The five commits originally in `about`
have been condensed to three, and two of them have new messages. Also
notice that they all have different commit ID's. These new ID's tell us
-that we didn't just *move* a couple of commits---we've literally
+that we didn't just _move_ a couple of commits---we've literally
rewritten our repository history with brand new commits.
-
+
Interactive rebasing gives you complete control over your project
history, but this can also be very dangerous. For example, if you were
@@ -2402,19 +2411,19 @@ trouble with public Git repositories.
## Stop to Amend a Commit {#rebasing.xhtml_stop-to-amend-a-commit}
-The previous rebase only stopped us to edit the *messages* of each
-commit. We can take this one step further and alter a *snapshot* during
+The previous rebase only stopped us to edit the _messages_ of each
+commit. We can take this one step further and alter a _snapshot_ during
the rebase. Start by running another interactive rebasing session. Note
that we've still been using `master` as the new base because it selects
the desired commits from the `about` branch.
-``` k
+```k
git rebase -i master
```
Specify the `edit` command for the second commit, as shown below.
-``` k
+```k
pick 58dec2a Create the about page
edit 6ac8a9f Begin creating bio pages
pick 51c958c Add link to about section in home page
@@ -2424,7 +2433,7 @@ When Git starts to move the second commit to the new base, it will stop
to do some "amending." This gives you the opportunity to alter the
staged snapshot before committing it.
-
+
We'll leave a helpful note for Mary, whom we'll meet in the
[Remotes](#remotes.xhtml) module. Open up `about/mary.html` and add the
@@ -2436,14 +2445,14 @@ We're currently between commits in a rebase, but we can alter the staged
snapshot in the exact same way as we have been throughout this entire
tutorial:
-``` k
+```k
git add about/mary.html
git status
git commit --amend
```
You can use the default message created by `git commit`. The new
-`‑‑amend` flag tells Git to *replace* the existing commit with the
+`‑‑amend` flag tells Git to _replace_ the existing commit with the
staged snapshot instead of creating a new one. This is also very useful
for fixing premature commits that often occur during normal development.
@@ -2453,7 +2462,7 @@ Remember that we're in the middle of a rebase, and Git still has one
more commit that it needs to re-apply. Tell Git that we're ready to move
on with the `--continue` flag:
-``` k
+```k
git rebase --continue
git log --oneline
```
@@ -2469,13 +2478,13 @@ start over from scratch.
## Publish the About Section {#rebasing.xhtml_publish-the-about-section}
-The point of all this interactive rebasing is to generate a *meaningful*
+The point of all this interactive rebasing is to generate a _meaningful_
history that we can merge back into `master`. And, since we've rebased
`about` onto the tip of `master`, Git will be able to perform a
fast-forward merge instead of using a merge commit to join the two
branches.
-``` k
+```k
git checkout master
git log --oneline
git merge about
@@ -2484,16 +2493,16 @@ git log --oneline
Don't forget to delete the obsolete `about` branch.
-``` k
+```k
git branch -d about
```
Our final history is shown in the figure below. As you can see, a linear
history is much easier to comprehend than the back-and-forth merging of
the previous module. But on the other hand, we don't have the slightest
-notion of *how* we got to our current state.
+notion of _how_ we got to our current state.
-
+
## Conclusion {#rebasing.xhtml_conclusion}
@@ -2508,12 +2517,12 @@ power to choose exactly what gets stored in your repositories.
This can actually be a bit of a controversial topic within the Git
community. Some believe that the benefits discussed in this module
aren't worth the hassle of rewriting history. They take a more "pure"
-approach to Git by saying that your history should reflect *exactly*
+approach to Git by saying that your history should reflect _exactly_
what you've done, ensuring that no information is ever lost.
Furthermore, an advanced configuration of `git log` can display a linear
history from a highly-branched repository.
-But, others contend that merge commits should be *meaningful*. Instead
+But, others contend that merge commits should be _meaningful_. Instead
of merging at arbitrary points just to access updates, they claim that
merge commits should represent a symbolic joining of two branches. In
particular, large software projects (such as the Linux kernel) typically
@@ -2526,7 +2535,7 @@ trouble when you can accomplish close to the same functionality using
merges exclusively. As a related note, you can use the following command
to force a merge commit when Git would normally do a fast-forward merge.
-``` k
+```k
git merge --no-ff <branch-name>
```
@@ -2537,25 +2546,25 @@ how to recover deleted commits.
## Quick Reference {#rebasing.xhtml_quick-reference}
`git rebase <new-base>`
-: Move the current branch's commits to the tip of `<new-base>`, which
- can be either a branch name or a commit ID.
+: Move the current branch's commits to the tip of `<new-base>`, which
+can be either a branch name or a commit ID.
`git rebase -i <new-base>`
-: Perform an interactive rebase and select actions for each commit.
+: Perform an interactive rebase and select actions for each commit.
`git commit --amend`
-: Add staged changes to the most recent commit instead of creating a
- new one.
+: Add staged changes to the most recent commit instead of creating a
+new one.
`git rebase --continue`
-: Continue a rebase after amending a commit.
+: Continue a rebase after amending a commit.
`git rebase --abort`
-: Abandon the current interactive rebase and return the repository to
- its former state.
+: Abandon the current interactive rebase and return the repository to
+its former state.
`git merge --no-ff <branch-name>`
-: Force a merge commit even if Git could do a fast-forward merge.
+: Force a merge commit even if Git could do a fast-forward merge.
:::::
::::::
@@ -2563,6 +2572,7 @@ how to recover deleted commits.
:::::: {#rewriting-history.xhtml_page}
::::: {#rewriting-history.xhtml_content}
+
# Rewriting History {#rewriting-history.xhtml_rewriting-history}
The previous module on rebasing taught us how to move commits around and
@@ -2576,7 +2586,7 @@ Git components, as we'll be inspecting and editing the internal makeup
of our project.
::: {.icon-text .download-icon-text}
-{style="max-width: 45px"}
+{style="max-width: 45px"}
[Download the repository for this
module](http://rypress.com/tutorials/git/media/repo-zips/rewriting-history.zip)
@@ -2593,7 +2603,7 @@ from the above link, uncompress it, and you're good to go.
First, let's create a new branch and add a few more HTML pages.
-``` k
+```k
git checkout -b new-pages
git branch
```
@@ -2603,7 +2613,7 @@ by passing the `-b` flag to the `git checkout` command.
Next, create the file `red.html` and add the following content:
-``` cp
+```cp
<!DOCTYPE html>
<html lang="en">
<head>
@@ -2614,7 +2624,7 @@ Next, create the file `red.html` and add the following content:
<body>
<h1 style="color: #C00">The Red Page</h1>
<p>Red is the color of <span style="color: #C00">passion</span>!</p>
-
+
<p><a href="index.html">Return to home page</a></p>
</body>
</html>
@@ -2627,7 +2637,7 @@ We'll hold off on committing this page for the moment.
Create a file called `yellow.html`, which should look like the
following.
-``` cp
+```cp
<!DOCTYPE html>
<html lang="en">
<head>
@@ -2638,7 +2648,7 @@ following.
<body>
<h1 style="color: #FF0">The Yellow Page</h1>
<p>Yellow is the color of <span style="color: #FF0">the sun</span>!</p>
-
+
<p><a href="index.html">Return to home page</a></p>
</body>
</html>
@@ -2649,7 +2659,7 @@ following.
Next, we'll link both new pages to the home page. Add the following
items to the "Navigation" section in `index.html`:
-``` nt
+```nt
<li style="color: #C00">
<a href="red.html">The Red Page</a>
</li>
@@ -2660,20 +2670,20 @@ items to the "Navigation" section in `index.html`:
Then, commit all of these changes in a single snapshot.
-``` k
+```k
git add red.html yellow.html index.html
git status
git commit -m "Add new HTML pages"
```
-This is an example of a *bad* commit. It performed multiple, unrelated
+This is an example of a _bad_ commit. It performed multiple, unrelated
tasks, and it has a relatively generic commit message. Thus far, we
haven't really specified when it's appropriate to commit changes, but
the general rules are essentially the same as for branch creation:
-- Commit a snapshot for each significant addition to your project.
-- *Don't* commit a snapshot if you can't come up with a single,
- specific message for it.
+- Commit a snapshot for each significant addition to your project.
+- _Don't_ commit a snapshot if you can't come up with a single,
+ specific message for it.
This will ensure that your project has a meaningful commit history,
which gives you the ability to see exactly when and where a feature was
@@ -2688,7 +2698,7 @@ up these problem commits after the fact.
Let's create one more page before splitting that "bad" commit: Add the
following HTML to a file called `green.html`.
-``` cp
+```cp
<!DOCTYPE html>
<html lang="en">
<head>
@@ -2699,7 +2709,7 @@ following HTML to a file called `green.html`.
<body>
<h1 style="color: #0C0">The Green Page</h1>
<p><span style="color: #0C0">Green</span> is the color of earth.</p>
-
+
<p><a href="index.html">Return to home page</a></p>
</body>
</html>
@@ -2707,7 +2717,7 @@ following HTML to a file called `green.html`.
Add a link to `index.html` in the "Navigation" section:
-``` nt
+```nt
<li style="color: #0C0">
<a href="green.html">The Green Page</a>
</li>
@@ -2715,7 +2725,7 @@ Add a link to `index.html` in the "Navigation" section:
And finally, stage the green page and commit the snapshot.
-``` k
+```k
git add green.html index.html
git status
git commit -m "Add green page"
@@ -2725,31 +2735,31 @@ git commit -m "Add green page"
The commits introduced in our `new-pages` branch are:
-``` s
+```s
4c3027c Add green page
db96c72 Add new HTML pages
```
But, we want these commits to look more like:
-``` s
+```s
4c3027c Add green page
9b1a64f Add yellow page
77a1cf1 Add red page
```
To achieve this, we can use the same interactive rebasing method covered
-in the previous module, only this time we'll actually *create* commits
+in the previous module, only this time we'll actually _create_ commits
in the middle of the rebasing procedure.
-``` k
+```k
git rebase -i master
```
Change the rebase listing to the following, then save the file and exit
the editor to begin the rebase.
-``` k
+```k
edit db96c72 Add new HTML pages
pick 4c3027c Add green page
```
@@ -2758,7 +2768,7 @@ pick 4c3027c Add green page
First, let's take a look at where we are with `git log --oneline`:
-``` s
+```s
db96c72 Add new HTML pages
7070b0e Add link to about section in home page
...
@@ -2767,10 +2777,10 @@ db96c72 Add new HTML pages
When Git encountered the `edit` command in the rebase configuration, it
stopped to let us edit the commit. As a result, the green page commit
doesn't appear in our history yet. This should be familiar from the
-previous module. But instead of *amending* the current commit, we're
+previous module. But instead of _amending_ the current commit, we're
going to completely remove it:
-``` k
+```k
git reset --mixed HEAD~1
git log --oneline
git status
@@ -2783,7 +2793,7 @@ second commit before `HEAD`). In this particular case, `HEAD~1` happens
to coincide with `master`. The effect on our repository can be
visualized as:
-
+
You may recall from [Undoing Changes](#undoing-changes.xhtml) that we
used `git reset --hard` to undo uncommitted changes to our project. The
@@ -2805,7 +2815,7 @@ involves the red page, we'll have to manually go in and remove the
yellow page's link from the "Navigation" section. In `index.html`,
change this section to match the following:
-``` nt
+```nt
<h2>Navigation</h2>
<ul>
<li>
@@ -2828,7 +2838,7 @@ change this section to match the following:
Now, we can group the red page's updates into an independent commit.
-``` k
+```k
git add red.html index.html
git status
git commit -m "Add red page"
@@ -2837,7 +2847,7 @@ git commit -m "Add red page"
Next up is the yellow page. Go ahead and add it back to the "Navigation"
section in `index.html`:
-``` nt
+```nt
<li style="color: #FF0">
<a href="yellow.html">The Yellow Page</a>
</li>
@@ -2845,7 +2855,7 @@ section in `index.html`:
And again, stage and commit the snapshot.
-``` k
+```k
git add yellow.html index.html
git status
git commit -m "Add yellow page"
@@ -2854,12 +2864,12 @@ git commit -m "Add yellow page"
We've successfully split up the contents of a single commit into two new
snapshots, as shown below.
-
+
But, don't forget that the rebase still needs to transfer the green
page:
-``` k
+```k
git rebase --continue
```
@@ -2875,7 +2885,7 @@ content, and the entire result will be moved to the new base.
Next, we're going to "accidentally" remove the green page commit so we
can learn how to retrieve it via Git's internal repository data.
-``` k
+```k
git reset --hard HEAD~1
git status
git log --oneline
@@ -2888,13 +2898,13 @@ the working directory. And of course, the `git log` output shows that
the `new-pages` branch no longer contains the green commit.
This behavior is slightly different from the reset we used in the
-interactive rebase: this time the *branch* moved with the new `HEAD`.
+interactive rebase: this time the _branch_ moved with the new `HEAD`.
Since we were on `(no branch)` during the rebase, there was no branch
tip to move. However, in general, `git reset` is used to move branch
tips around and optionally alter the working directory via one of its
many flags (e.g., `--mixed` or `--hard`).
-
+
The commit that we removed from the branch is now a **dangling commit**.
Dangling commits are those that cannot be reached from any branch and
@@ -2905,7 +2915,7 @@ are thus in danger of being lost forever.
Git uses something called the **reflog** to record every change you make
to your repository. Let's take a look at what it contains:
-``` k
+```k
git reflog
```
@@ -2913,7 +2923,7 @@ The resulting output should look something like the following. Depending
on your version of Git, the messages might be slightly different. You
can press `Space` to scroll through the content or `q` to exit.
-``` s
+```s
9b1a64f HEAD@{0}: reset: moving to HEAD~1
002185c HEAD@{1}: rebase -i (finish): returning to refs/heads/new-pages
002185c HEAD@{2}: rebase -i (pick): Add green page
@@ -2928,7 +2938,7 @@ current `HEAD`, denoted by `HEAD@{0}`, resulted from reseting `HEAD` to
`HEAD~1`. Four actions ago, the yellow page was applied during our
rebase, as shown in `HEAD@{3}`.
-The reflog is a *chronological* listing of our history, without regard
+The reflog is a _chronological_ listing of our history, without regard
for the repository's branch structure. This lets us find dangling
commits that would otherwise be lost from the project history.
@@ -2937,30 +2947,30 @@ commits that would otherwise be lost from the project history.
At the beginning of each reflog entry, you'll find a commit ID
representing the `HEAD` after that action. Check out the commit at
`HEAD@{2}`, which should be where the rebase added the green page
-(change the ID below to the ID from *your* reflog).
+(change the ID below to the ID from _your_ reflog).
-``` k
+```k
git checkout 002185c
```
This puts us in a `detached HEAD` state, which means our `HEAD` is no
longer on the tip of a branch. We're actually in the opposite situation
as we were in [Undoing Changes](#undoing-changes.xhtml) when we checked
-out a commit *before* the branch tip. Now, we're looking at a commit
-*after* the tip of the branch, but we still have a `detached HEAD`:
+out a commit _before_ the branch tip. Now, we're looking at a commit
+_after_ the tip of the branch, but we still have a `detached HEAD`:
-
+
To turn our dangling commit into a full-fledged branch, all we have to
do is create one:
-``` k
+```k
git checkout -b green-page
```
We now have a branch that can be merged back into the project:
-
+
The above diagram makes it easy to see that the `green-page` branch is
an extension of `new-pages`, but how would we figure this out if we
@@ -2971,7 +2981,7 @@ weren't drawing out the state of our repository every step of the way?
To view the differences between branches, we can use Git's log-filtering
syntax.
-``` k
+```k
git log new-pages..green-page
```
@@ -2985,14 +2995,14 @@ You can also use this syntax to limit the output of `git log`. For
example, to display the last 4 commits on the current branch, you could
use:
-``` k
+```k
git log HEAD~4..HEAD
```
However, this is a bit verbose for such a common task, so Git developers
added the `-n` flag as an easier way to limit output.
-``` k
+```k
git log -n 4
```
@@ -3008,7 +3018,7 @@ We've revived our lost commit, and now we're ready to merge everything
back into the `master` branch. Before we do the merge, let's see exactly
what we're merging:
-``` k
+```k
git checkout master
git log HEAD..green-page --stat
```
@@ -3020,7 +3030,7 @@ information about which files have been changed in each commit. For
example, the most recent commit tells us that 14 lines were added to the
`green.html` file and 3 lines were added to `index.html`:
-``` k
+```k
commit 002185c71e6674915eb75be2afb4ca52c2c7fd1b
Author: Ryan <ryan.example@rypress.com>
Date: Wed Jan 11 06:49:50 2012 -0600
@@ -3036,26 +3046,26 @@ If we didn't already know what was in this new commit, the log output
would tell us which files we needed to look at. But, we authored all of
these changes, so we can skip right to the merge.
-``` k
+```k
git merge green-page
```
The following diagram shows the state of our repository after the merge.
-
+
Note that the `green-page` branch already contains all the history of
`new-pages`, which is why we merged the former instead of the latter. If
this wasn't the case, Git would complain when we try to run the
following command.
-``` k
+```k
git branch -d new-pages
```
We can go ahead and delete the green page branch, too.
-``` k
+```k
git branch -d green-page
```
@@ -3070,12 +3080,12 @@ options for displaying our commit history, which will become an
important skill as our project grows.
We did a lot of work with branch tips this module. It's important to
-realize that Git uses the *tip* of a branch to represent the *entire
-branch*. That is to say, a branch is actually a pointer to a single
+realize that Git uses the _tip_ of a branch to represent the _entire
+branch_. That is to say, a branch is actually a pointer to a single
commit---not a container for a series of commits. This idea has been
implicitly reflected in our diagrams:
-
+
The history is represented by the parent of each commit (designated by
arrows), not the branch itself. So, to request a new branch, all Git has
@@ -3093,22 +3103,22 @@ on Git branches.
## Quick Reference {#rewriting-history.xhtml_quick-reference}
`git reflog`
-: Display the local, chronological history of a repository.
+: Display the local, chronological history of a repository.
`git reset --mixed HEAD~<n>`
-: Move the `HEAD` backward `<n>` commits, but don't change the working
- directory.
+: Move the `HEAD` backward `<n>` commits, but don't change the working
+directory.
`git reset --hard HEAD~<n>`
-: Move the `HEAD` backward `<n>` commits, and change the working
- directory to match.
+: Move the `HEAD` backward `<n>` commits, and change the working
+directory to match.
`git log <since>..<until>`
-: Display the commits reachable from `<until>` but not from `<since>`.
- These parameters can be either commit ID's or branch names.
+: Display the commits reachable from `<until>` but not from `<since>`.
+These parameters can be either commit ID's or branch names.
`git log --stat`
-: Include extra information about altered files in the log output.
+: Include extra information about altered files in the log output.
:::::
::::::
@@ -3116,6 +3126,7 @@ on Git branches.
:::::: {#remotes.xhtml_page}
::::: {#remotes.xhtml_content}
+
# Remotes {#remotes.xhtml_remotes}
Simply put, a **remote repository** is one that is not your own. It can
@@ -3129,7 +3140,7 @@ sharing commits between repositories. **Remote branches** act just like
the local branches that we've been using, only they represent a branch
in someone else's repository.
-
+
This means that we can adapt our merging and rebasing skills to make Git
a fantastic collaboration tool. Over the next few modules, we'll be
@@ -3141,7 +3152,7 @@ graphic designer for our website. Mary's actions are clearly denoted by
including her name in the heading of each step.
::: {.icon-text .download-icon-text}
-{style="max-width: 45px"}
+{style="max-width: 45px"}
[Download the repository for this
module](http://rypress.com/tutorials/git/media/repo-zips/remotes.zip)
@@ -3161,14 +3172,14 @@ First, Mary needs her own copy of the repository to work with. The
discuss network-based remotes, but right now we're just going to store
them on the local filesystem.
-``` k
+```k
cd /path/to/my-git-repo
cd ..
git clone my-git-repo marys-repo
cd marys-repo
```
-The first two lines navigate the command shell to the directory *above*
+The first two lines navigate the command shell to the directory _above_
`my-git-repo`. Make sure to change `/path/to/my-git-repo` to the actual
path to your repository. The `git clone` command copies our repository
into `marys-repo`, which will reside in the same directory as
@@ -3183,14 +3194,14 @@ original repository.
First off, Mary needs to configure her repository so that we know who
contributed what to the project.
-``` k
+```k
git config user.name "Mary"
git config user.email mary.example@rypress.com
```
You may recall from the first module that we used a `--global` flag to
set the configuration for the entire Git installation. But since Mary's
-repository is on the local filesystem, she needs a *local*
+repository is on the local filesystem, she needs a _local_
configuration.
Use a text editor to open up the file called `config` in the `.git`
@@ -3204,7 +3215,7 @@ the global configuration that we set in [The Basics](#the-basics.xhtml).
Today, Mary is going to be working on her bio page, which she should
develop in a separate branch:
-``` k
+```k
git checkout -b bio-page
```
@@ -3220,7 +3231,7 @@ history, a repository is an abstraction for branches.
Let's complete Mary's biography page. In `marys-repo`, change
`about/mary.html` to:
-``` cp
+```cp
<!DOCTYPE html>
<html lang="en">
<head>
@@ -3247,7 +3258,7 @@ Again, we're developing this in a branch as a best-practice step: our
`master` branch is only for stable, tested code. Stage and commit the
snapshot, then take a look at the result.
-``` k
+```k
git commit -a -m "Add bio page for Mary"
git log -n 1
```
@@ -3260,7 +3271,7 @@ configurations we made for Mary's name and email. Remember that the
Now, we can publish the bio page by merging into the `master` branch.
-``` k
+```k
git checkout master
git merge bio-page
```
@@ -3269,7 +3280,7 @@ Of course, this results in a fast-forward merge. We'll eventually pull
this update into `my-git-repo` once we stop pretending to be Mary.
Here's what Mary's repository looks like compared to ours:
-
+
Notice that both repositories have normal, local branches---we haven't
had any interaction between the two repositories, so we don't see any
@@ -3281,7 +3292,7 @@ examine Mary's remote connections.
Mary can list the connections she has to other repositories using the
following command.
-``` k
+```k
git remote
```
@@ -3291,7 +3302,7 @@ original repository, under the assumption that you'll probably want to
interact with it down the road. We can request a little bit more
information with the `-v` (verbose) flag:
-``` k
+```k
git remote -v
```
@@ -3304,7 +3315,7 @@ in a moment.
Ok, we're done being Mary, and we can return to our own repository.
-``` k
+```k
cd ../my-git-repo
```
@@ -3320,14 +3331,14 @@ her changes in.
Before we can get ahold of Mary's bio page, we need access to her
repository. Let's look at our current list of remotes:
-``` k
+```k
git remote
```
We don't have any (`origin` was never created because we didn't clone
from anywhere). So, let's add Mary as a remote repository.
-``` k
+```k
git remote add mary ../marys-repo
git remote -v
```
@@ -3337,10 +3348,10 @@ We can now use `mary` to refer to Mary's repository, which is located at
another Git repository for easy access, and our connections can be seen
in the figure below.
-
+
-Now that our remote *repositories* are setup, we'll spend the rest of
-the module discussing remote *branches*.
+Now that our remote _repositories_ are setup, we'll spend the rest of
+the module discussing remote _branches_.
## Fetch Mary's Branches (You) {#remotes.xhtml_fetch-marys-branches-you}
@@ -3348,14 +3359,14 @@ As noted earlier, we can use remote branches to access snapshots from
another repository. Let's take a look at our current remote branches
with the `-r` flag:
-``` k
+```k
git branch -r
```
Again, we don't have any. To populate our remote branch listing, we need
to **fetch** the branches from Mary's repository:
-``` k
+```k
git fetch mary
git branch -r
```
@@ -3373,14 +3384,14 @@ local branches. The above listing reflects the state of Mary's
repository at the time of the fetch, but they will not be automatically
updated if Mary continues developing any of her branches.
-That is to say, our remote branches are not *direct* links into Mary's
+That is to say, our remote branches are not _direct_ links into Mary's
repository---they are read-only copies of her branches, stored in our
own repository. This means that we would have to do another fetch to
access new updates.
-
+
-The above figure shows the state of *our* repository. We have access to
+The above figure shows the state of _our_ repository. We have access to
Mary's snapshots (represented as squares) and her branches, even though
we don't have a real-time connection to Mary's repository.
@@ -3388,17 +3399,17 @@ we don't have a real-time connection to Mary's repository.
Let's check out a remote branch to review Mary's changes.
-``` k
+```k
git checkout mary/master
```
This puts us in a `detached HEAD` state, just like we were in when we
checked out a dangling commit. This shouldn't be that surprising,
-considering that our remote branches are *copies* of Mary's branches.
+considering that our remote branches are _copies_ of Mary's branches.
Checking out a remote branch takes our `HEAD` off the tip of a local
branch, illustrated by the following diagram.
-
+
We can't continue developing if we're not on a local branch. To build on
`mary/master` we either need to merge it into our own local `master` or
@@ -3413,7 +3424,7 @@ doesn't really affect us.
We can use the same log-filtering syntax from the previous module to
view Mary's changes.
-``` k
+```k
git log master..mary/master --stat
```
@@ -3421,20 +3432,20 @@ This shows us what Mary has added to her master branch, but it's also a
good idea to see if we've added any new changes that aren't in Mary's
repository:
-``` k
+```k
git log mary/master..master --stat
```
This won't output anything, since we haven't altered our database since
-Mary cloned it. In other words, our history hasn't *diverged*---we're
-just *behind* by a commit.
+Mary cloned it. In other words, our history hasn't _diverged_---we're
+just _behind_ by a commit.
## Merge Mary's Changes {#remotes.xhtml_merge-marys-changes}
Let's approve Mary's changes and integrate them into our own `master`
branch.
-``` k
+```k
git checkout master
git merge mary/master
```
@@ -3443,13 +3454,13 @@ Even though `mary/master` is a remote branch, this still results in a
fast-forward merge because there is a linear path from our `master` to
the tip of `mary/master`:
-
+
After the merge, the snapshots from Mary's remote branch become a part
of our local `master` branch. As a result, our `master` is now
synchronized with Mary's:
-
+
Notice that we only interacted with Mary's `master` branch, even though
we had access to her `bio-page`. If we hadn't been pretending to be
@@ -3461,11 +3472,11 @@ Mary was also aware of this convention).
## Push a Dummy Branch {#remotes.xhtml_push-a-dummy-branch}
To complement our `git fetch` command, we'll take a brief look at
-**pushing**. Fetching and pushing are *almost* opposites, in that
+**pushing**. Fetching and pushing are _almost_ opposites, in that
fetching imports branches, while pushing exports branches to another
repository. Let's take a look:
-``` k
+```k
git branch dummy
git push mary dummy
```
@@ -3473,15 +3484,15 @@ git push mary dummy
This creates a new branch called `dummy` and sends it to Mary. Switch
into Mary's repository to see what we did:
-``` k
+```k
cd ../marys-repo
git branch
```
-You should find a new `dummy` branch in her *local* branch listing. I
-said that `git fetch` and `git push` are *almost* opposites because
-pushing creates a new *local* branch, while fetching imports commits
-into *remote* branches.
+You should find a new `dummy` branch in her _local_ branch listing. I
+said that `git fetch` and `git push` are _almost_ opposites because
+pushing creates a new _local_ branch, while fetching imports commits
+into _remote_ branches.
Now, put yourself in Mary's shoes. She was developing in her own
repository when, all of a sudden, a new `dummy` branch appeared out of
@@ -3495,7 +3506,7 @@ for maintaining public repositories. Until then, just remember to never,
ever push into one of your friend's repositories. Let's get rid of these
dummy branches and return to our repository.
-``` k
+```k
git branch -d dummy
cd ../my-git-repo
git branch -d dummy
@@ -3507,7 +3518,7 @@ An important property of `git push` is that it does not automatically
push tags associated with a particular branch. Let's examine this by
creating a new tag.
-``` k
+```k
git tag -a v2.0 -m "An even stabler version of the website"
```
@@ -3515,7 +3526,7 @@ We now have a `v2.0` tag in `my-git-repo`, which we can see by running
the `git tag` command. Now, let's try pushing the branch to Mary's
repository.
-``` k
+```k
git push mary master
```
@@ -3523,7 +3534,7 @@ Git will say her `master` branch is already up-to-date, and her
repository will remain unchanged. Instead of pushing the branch that
contains the tag, Git requires us to manually push the tag itself:
-``` k
+```k
git push mary v2.0
```
@@ -3545,10 +3556,10 @@ without consulting Mary, but this doesn't necessarily have to be the
case. When implementing your own workflow, Git offers you a lot of
flexibility about when and where you should pull from your team members.
As long as you clearly define your project conventions, you can
-designate special uses or privileges to *any* branch.
+designate special uses or privileges to _any_ branch.
-That said, it's important to note that remotes are for *people*, whereas
-branches are for *topics*. Do *not* create separate branches for each of
+That said, it's important to note that remotes are for _people_, whereas
+branches are for _topics_. Do _not_ create separate branches for each of
your developers---give them separate repositories and bookmark them with
`git remote add`. Branches should always be for project development, not
user management.
@@ -3561,28 +3572,28 @@ repository.
## Quick Reference {#remotes.xhtml_quick-reference}
`git clone <remote-path>`
-: Create a copy of a remote Git repository.
+: Create a copy of a remote Git repository.
`git remote`
-: List remote repositories.
+: List remote repositories.
`git remote add <remote-name> <remote-path>`
-: Add a remote repository.
+: Add a remote repository.
`git fetch <remote-name>`
-: Download remote branch information, but do not merge anything.
+: Download remote branch information, but do not merge anything.
`git merge <remote-name>/<branch-name>`
-: Merge a remote branch into the checked-out branch.
+: Merge a remote branch into the checked-out branch.
`git branch -r`
-: List remote branches.
+: List remote branches.
`git push <remote-name> <branch-name>`
-: Push a local branch to another repository.
+: Push a local branch to another repository.
`git push <remote-name> <tag-name>`
-: Push a tag to another repository.
+: Push a tag to another repository.
:::::
::::::
@@ -3590,6 +3601,7 @@ repository.
:::::: {#centralized-workflows.xhtml_page}
::::: {#centralized-workflows.xhtml_content}
+
# Centralized Workflows {#centralized-workflows.xhtml_centralized-workflows}
In the previous module, we shared information directly between two
@@ -3604,7 +3616,7 @@ between us and Mary. Instead of pulling changes into `my-git-repo` from
storage repository. After this module, our workflow will look like the
following.
-
+
Typically, you would store the central repository on a server to allow
internet-based collaboration. Unfortunately, server configuration can
@@ -3621,7 +3633,7 @@ find them. For everyone else, our network-based Git experience will
begin in the next module.
::: {.icon-text .download-icon-text}
-{style="max-width: 45px"}
+{style="max-width: 45px"}
[Download the repositories for this
module](http://rypress.com/tutorials/git/media/repo-zips/centralized-workflows.zip)
@@ -3643,7 +3655,7 @@ you've decided to host the central repository on your server, you should
SSH into it and run the `git init` command wherever you'd like to store
the repository.
-``` k
+```k
cd /path/to/my-git-repo
cd ..
git init --bare central-repo.git
@@ -3654,11 +3666,11 @@ this time, we used the `--bare` flag to tell Git that we don't want a
working directory. This will prevent us from developing in the central
repository, which eliminates the possibility of messing up another
user's environment with `git push`. A central repository is only
-supposed to act as a *storage facility*---not a development environment.
+supposed to act as a _storage facility_---not a development environment.
If you examine the contents of the resulting `central-repo.git` folder,
you'll notice that it contains the exact same files as the `.git` folder
-in our `my-git-repo` project. Git has *literally* gotten rid of our
+in our `my-git-repo` project. Git has _literally_ gotten rid of our
working directory. The conventional `.git` extension in the directory
name is a way to convey this property.
@@ -3668,7 +3680,7 @@ We've successfully set up a central repository that can be used to share
updates between us, Mary, and any other developers. Next, we should add
it as a remote to both `marys-repo` and `my-git-repo`.
-``` k
+```k
cd marys-repo
git remote rm origin
git remote add origin ../central-repo.git
@@ -3676,7 +3688,7 @@ git remote add origin ../central-repo.git
Now for our repository:
-``` k
+```k
cd ../my-git-repo
git remote add origin ../central-repo.git
git remote rm mary
@@ -3694,26 +3706,26 @@ repository's location for `path/to/central-repo.git`.
## Push the Master Branch (You) {#centralized-workflows.xhtml_push-the-master-branch-you}
-We didn't *clone* the central repository---we just initialized it as a
+We didn't _clone_ the central repository---we just initialized it as a
bare repository. This means it doesn't have any of our project history
yet. We can fix that using the `git push` command introduced in the last
module.
-``` k
+```k
git push origin master
```
Our central repository now contains our entire `master` branch, which we
can double-check with the following.
-``` k
+```k
cd ../central-repo.git
git log
```
This should output the familiar history listing of the `master` branch.
-Recall that `git push` creates *local* branches in the destination
+Recall that `git push` creates _local_ branches in the destination
repository. We said it was dangerous to push to a friend's repository,
as they probably wouldn't appreciate new branches appearing at random.
However, it's safe to create local branches in `central-repo.git`
@@ -3725,7 +3737,7 @@ disturb anyone's development.
Let's see our new centralized collaboration workflow in action by
committing a few more snapshots.
-``` k
+```k
cd ../my-git-repo
git checkout -b news-item
```
@@ -3733,7 +3745,7 @@ git checkout -b news-item
Create a file called `news-3.html` in `my-git-repo` and add the
following HTML.
-``` cp
+```cp
<!DOCTYPE html>
<html lang="en">
<head>
@@ -3748,7 +3760,7 @@ following HTML.
disagreement—announced the adoption of
<span style="color: #D90">Yellow</span> as this year's
color of choice.</p>
-
+
<p><a href="index.html">Return to home page</a></p>
</body>
</html>
@@ -3757,7 +3769,7 @@ following HTML.
Next, add a link to the "News" section of `index.html` so that it looks
like:
-``` nt
+```nt
<h2 style="color: #C00">News</h2>
<ul>
<li><a href="news-1.html">Blue Is The New Hue</a></li>
@@ -3769,7 +3781,7 @@ like:
Stage and commit a snapshot.
-``` k
+```k
git add news-3.html index.html
git status
git commit -m "Add 3rd news item"
@@ -3778,14 +3790,14 @@ git commit -m "Add 3rd news item"
## Publish the News Item (You) {#centralized-workflows.xhtml_publish-the-news-item-you}
Previously, "publishing" meant merging with the local `master` branch.
-But since we're *only* interacting with the central repository, our
+But since we're _only_ interacting with the central repository, our
`master` branch is private again. There's no chance of Mary pulling
content directly from our repository.
-Instead, everyone accesses updates through the *public* `master` branch,
+Instead, everyone accesses updates through the _public_ `master` branch,
so "publishing" means pushing to the central repository.
-``` k
+```k
git checkout master
git merge news-item
git branch -d news-item
@@ -3796,7 +3808,7 @@ After merging into `master` as we normally would, `git push` updates the
central repository's `master` branch to reflect our local `master`. From
our perspective, the push can be visualized as the following:
-
+
Note that this accomplishes the exact same thing as going into the
central repository and doing a fetch/fast-forward merge, except
@@ -3808,14 +3820,14 @@ see some other convenient features of this command later in the module.
Next, let's pretend to be Mary again and add some CSS formatting (she is
our graphic designer, after all).
-``` k
+```k
cd ../marys-repo
git checkout -b css-edits
```
Add the following to the end of `style.css`:
-``` nt
+```nt
h1 {
font-size: 32px;
}
@@ -3831,7 +3843,7 @@ a:link, a:visited {
And, stage and commit a snapshot.
-``` k
+```k
git commit -a -m "Add CSS styles for headings and links"
```
@@ -3840,7 +3852,7 @@ git commit -a -m "Add CSS styles for headings and links"
Oops, Mary forgot to add some formatting. Append the `h3` styling to
`style.css`:
-``` nt
+```nt
h3 {
font-size: 18px;
margin-left: 20px;
@@ -3849,18 +3861,18 @@ h3 {
And of course, stage and commit the updates.
-``` k
+```k
git commit -a -m "Add CSS styles for 3rd level headings"
```
## Clean Up Before Publishing (Mary) {#centralized-workflows.xhtml_clean-up-before-publishing-mary}
Before Mary considers pushing her updates to the central repository, she
-needs to make sure she has a clean history. This *must* be done by Mary,
+needs to make sure she has a clean history. This _must_ be done by Mary,
because it's near-impossible to change history after it has been made
public.
-``` k
+```k
git rebase -i master
```
@@ -3869,7 +3881,7 @@ independent features. Mary doesn't need to go back and figure out what
changes need to be rebased, since they all reside in her current branch.
Change the rebase configuration to:
-``` k
+```k
pick 681bd1c Add CSS styles for headings and links
squash eabac68 Add CSS styles for 3rd level headings
```
@@ -3879,15 +3891,15 @@ first commit's message:
Add CSS styles for headings and links
-Consider what would have happened had Mary rebased *after* pushing to
+Consider what would have happened had Mary rebased _after_ pushing to
the central repository. She would be re-writing commits that other
developers may have already pulled into their project. To Git, Mary's
re-written commits look like entirely new commits (since they have
different ID's). This situation is shown below.
-
+
-The commits labeled *1* and *2* are the public commits that Mary would
+The commits labeled _1_ and _2_ are the public commits that Mary would
be rebasing. Afterwards, the public history is still the exact same as
Mary's original history, but now her local `master` branch has diverged
from `origin/master`---even though they represent the same snapshot.
@@ -3910,7 +3922,7 @@ snapshots.
Now that her history is cleaned up, Mary can publish the changes.
-``` k
+```k
git checkout master
git merge css-edits
git branch -d css-edits
@@ -3925,14 +3937,14 @@ sense to publish it as an independent branch.
Mary still needs to push the changes to the central repository. But
first, let's take a look at the state of everyone's project.
-
+
You might be wondering how Mary can push her local `master` up to the
central repository, since it has progressed since Mary last fetched from
it. This is a common situation when many developers are working on a
project simultaneously. Let's see how Git handles it:
-``` k
+```k
git push origin master
```
@@ -3948,21 +3960,21 @@ Mary can solve this problem by pulling in the central changes before
trying to push her CSS changes. First, she needs the most up-to-date
version of the `origin/master` branch.
-``` k
+```k
git fetch origin
```
Remember that Mary can see what's in `origin/master` and not in the
local `master` using the `..` syntax:
-``` k
+```k
git log master..origin/master
```
And she can also see what's in her `master` that's not in
`origin/master`:
-``` k
+```k
git log origin/master..master
```
@@ -3970,10 +3982,10 @@ Since both of these output a commit, we can tell that Mary's history
diverged. This should also be clear from the diagram below, which shows
the updated `origin/master` branch.
-
+
Mary is now in the familiar position of having to pull in changes from
-another branch. She can either merge, which *cannot* be fast-forwarded,
+another branch. She can either merge, which _cannot_ be fast-forwarded,
or she can rebase for a linear history.
Typically, you'll want to rebase your changes on top of those found in
@@ -3982,7 +3994,7 @@ add my changes to what everyone else has already done." As previously
discussed, rebasing also eliminates superfluous merge commits. For these
reasons, Mary will opt for a rebase.
-``` k
+```k
git rebase origin/master
git push origin master
```
@@ -3991,14 +4003,14 @@ After the rebase, Mary's `master` branch contains everything from the
central repository, so she can do a fast-forward push to publish her
changes.
-
+
## Pull in Changes (You) {#centralized-workflows.xhtml_pull-in-changes-you}
Finally, we'll switch back to our repository and pull in Mary's CSS
formatting.
-``` k
+```k
cd ../my-git-repo
git fetch origin
git log master..origin/master --stat
@@ -4011,7 +4023,7 @@ usually a good idea to check this before trying to merge in a remote
branch. Otherwise, you might end up with some extra merge commits when
you thought you were fast-forwarding your branch.
-``` k
+```k
git merge origin/master
```
@@ -4024,7 +4036,7 @@ having to keep track of a dozen different developers' repositories in
real-time. This kind of chaos is precisely the problem a centralized
collaboration workflow is designed to solve:
-
+
The presence of a central communication hub condenses all this
development into a single repository and ensures that no one overwrites
@@ -4056,10 +4068,10 @@ standard: the integrator workflow.
## Quick Reference {#centralized-workflows.xhtml_quick-reference}
`git init --bare <repository-name>`
-: Create a Git repository, but omit the working directory.
+: Create a Git repository, but omit the working directory.
`git remote rm <remote-name>`
-: Remove the specified remote from your bookmarked connections.
+: Remove the specified remote from your bookmarked connections.
:::::
::::::
@@ -4067,13 +4079,14 @@ standard: the integrator workflow.
:::::: {#distributed-workflows.xhtml_page}
::::: {#distributed-workflows.xhtml_content}
+
# Distributed Workflows {#distributed-workflows.xhtml_distributed-workflows}
Now that we know how to share information via a centralized workflow, we
can appreciate some of the drawbacks of this collaboration model. While
it may be convenient, allowing everyone to push to an "official"
repository raises some legitimate security concerns. It means that for
-anyone to contribute content, they need access to the *entire project.*
+anyone to contribute content, they need access to the _entire project._
This is fine if you're only interacting with a small team, but imagine a
scenario where you're working on an open-source software project and a
@@ -4083,14 +4096,14 @@ your central repository, since they could start pushing all sorts of
random snapshots, and you would effectively lose control of the project.
But, what you can do is tell the contributor to push the changes to
-*their own* public repository. Then, you can pull their bug fix into
+_their own_ public repository. Then, you can pull their bug fix into
your private repository to ensure it doesn't contain any undeclared
code. If you approve their contributions, all you have to do is merge
them into a local branch and push it to the main repository, just like
-we did in the previous module. You've become an *integrator*, in
+we did in the previous module. You've become an _integrator_, in
addition to an ordinary developer:
-
+
In this module, we'll experience all of this first-hand by creating a
free public repository on [Bitbucket.org](http://bitbucket.org) and
@@ -4099,7 +4112,7 @@ Bitbucket is a DVCS hosting provider that makes it very easy to set up a
Git repository and start collaborating with a team of developers.
::: {.icon-text .download-icon-text}
-{style="max-width: 45px"}
+{style="max-width: 45px"}
[Download the repositories for this
module](http://rypress.com/tutorials/git/media/repo-zips/distributed-workflows.zip)
@@ -4119,7 +4132,7 @@ The first part of this module will walk you through setting up a
Bitbucket account. Navigate your web browser to
[Bitbucket.org](http://bitbucket.org) and sign up for a free account.
-
+
You can choose any username for your account, but the email address
should match the one you assigned to your Git installation with
@@ -4130,13 +4143,13 @@ your email, you can run another
## Create a Public Repository (You) {#distributed-workflows.xhtml_create-a-public-repository-you}
To create our first networked Git repository, log into your Bitbucket
-account, and navigate to *Repositories \> Create repository*. Use
-`my-git-repo` as the *Repository Name*, and anything you like for the
-*Description* field. Since this is just an example project, go ahead and
-uncheck the *This is a private repository* field. Select *HTML/CSS* for
-the *Language* field, then go ahead and click *Create repository*.
+account, and navigate to _Repositories \> Create repository_. Use
+`my-git-repo` as the _Repository Name_, and anything you like for the
+_Description_ field. Since this is just an example project, go ahead and
+uncheck the _This is a private repository_ field. Select _HTML/CSS_ for
+the _Language_ field, then go ahead and click _Create repository_.
-
+
Essentially, we just ran `git init --bare` on a Bitbucket server. We can
now push to and fetch from this repository as we did with
@@ -4146,7 +4159,7 @@ After initialization, Bitbucket offers some helpful instructions, but
don't follow them just yet---we'll walk through importing an existing
repository in the next section.
-
+
## Push to the Public Repository (You) {#distributed-workflows.xhtml_push-to-the-public-repository-you}
@@ -4155,7 +4168,7 @@ project, we first need to point our `origin` remote to the Bitbucket
repository. Be sure to change the `<username>` portion to your actual
Bitbucket username.
-``` k
+```k
cd /path/to/my-git-repo
git remote rm origin
git remote add origin https://<username>@bitbucket.org/<username>/my-git-repo.git
@@ -4169,18 +4182,18 @@ To populate the remote repository with our existing code, we can use the
same push mechanism as with a centralized workflow. When prompted for a
password, use the one that you signed up with.
-``` k
+```k
git push origin master
```
## Browse the Public Repository (You) {#distributed-workflows.xhtml_browse-the-public-repository-you}
We should now be able to see our project on the Bitbucket site. The
-*Source* tab displays all of the files in the project, and the *Commits*
+_Source_ tab displays all of the files in the project, and the _Commits_
tab contains the entire commit history. Note that the branch structure
of the repository is also visualized to the left of each commit.
-
+
This repository now serves as the "official" copy of our example
website. We'll tell everyone else to download from this repository, and
@@ -4205,7 +4218,7 @@ of our hard work.
Fortunately, John knows how to exploit Bitbucket's collaboration
potential. He'll start by cloning a copy of our public repository:
-``` k
+```k
cd /path/to/my-git-repo
cd ..
git clone http://bitbucket.org/<username>/my-git-repo.git johns-repo
@@ -4213,11 +4226,11 @@ cd johns-repo
```
You should now have another copy of our repository called `johns-repo`
-in the same folder as `my-git-repo`. This is John's *private*
+in the same folder as `my-git-repo`. This is John's _private_
repository---a completely isolated environment where he can safely
develop the pink page. Let's quickly configure his name and email:
-``` k
+```k
git config user.name "John"
git config user.email john.example@rypress.com
```
@@ -4227,7 +4240,7 @@ git config user.email john.example@rypress.com
Of course, John should be developing his contributions in a dedicated
feature branch.
-``` k
+```k
git checkout -b pink-page
```
@@ -4238,7 +4251,7 @@ in. Then, we'll be able merge his content with minimal effort.
Create the file `pink.html` and add the following code:
-``` cp
+```cp
<!DOCTYPE html>
<html lang="en">
<head>
@@ -4258,7 +4271,7 @@ Create the file `pink.html` and add the following code:
Add the pink page to the "Navigation" section in `index.html`:
-``` nt
+```nt
<li style="color: #F0F">
<a href="pink.html">The Pink Page</a>
</li>
@@ -4266,7 +4279,7 @@ Add the pink page to the "Navigation" section in `index.html`:
Then, stage and commit the snapshot as normal.
-``` k
+```k
git add pink.html index.html
git status
git commit -m "Add pink page"
@@ -4275,30 +4288,30 @@ git commit -m "Add pink page"
## Publish the Pink Page (John) {#distributed-workflows.xhtml_publish-the-pink-page-john}
Now, John needs to publish his contributions to a public repository.
-Remember that we don't want him to push to *our* public repository,
-which is stored in his `origin` remote. In fact, he *can't* push to
+Remember that we don't want him to push to _our_ public repository,
+which is stored in his `origin` remote. In fact, he _can't_ push to
`origin` for reasons we'll discuss in a moment.
Instead, he'll create his own Bitbucket repository that we can pull
contributions from. In the real world, John would have his own Bitbucket
account, but for convenience, we'll just store his public repository
under our existing account. Once again, navigate to your Bitbucket home
-page and click *Repositories \> Create repository* to create John's
-public repository. For the *Name* field, use `johns-repo`.
+page and click _Repositories \> Create repository_ to create John's
+public repository. For the _Name_ field, use `johns-repo`.
-
+
Back in John's private repository, we'll need to add this as a remote:
-``` k
+```k
git remote add john-public https://<username>@bitbucket.org/<username>/johns-repo.git
```
This is where John will publish the pink page for us to access. Since
he's pushing with HTTPS, he'll need to enter the password for his
-Bitbucket account (which is actually the password for *your* account).
+Bitbucket account (which is actually the password for _your_ account).
-``` k
+```k
git push john-public pink-page
```
@@ -4330,7 +4343,7 @@ Ok, we're done being John and we're ready to integrate his code into the
official project. Let's start by switching back into our repository and
adding John's public repository as a remote.
-``` k
+```k
cd ../my-git-repo
git remote add john http://bitbucket.org/<username>/johns-repo.git
```
@@ -4340,7 +4353,7 @@ repository---the only thing that matters are his published changes.
Let's download his branches and take a look at what he's been working
on:
-``` k
+```k
git fetch john
git branch -r
git log master..john/pink-page --stat
@@ -4348,11 +4361,11 @@ git log master..john/pink-page --stat
We can visualize this history information as the following.
-
+
Let's take a look at his actual changes:
-``` k
+```k
git checkout john/pink-page
```
@@ -4367,7 +4380,7 @@ contributor.**
Assuming we approve John's updates, we're now ready to merge it into the
project.
-``` k
+```k
git checkout master
git merge john/pink-page
```
@@ -4376,7 +4389,7 @@ Notice that is the exact same way we incorporated Mary's changes in the
centralized workflow, except now we're pulling from and pushing to
different locations:
-
+
Furthermore, John's workflow is just like ours: develop in a local,
private repository, then push changes to the public one. The integrator
@@ -4390,7 +4403,7 @@ We've integrated John's contribution into our local `my-git-repo`
repository, but no one else knows what we've done. It's time to publish
our `master` branch again.
-``` k
+```k
git push origin master
```
@@ -4404,7 +4417,7 @@ Mary should now be pulling changes from our Bitbucket repository instead
of the central one from the previous module. This should be fairly easy
for her to configure.
-``` k
+```k
cd ../marys-repo
git remote rm origin
git remote add origin http://bitbucket.org/<username>/my-git-repo.git
@@ -4415,7 +4428,7 @@ username. For the sake of brevity, we'll do a blind merge to add John's
updates to Mary's repository (normally, Mary should check what she's
integrating before doing so).
-``` k
+```k
git checkout master
git fetch origin
git rebase origin/master
@@ -4428,12 +4441,12 @@ prompting her to synchronize her private repository.
## Update John's Repository (John) {#distributed-workflows.xhtml_update-johns-repository-john}
John still needs to incorporate the pink page into his `master` branch.
-He should *not* merge directly from his `pink-page` topic branch because
+He should _not_ merge directly from his `pink-page` topic branch because
we could have edited his contribution before publishing it or included
other contributions along with it. Instead, he'll pull from the
"official" `master`:
-``` k
+```k
cd ../johns-repo
git checkout master
git fetch origin
@@ -4442,11 +4455,11 @@ git rebase origin/master
If John had updated `master` directly from his local `pink-page`, it
could have wound up out-of-sync from the main project. For this reason,
-the integrator workflow requires that everyone *pull* from a single,
-official repository, while they all *push* to their own public
+the integrator workflow requires that everyone _pull_ from a single,
+official repository, while they all _push_ to their own public
repositories:
-
+
In this way, additions from one contributor can be approved, integrated,
and made available to everyone without interrupting anyone's independent
@@ -4471,11 +4484,11 @@ workflow creates a more stable development environment for open-source
software projects. Should the lead developer stop maintaining the
"official" repository, any of the other participants could take over by
simply designating their public repository as the new "official"
-project. This is part of what makes Git a *distributed* version control
+project. This is part of what makes Git a _distributed_ version control
system: there is no single central repository that Git forces everyone
to rely upon.
-
+
In the next module, we'll take a look at an even more flexible way to
share commits. This low-level approach will also give us a better
@@ -4487,13 +4500,14 @@ understanding of how Git internally manages our content.
:::::: {#patch-workflows.xhtml_page}
::::: {#patch-workflows.xhtml_content}
+
# Patch Workflows {#patch-workflows.xhtml_patch-workflows}
Thus far, all of the collaboration workflows we've seen rely heavily on
branches. For example, in the last module, a contributor had to publish
-an entire *branch* for us to merge into our project. However, it's also
-possible to communicate directly on the *commit* level using a
-***patch***.
+an entire _branch_ for us to merge into our project. However, it's also
+possible to communicate directly on the _commit_ level using a
+**_patch_**.
A patch file represents a single set of changes (i.e., a commit) that
can be applied to any branch, in any order. In this sense, the patch
@@ -4507,7 +4521,7 @@ Integrating on the commit level will also give us a deeper understanding
of how a Git repository records project history.
::: {.icon-text .download-icon-text}
-{style="max-width: 45px"}
+{style="max-width: 45px"}
[Download the repositories for this
module](http://rypress.com/tutorials/git/media/repo-zips/patch-workflows.zip)
@@ -4522,7 +4536,7 @@ repositories from the above link, uncompress them, and you're good to
go. If you've set up a Bitbucket account, you should also run the
following commands to configure the downloaded repositories:
-``` k
+```k
cd /path/to/my-git-repo
git remote add origin https://<username>@bitbucket.org/<username>/my-git-repo.git
cd ../marys-repo
@@ -4534,7 +4548,7 @@ git remote add origin http://bitbucket.org/<username>/my-git-repo.git
We'll begin by pretending to be Mary again. Mary didn't like the pink
page that John contributed and wants to change it.
-``` k
+```k
cd /path/to/marys-repo
git checkout -b pink-page
```
@@ -4543,20 +4557,20 @@ Developing in a new branch not only gives Mary an isolated environment,
it also makes it easier to create a series of patches once she's done
editing the pink page. Find these lines in `pink.html`:
-``` nt
+```nt
<p>Pink is <span style="color: #F0F">girly,
flirty and fun</span>!</p>
```
and change them to the following.
-``` nt
+```nt
<p>Only <span style="color: #F0F">real men</span> wear pink!</p>
```
Stage and commit the update as normal.
-``` k
+```k
git commit -a -m "Change pink to a manly color"
```
@@ -4570,7 +4584,7 @@ core Git concepts introduced in the first portion of this tutorial.
Mary can create a patch from the new commit using the `git format‑patch`
command.
-``` k
+```k
git format-patch master
```
@@ -4584,7 +4598,7 @@ the top of the file, it's actually a complete email. This makes it
incredibly easy to send patches to other developer. Further down, you
should see the following.
-``` gh
+```gh
index 98e10a1..828dd1a 100644
--- a/pink.html
+++ b/pink.html
@@ -4595,12 +4609,12 @@ index 98e10a1..828dd1a 100644
- <p>Pink is <span style="color: #F0F">girly,
- flirty and fun</span>!</p>
+ <p>Only <span style="color: #F0F">real men</span> wear pink!</p>
-
+
<p><a href="index.html">Return to home page</a></p>
</body>
```
-This unique formatting is called a ***diff***, because it shows the
+This unique formatting is called a **_diff_**, because it shows the
*diff*erence between two versions of a file. In our case, it tells us
what happened to the `pink.html` file between the `98e10a1` and
`828dd1a` commits (your patch will contain different commit ID's). The
@@ -4623,7 +4637,7 @@ more snapshot.
In `pink.html`, add the following on the line after the `<meta>` tag.
-``` nt
+```nt
<style>
div {
width: 300px;
@@ -4634,26 +4648,26 @@ In `pink.html`, add the following on the line after the `<meta>` tag.
And, add the next line of HTML after `Only real men wear pink!`:
-``` nt
+```nt
<div style="background-color: #F0F"></div>
```
Stage and commit the snapshot.
-``` k
+```k
git commit -a -m "Add a pink block of color"
```
Mary's repository now contains two commits after the tip of `master`:
-
+
## Create Patch of Entire Branch (Mary) {#patch-workflows.xhtml_create-patch-of-entire-branch-mary}
Mary can use the same command as before to generate patches for all the
commits in her `pink-page` branch.
-``` k
+```k
git format-patch master
```
@@ -4663,7 +4677,7 @@ the first line of the commit message will always be used to make a
descriptive filename for the patch. You should find the following diff
in the second patch.
-``` gh
+```gh
index 828dd1a..2713b10 100644
--- a/pink.html
+++ b/pink.html
@@ -4682,7 +4696,7 @@ index 828dd1a..2713b10 100644
<h1 style="color: #F0F">The Pink Page</h1>
<p>Only <span style="color: #F0F">real men</span> wear pink!</p>
+ <div style="background-color: #F0F"></div>
-
+
<p><a href="index.html">Return to home page</a></p>
</body>
```
@@ -4698,18 +4712,18 @@ Now that Mary has prepared a series of patches, she can send them to the
project maintainer (us). In the typical patch workflow, she would send
them via email using one of the following methods:
-- Copying and pasting the contents of the patch files into an email
- client. If she uses this method, Mary would have to make sure that
- her email application doesn't change the whitespace in the patch
- upon sending it.
-- Sending the patch file as an attachment to a normal email.
-- Using the convenient `git send-email` command and specifying a file
- or a directory of files to send. For example, `git send-email .`
- will send all the patches in the current directory. Git also
- requires some special configurations for this command. Please
- consult the [official Git
- documentation](http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html)
- for details.
+- Copying and pasting the contents of the patch files into an email
+ client. If she uses this method, Mary would have to make sure that
+ her email application doesn't change the whitespace in the patch
+ upon sending it.
+- Sending the patch file as an attachment to a normal email.
+- Using the convenient `git send-email` command and specifying a file
+ or a directory of files to send. For example, `git send-email .`
+ will send all the patches in the current directory. Git also
+ requires some special configurations for this command. Please
+ consult the [official Git
+ documentation](http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html)
+ for details.
The point is, the `.patch` files need to find their way into the Git
repository of whoever wants to add it to their project. For our example,
@@ -4722,7 +4736,7 @@ Copy the two patch files from `marys-repo` into `my-git-repo`. Using the
new `git am` command, we can use these patches to add Mary's commits to
our repository.
-``` k
+```k
cd ../my-git-repo
git checkout -b patch-integration
git am < 0001-Change-pink-to-a-manly-color.patch
@@ -4738,7 +4752,7 @@ author information.
Let's repeat the process for the second commit.
-``` k
+```k
git am < 0002-Add-a-pink-block-of-color.patch
git log master..HEAD --stat
```
@@ -4760,7 +4774,7 @@ as you please.
Once again, we're in the familiar situation of integrating a topic
branch into the stable `master` branch.
-``` k
+```k
git checkout master
git merge patch-integration
git branch -d patch-integration
@@ -4776,11 +4790,11 @@ developers can access the most up-to-date version of the project.
## Update Mary's Repository (Mary) {#patch-workflows.xhtml_update-marys-repository-mary}
Mary might be tempted to merge her `pink-page` branch directly into her
-`master` branch, but this would be a mistake. Her `master` branch *must*
+`master` branch, but this would be a mistake. Her `master` branch _must_
track the "official" repository's `master`, as discussed in the previous
module.
-``` k
+```k
cd ../marys-repo
git checkout master
git fetch origin
@@ -4791,7 +4805,7 @@ git clean -f
Patches are a convenient way to share commits amongst developers, but
the patch workflow still requires an "official" repository that contains
-*everybody's* changes. What would have happened if Mary wasn't the only
+_everybody's_ changes. What would have happened if Mary wasn't the only
one sending patches to us? We may very well have applied several
different patches or applied Mary's contributions in a different order.
Using Mary's `pink-page` to update her `master` branch would completely
@@ -4800,12 +4814,12 @@ ignore all these updates.
Taking this into consideration, our final patch workflow resembles the
following.
-
+
## Conclusion {#patch-workflows.xhtml_conclusion}
-Whereas remote repositories are a way to share entire *branches*,
-patches are a way to send individual *commits* to another developer.
+Whereas remote repositories are a way to share entire _branches_,
+patches are a way to send individual _commits_ to another developer.
Keep in mind that patches are usually only sent to a project maintainer,
who then integrates them into the "official" project for all to see. It
would be impossible for everyone to communicate using only patches, as
@@ -4835,12 +4849,12 @@ and introduce a variety of practical Git commands.
## Quick Reference {#patch-workflows.xhtml_quick-reference}
`git format-patch <branch-name>`
-: Create a patch for each commit contained in the current branch but
- not in `<branch-name>`. You can also specify a commit ID instead of
- `<branch-name>`.
+: Create a patch for each commit contained in the current branch but
+not in `<branch-name>`. You can also specify a commit ID instead of
+`<branch-name>`.
`git am < <patch-file>`
-: Apply a patch to the current branch.
+: Apply a patch to the current branch.
:::::
::::::
@@ -4848,6 +4862,7 @@ and introduce a variety of practical Git commands.
:::::: {#tips-and-tricks.xhtml_page}
::::: {#tips-and-tricks.xhtml_content}
+
# Tips & Tricks {#tips-and-tricks.xhtml_tips-tricks}
This module presents a broad survey of useful Git utilities. We'll take
@@ -4858,7 +4873,7 @@ of these miscellaneous tools, but rather to understand why they were
created and when they might come in handy.
::: {.icon-text .download-icon-text}
-{style="max-width: 45px"}
+{style="max-width: 45px"}
[Download the repositories for this
module](http://rypress.com/tutorials/git/media/repo-zips/tips-and-tricks.zip)
@@ -4877,13 +4892,13 @@ go.
First, let's export our repository into a ZIP archive. Run the following
command in your local copy of `my-git-repo`.
-``` k
+```k
git archive master --format=zip --output=../website-12-10-2012.zip
```
Or, for Unix users that would prefer a tarball:
-``` k
+```k
git archive master --format=tar --output=../website-12-10-2012.tar
```
@@ -4904,7 +4919,7 @@ into a single file. However, in this case, the file retains the
versioning information of the entire project. Try running the following
command.
-``` k
+```k
git bundle create ../repo.bundle master
```
@@ -4912,7 +4927,7 @@ It's like we just pushed our `master` branch to a remote, except it's
contained in a file instead of a remote repository. We can even clone it
using the same `git clone` command:
-``` k
+```k
cd ..
git clone repo.bundle repo-copy -b master
cd repo-copy
@@ -4949,7 +4964,7 @@ Let's see how this works by creating a file called `notes.txt` to store
some personal (private) comments about the project. Add some text to it
and save it, then run the following.
-``` k
+```k
git status
```
@@ -4960,7 +4975,7 @@ that starts with a period by executing the `touch .gitignore` command in
Git Bash (you should also make sure hidden files are visible in your
file browser).
-``` k
+```k
notes.txt
```
@@ -4968,7 +4983,7 @@ Run another `git status` and you'll see that the notes file no longer
appears under "Untracked files", but `.gitignore` does. This is a common
file for Git-based projects, so let's add it to the repository.
-``` k
+```k
git add .gitignore
git commit -m "Add .gitignore file"
git status
@@ -4990,7 +5005,7 @@ Next, we'll take a brief look at **stashing**, which conveniently
"stashes" away uncommitted changes. Open up `style.css` and change the
`h1` element to:
-``` nt
+```nt
h1 {
font-size: 32px;
font-family: "Times New Roman", serif;
@@ -5002,7 +5017,7 @@ want to commit an unfinished feature, and we also don't want to lose our
current CSS addition. The solution is to temporarily remove these
changes with the `git stash` command:
-``` k
+```k
git status
git stash
git status
@@ -5018,7 +5033,7 @@ Let's pretend we've completed our emergency update and we're ready to
continue working on our CSS changes. We can retrieve our stashed content
with the following command.
-``` k
+```k
git stash apply
```
@@ -5027,7 +5042,7 @@ we can continue development as if we were never interrupted. Whereas
patches represent a committed snapshot, a stash represents a set of
*un*committed changes. It takes the uncommitted modifications, stores
them internally, then does a `git reset --hard` to give us a clean
-working directory. This also means that stashes can be applied to *any*
+working directory. This also means that stashes can be applied to _any_
branch, not just the one from which it was created.
In addition to temporarily storing uncommitted changes, this makes
@@ -5038,7 +5053,7 @@ a `git stash apply`.
Let's undo these CSS updates before moving on.
-``` k
+```k
git reset --hard
```
@@ -5052,11 +5067,11 @@ to the `central-repo.git` repository.
In the `central-repo.git` directory, open the `hooks` directory and
rename the file `post-update.sample` to `post-update`. After removing
-the `.sample` extension, this script will be executed whenever *any*
+the `.sample` extension, this script will be executed whenever _any_
branch gets pushed to `central-repo.git`. Replace the default contents
of `post-update` with the following.
-``` c
+```c
#!/bin/sh
# Output a friendly message
@@ -5086,7 +5101,7 @@ our "live" website.
We can see the script in action by pushing a branch to the
`central-repo.git` repository.
-``` k
+```k
git push ../central-repo.git master
```
@@ -5120,14 +5135,14 @@ have been changed in any given file. For this level of detail, we need
the `git diff` command. Let's take a look at the updates from the
`Add a pink block of color` commit:
-``` k
+```k
git diff HEAD~2..HEAD~1
```
This will output the diff between the `Add a pink block of color` commit
(`HEAD~1`) and the one before it (`HEAD~2`):
-``` gh
+```gh
index 828dd1a..2713b10 100644
--- a/pink.html
+++ b/pink.html
@@ -5159,7 +5174,7 @@ have used the following to view the differences between John's
`pink-page` branch and our `master` before merging it into the project
in [Distributed Workflows](#distributed-workflows.xhtml).
-``` k
+```k
git diff master..john/pink-page
```
@@ -5167,7 +5182,7 @@ This flexible command can also generate a detailed view of our
uncommitted changes. Open up `blue.html`, make any kind of change, and
save the file. Then, run `git diff` without any arguments:
-``` k
+```k
git diff
```
@@ -5175,7 +5190,7 @@ And, just in case we forgot what was added to the staging area, we can
use the `--cached` flag to generate a diff between the staged snapshot
and the most recent commit:
-``` k
+```k
git add blue.html
git diff --cached
```
@@ -5194,12 +5209,12 @@ behavior of both commands.
The `git reset` we're accustomed to moves the current branch to a new
commit and optionally updates the working directory to match. But when
-we pass a file path, `git reset` updates the *staging area* to match the
+we pass a file path, `git reset` updates the _staging area_ to match the
given commit instead of the working directory, and it doesn't move the
current branch pointer. This means we can remove `blue.html` from the
staged snapshot with the following command.
-``` k
+```k
git reset HEAD blue.html
git status
```
@@ -5210,16 +5225,16 @@ The result is a staging area that matches the most recent commit and a
working directory that contains the modified `blue.html` file. In other
words, this type of `git reset` can be used to unstage a file:
-
+
Let's take this one step further with `git checkout`. The `git checkout`
-we've been using updates the working directory *and* switches branches.
+we've been using updates the working directory _and_ switches branches.
If we add a file path to `git checkout`, it narrows its focus to only
-the specified file and does *not* update the branch pointer. This means
+the specified file and does _not_ update the branch pointer. This means
that we can "check out" the most recent version of `blue.html` with the
following command.
-``` k
+```k
git checkout HEAD blue.html
git status
```
@@ -5228,7 +5243,7 @@ Our `blue.html` file now looks exactly like the version stored in
`HEAD`, and we thus have a clean working directory. Passing a file path
to `git checkout` reverts that file to the specified commit.
-
+
To summarize the file-path behavior of `git reset` and `git checkout`,
both take a committed snapshot as an reference point and make a file in
@@ -5242,7 +5257,7 @@ last ten modules has been a bit verbose. Fortunately, Git lets you
create **aliases**, which are shortcuts to other commands. Let's create
a few aliases for our most common commands:
-``` k
+```k
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.br branch
@@ -5302,7 +5317,7 @@ clearer picture of Git's numerous capabilities.
With all of these convenient features, it's easy to get so caught up in
designing the perfect workflow that you lose sight of Git's underlying
purpose. As you add new commands to your repertoire, remember that Git
-should always make it *easier* to develop a software project---never
+should always make it _easier_ to develop a software project---never
harder. If you ever find that Git is causing more harm than good, don't
be scared to drop some of the advanced features and go back to the
basics.
@@ -5316,44 +5331,44 @@ the reality of Git-based project management.
## Quick Reference {#tips-and-tricks.xhtml_quick-reference}
`git archive <branch-name> --format=zip --output=<file>`
-: Export a single snapshot to a ZIP archive called `<file>`.
+: Export a single snapshot to a ZIP archive called `<file>`.
`git bundle create <file> <branch-name>`
-: Export an entire branch, complete with history, to the specified
- file.
+: Export an entire branch, complete with history, to the specified
+file.
`git clone repo.bundle <repo-dir> -b <branch-name>`
-: Re-create a project from a bundled repository and checkout
- `<branch‑name>`.
+: Re-create a project from a bundled repository and checkout
+`<branch‑name>`.
`git stash`
-: Temporarily stash changes to create a clean working directory.
+: Temporarily stash changes to create a clean working directory.
`git stash apply`
-: Re-apply stashed changes to the working directory.
+: Re-apply stashed changes to the working directory.
`git diff <commit-id>..<commit-id>`
-: View the difference between two commits.
+: View the difference between two commits.
`git diff`
-: View the difference between the working directory and the staging
- area.
+: View the difference between the working directory and the staging
+area.
`git diff --cached`
-: View the difference between the staging area and the most recent
- commit.
+: View the difference between the staging area and the most recent
+commit.
`git reset HEAD <file>`
-: Unstage a file, but don't alter the working directory or move the
- current branch.
+: Unstage a file, but don't alter the working directory or move the
+current branch.
`git checkout <commit-id> <file>`
-: Revert an individual file to match the specified commit without
- switching branches.
+: Revert an individual file to match the specified commit without
+switching branches.
`git config --global alias.<alias-name> <git-command>`
-: Create a shortcut for a command and store it in the global
- configuration file.
+: Create a shortcut for a command and store it in the global
+configuration file.
:::::
::::::
@@ -5361,6 +5376,7 @@ the reality of Git-based project management.
:::::: {#plumbing.xhtml_page}
::::: {#plumbing.xhtml_content}
+
# Plumbing {#plumbing.xhtml_plumbing}
In [Rewriting History](#rewriting-history.xhtml), I talked about the
@@ -5369,7 +5385,7 @@ bit. While the reflog, interactive rebasing, and resetting may be more
complex features of Git, they are still considered part of the
**porcelain**, as is every other command we've covered. In this module,
we'll take a look at Git's **plumbing**---the low-level commands that
-give us access to Git's *true* internal representation of a project.
+give us access to Git's _true_ internal representation of a project.
Unless you start hacking on Git's source code, you'll probably never
need to use the plumbing commands presented below. But, manually
@@ -5383,7 +5399,7 @@ We'll start by inspecting Git's object database, then we'll manually
create and commit a snapshot using only Git's low-level interface.
::: {.icon-text .download-icon-text}
-{style="max-width: 45px"}
+{style="max-width: 45px"}
[Download the repository for this
module](http://rypress.com/tutorials/git/media/repo-zips/plumbing.zip)
@@ -5401,7 +5417,7 @@ from the above link, uncompress it, and you're good to go.
First, let's take a closer look at our latest commit with the
`git cat-file` plumbing command.
-``` k
+```k
git cat-file commit HEAD
```
@@ -5419,7 +5435,7 @@ be different.
This is the complete representation of a commit: a tree, a parent, user
data, and a commit message. The user information and commit message are
-relatively straightforward, but we've never seen the *tree* or *parent*
+relatively straightforward, but we've never seen the _tree_ or _parent_
values before.
A **tree object** is Git's representation of the "snapshots" we've been
@@ -5430,7 +5446,7 @@ each one in a **commit object** and specifies a **parent**, which is
just another commit. By following the parent of each commit, you can
walk through the entire history of a project.
-
+
Notice that each commit refers to one and only one tree object. From the
`git cat-file` output, we can also infer that trees use SHA-1 checksums
@@ -5442,7 +5458,7 @@ Next, let's try to inspect a tree using the same `git cat-file` command.
Make sure to change `552acd4` to the ID of your tree from the previous
step.
-``` k
+```k
git cat-file tree 552acd4
```
@@ -5450,7 +5466,7 @@ Unfortunately, trees contain binary data, which is quite ugly when
displayed in its raw form. So, Git offers another useful plumbing
command:
-``` k
+```k
git ls-tree 552acd4
```
@@ -5477,22 +5493,22 @@ objects tie trees into a project history. These are the only types of
objects that Git needs to implement nearly all of the porcelain commands
we've been using, and their relationship is summed up as follows:
-
+
## Examine a Blob {#plumbing.xhtml_examine-a-blob}
Let's take a look at the blob associated with `blue.html` (be sure to
-change the following to the ID next to `blue.html` in *your* tree
+change the following to the ID next to `blue.html` in _your_ tree
output).
-``` k
+```k
git cat-file blob cefb5a6
```
This should display the entire contents of `blue.html`, confirming that
blobs really are plain data files. Note that blobs are pure content:
there is no mention of a filename in the above output. That is to say,
-the name `blue.html` is stored in the *tree that contains the blob*, not
+the name `blue.html` is stored in the _tree that contains the blob_, not
the blob itself.
You may recall from [The Basics](#the-basics.xhtml) that an SHA-1
@@ -5503,7 +5519,7 @@ identifier, it also guarantees that an object won't be silently
corrupted (the altered content would generate a different ID).
When it comes to blob objects, this has an additional benefit. Since two
-blobs with the same data will have the same ID, Git *must* share blobs
+blobs with the same data will have the same ID, Git _must_ share blobs
across multiple trees. For example, our `blue.html` file hasn't been
changed since it was created, so our repository will only have a single
associated blob, and all subsequent trees will refer to it. By not
@@ -5511,7 +5527,7 @@ creating duplicate blobs for each tree object, Git vastly reduces the
size of a repository. With this in mind, we can revise our Git object
diagram to the following.
-
+
However, as soon as you change a single line in a file, Git must create
a new blob object because its contents will have changed, resulting in a
@@ -5522,7 +5538,7 @@ new SHA-1 checksum.
The fourth and final type of Git object is the **tag object** We can use
the same `git cat-file` command to show the details of a tag.
-``` k
+```k
git cat-file tag v2.0
```
@@ -5531,7 +5547,7 @@ tag's name, author, creation date, and message. The straightforward
relationship between tags and commits gives us our finalized Git object
diagram:
-
+
## Inspect Git's Branch Representation {#plumbing.xhtml_inspect-gits-branch-representation}
@@ -5539,14 +5555,14 @@ We now have the tools to fully explore Git's branch representation.
Using the `-t` flag, we can determine what kind of object Git uses for
branches.
-``` k
+```k
git cat-file -t master
```
That's right, a branch is just a reference to a commit object, which
means we can view it with a normal `git cat-file`.
-``` k
+```k
git cat-file commit master
```
@@ -5568,7 +5584,7 @@ occurred when `HEAD` did not coincide with the tip of any branch.
Internally, all this means to Git is that `.git/HEAD` doesn't contain a
local branch. Try checking out an old commit:
-``` k
+```k
git checkout HEAD~1
```
@@ -5579,7 +5595,7 @@ checked-out reference in `.git/HEAD`.
Let's get back to our `master` branch before moving on:
-``` k
+```k
git checkout master
```
@@ -5612,16 +5628,16 @@ is stored in a folder called `7a`, using the remaining characters
can inspect items in the object database, we need to know what type of
object it is. Again, we can use the `-t` flag:
-``` k
+```k
git cat-file -t 7a52bb8
```
-Of course, change the object ID to an object from *your* database (don't
+Of course, change the object ID to an object from _your_ database (don't
forget to combine the folder name with the filename to get the full ID).
This will output the type of commit, which we can then pass to a normal
call to `git cat-file`.
-``` k
+```k
git cat-file blob 7a52bb8
```
@@ -5638,7 +5654,7 @@ command is undo-able. If you want to continue exploring the contents of
the `.git/objects` folder, you should do so before running the following
command. Normal Git functionality will not be affected.
-``` k
+```k
git gc
```
@@ -5662,7 +5678,7 @@ the staging area.
Create a new file called `news-4.html` in `my-git-repo` and add the
following HTML.
-``` cp
+```cp
<!DOCTYPE html>
<html lang="en">
<head>
@@ -5675,7 +5691,7 @@ following HTML.
<p>Last week, a coalition of Asian designers, artists,
and advertisers announced the official color of Asia:
<span style="color: #A0C">Indigo</span>.</p>
-
+
<p><a href="index.html">Return to home page</a></p>
</body>
</html>
@@ -5683,7 +5699,7 @@ following HTML.
Then, update the `index.html` "News" section to match the following.
-``` nt
+```nt
<h2 style="color: #C00">News</h2>
<ul>
<li><a href="news-1.html">Blue Is The New Hue</a></li>
@@ -5698,7 +5714,7 @@ Instead of `git add`, we'll use the low-level `git update-index` command
to add files to the staging area. The **index** is Git's term for the
staged snapshot.
-``` k
+```k
git status
git update-index index.html
git update-index news-4.html
@@ -5707,7 +5723,7 @@ git update-index news-4.html
The last command will throw an error---Git won't let you add a new file
to the index without explicitly stating that it's a new file:
-``` k
+```k
git update-index --add news-4.html
git status
```
@@ -5723,7 +5739,7 @@ snapshot for that commit. So, before creating a commit object, we need
to add our index (the staged tree) to Git's object database. We can do
this with the following command.
-``` k
+```k
git write-tree
```
@@ -5738,7 +5754,7 @@ the only new blobs created for this commit were `index.html` and
`news-4.html`. The rest of the tree contains references to existing
blobs.
-``` k
+```k
git ls-tree 5f44809
```
@@ -5750,7 +5766,7 @@ history.
To commit the new tree object, we need to manually figure out the ID of
the parent commit.
-``` k
+```k
git log --oneline -n 1
```
@@ -5758,7 +5774,7 @@ This will output the following line, though your commit ID will be
different. We'll use this ID to specify the parent of our new commit
object.
-``` s
+```s
3329762 Add .gitignore file
```
@@ -5767,7 +5783,7 @@ parent ID, while the author information is taken from an environment
variable set by Git. Make sure to change `5f44809` to your tree ID, and
`3329762` to your most recent commit ID.
-``` k
+```k
git commit-tree 5f44809 -p 3329762
```
@@ -5781,10 +5797,10 @@ command, this will output the ID of the resulting commit object.
You'll now be able to find this commit in `.git/objects`, but neither
`HEAD` nor the branches have been updated to include this commit. It's a
-*dangling commit* at this point. Fortunately for us, we know where Git
+_dangling commit_ at this point. Fortunately for us, we know where Git
stores its branch information.
-
+
## Update HEAD {#plumbing.xhtml_update-head}
@@ -5803,7 +5819,7 @@ it.
Now that our `master` branch points to the new commit, we should be able
to see the `news-4.html` file in the project history.
-``` k
+```k
git log -n 2
```
@@ -5811,7 +5827,7 @@ The last four sections explain everything that happens behind the scenes
when we execute `git commit -a -m "Some Message"`. Aren't you glad you
won't have to use Git's plumbing ever again?
-
+
## Conclusion {#plumbing.xhtml_conclusion}
@@ -5847,28 +5863,28 @@ us](http://rypress.com/about).
## Quick Reference {#plumbing.xhtml_quick-reference}
`git cat-file <type> <object-id>`
-: Display the specified object, where `<type>` is one of `commit`,
- `tree`, `blob`, or `tag`.
+: Display the specified object, where `<type>` is one of `commit`,
+`tree`, `blob`, or `tag`.
`git cat-file -t <object-id>`
-: Output the type of the specified object.
+: Output the type of the specified object.
`git ls-tree <tree-id>`
-: Display a pretty version of the specified tree object.
+: Display a pretty version of the specified tree object.
`git gc`
-: Perform a garbage collection on the object database.
+: Perform a garbage collection on the object database.
`git update-index [--add] <file>`
-: Stage the specified file, using the optional `--add` flag to denote
- a new untracked file.
+: Stage the specified file, using the optional `--add` flag to denote
+a new untracked file.
`git write-tree`
-: Generate a tree from the index and store it in the object database.
- Returns the ID of the new tree object.
+: Generate a tree from the index and store it in the object database.
+Returns the ID of the new tree object.
`git commit-tree <tree-id> -p <parent-id>`
-: Create a new commit object from the given tree object and parent
- commit. Returns the ID of the new commit object.
+: Create a new commit object from the given tree object and parent
+commit. Returns the ID of the new commit object.
:::::
::::::
diff --git a/images/0-1.png b/images/0-1.png
new file mode 100644
index 0000000..1a0338c
Binary files /dev/null and b/images/0-1.png differ
diff --git a/images/0-2.png b/images/0-2.png
new file mode 100644
index 0000000..c51eaa6
Binary files /dev/null and b/images/0-2.png differ
diff --git a/images/0-3.png b/images/0-3.png
new file mode 100644
index 0000000..525c39e
Binary files /dev/null and b/images/0-3.png differ
diff --git a/images/0-4.png b/images/0-4.png
new file mode 100644
index 0000000..b7051c7
Binary files /dev/null and b/images/0-4.png differ
diff --git a/images/1-1.png b/images/1-1.png
new file mode 100644
index 0000000..051e33c
Binary files /dev/null and b/images/1-1.png differ
diff --git a/images/1-2.png b/images/1-2.png
new file mode 100644
index 0000000..572f401
Binary files /dev/null and b/images/1-2.png differ
diff --git a/images/1-3.png b/images/1-3.png
new file mode 100644
index 0000000..41d38e5
Binary files /dev/null and b/images/1-3.png differ
diff --git a/images/1-4.png b/images/1-4.png
new file mode 100644
index 0000000..217c519
Binary files /dev/null and b/images/1-4.png differ
diff --git a/images/1-5.png b/images/1-5.png
new file mode 100644
index 0000000..36bcdb1
Binary files /dev/null and b/images/1-5.png differ
diff --git a/images/10-1.png b/images/10-1.png
new file mode 100644
index 0000000..69214fc
Binary files /dev/null and b/images/10-1.png differ
diff --git a/images/10-2.png b/images/10-2.png
new file mode 100644
index 0000000..e77f4f6
Binary files /dev/null and b/images/10-2.png differ
diff --git a/images/11-1.png b/images/11-1.png
new file mode 100644
index 0000000..9c1f29d
Binary files /dev/null and b/images/11-1.png differ
diff --git a/images/11-2.png b/images/11-2.png
new file mode 100644
index 0000000..beccbb8
Binary files /dev/null and b/images/11-2.png differ
diff --git a/images/12-1.png b/images/12-1.png
new file mode 100644
index 0000000..38a7591
Binary files /dev/null and b/images/12-1.png differ
diff --git a/images/12-2.png b/images/12-2.png
new file mode 100644
index 0000000..8b7790a
Binary files /dev/null and b/images/12-2.png differ
diff --git a/images/12-3.png b/images/12-3.png
new file mode 100644
index 0000000..aac7a6a
Binary files /dev/null and b/images/12-3.png differ
diff --git a/images/12-4.png b/images/12-4.png
new file mode 100644
index 0000000..b259841
Binary files /dev/null and b/images/12-4.png differ
diff --git a/images/12-5.png b/images/12-5.png
new file mode 100644
index 0000000..e22b95d
Binary files /dev/null and b/images/12-5.png differ
diff --git a/images/12-6.png b/images/12-6.png
new file mode 100644
index 0000000..6790c0d
Binary files /dev/null and b/images/12-6.png differ
diff --git a/images/2-1.png b/images/2-1.png
new file mode 100644
index 0000000..c19d342
Binary files /dev/null and b/images/2-1.png differ
diff --git a/images/2-2.png b/images/2-2.png
new file mode 100644
index 0000000..1edc179
Binary files /dev/null and b/images/2-2.png differ
diff --git a/images/2-3.png b/images/2-3.png
new file mode 100644
index 0000000..217c519
Binary files /dev/null and b/images/2-3.png differ
diff --git a/images/2-4.png b/images/2-4.png
new file mode 100644
index 0000000..228d76d
Binary files /dev/null and b/images/2-4.png differ
diff --git a/images/2-5.png b/images/2-5.png
new file mode 100644
index 0000000..dd287f1
Binary files /dev/null and b/images/2-5.png differ
diff --git a/images/3-1.png b/images/3-1.png
new file mode 100644
index 0000000..6e7ab37
Binary files /dev/null and b/images/3-1.png differ
diff --git a/images/3-10.png b/images/3-10.png
new file mode 100644
index 0000000..b2144ae
Binary files /dev/null and b/images/3-10.png differ
diff --git a/images/3-11.png b/images/3-11.png
new file mode 100644
index 0000000..dc9e4fa
Binary files /dev/null and b/images/3-11.png differ
diff --git a/images/3-12.png b/images/3-12.png
new file mode 100644
index 0000000..06ab52b
Binary files /dev/null and b/images/3-12.png differ
diff --git a/images/3-2.png b/images/3-2.png
new file mode 100644
index 0000000..364e901
Binary files /dev/null and b/images/3-2.png differ
diff --git a/images/3-3.png b/images/3-3.png
new file mode 100644
index 0000000..1f692ce
Binary files /dev/null and b/images/3-3.png differ
diff --git a/images/3-4.png b/images/3-4.png
new file mode 100644
index 0000000..c31297b
Binary files /dev/null and b/images/3-4.png differ
diff --git a/images/3-5.png b/images/3-5.png
new file mode 100644
index 0000000..3431a8b
Binary files /dev/null and b/images/3-5.png differ
diff --git a/images/3-6.png b/images/3-6.png
new file mode 100644
index 0000000..be7d2c0
Binary files /dev/null and b/images/3-6.png differ
diff --git a/images/3-7.png b/images/3-7.png
new file mode 100644
index 0000000..af50e84
Binary files /dev/null and b/images/3-7.png differ
diff --git a/images/3-8.png b/images/3-8.png
new file mode 100644
index 0000000..cb40898
Binary files /dev/null and b/images/3-8.png differ
diff --git a/images/3-9.png b/images/3-9.png
new file mode 100644
index 0000000..95fa08c
Binary files /dev/null and b/images/3-9.png differ
diff --git a/images/4-1.png b/images/4-1.png
new file mode 100644
index 0000000..850528e
Binary files /dev/null and b/images/4-1.png differ
diff --git a/images/4-2.png b/images/4-2.png
new file mode 100644
index 0000000..4dde48d
Binary files /dev/null and b/images/4-2.png differ
diff --git a/images/4-3.png b/images/4-3.png
new file mode 100644
index 0000000..99c1ee0
Binary files /dev/null and b/images/4-3.png differ
diff --git a/images/4-4.png b/images/4-4.png
new file mode 100644
index 0000000..f0badff
Binary files /dev/null and b/images/4-4.png differ
diff --git a/images/4-5.png b/images/4-5.png
new file mode 100644
index 0000000..a509db1
Binary files /dev/null and b/images/4-5.png differ
diff --git a/images/4-6.png b/images/4-6.png
new file mode 100644
index 0000000..fd0b5d6
Binary files /dev/null and b/images/4-6.png differ
diff --git a/images/5-1.png b/images/5-1.png
new file mode 100644
index 0000000..362928b
Binary files /dev/null and b/images/5-1.png differ
diff --git a/images/5-2.png b/images/5-2.png
new file mode 100644
index 0000000..79f6b98
Binary files /dev/null and b/images/5-2.png differ
diff --git a/images/5-3.png b/images/5-3.png
new file mode 100644
index 0000000..23511fb
Binary files /dev/null and b/images/5-3.png differ
diff --git a/images/5-4.png b/images/5-4.png
new file mode 100644
index 0000000..8aa067a
Binary files /dev/null and b/images/5-4.png differ
diff --git a/images/5-5.png b/images/5-5.png
new file mode 100644
index 0000000..2d09dd5
Binary files /dev/null and b/images/5-5.png differ
diff --git a/images/5-6.png b/images/5-6.png
new file mode 100644
index 0000000..a2e1587
Binary files /dev/null and b/images/5-6.png differ
diff --git a/images/5-7.png b/images/5-7.png
new file mode 100644
index 0000000..4cb6e99
Binary files /dev/null and b/images/5-7.png differ
diff --git a/images/6-1.png b/images/6-1.png
new file mode 100644
index 0000000..85270a5
Binary files /dev/null and b/images/6-1.png differ
diff --git a/images/6-2.png b/images/6-2.png
new file mode 100644
index 0000000..c332464
Binary files /dev/null and b/images/6-2.png differ
diff --git a/images/6-3.png b/images/6-3.png
new file mode 100644
index 0000000..8578581
Binary files /dev/null and b/images/6-3.png differ
diff --git a/images/6-4.png b/images/6-4.png
new file mode 100644
index 0000000..085e80b
Binary files /dev/null and b/images/6-4.png differ
diff --git a/images/6-5.png b/images/6-5.png
new file mode 100644
index 0000000..e600357
Binary files /dev/null and b/images/6-5.png differ
diff --git a/images/6-6.png b/images/6-6.png
new file mode 100644
index 0000000..0e08e2f
Binary files /dev/null and b/images/6-6.png differ
diff --git a/images/6-7.png b/images/6-7.png
new file mode 100644
index 0000000..338a7f9
Binary files /dev/null and b/images/6-7.png differ
diff --git a/images/7-1.png b/images/7-1.png
new file mode 100644
index 0000000..a89b8b7
Binary files /dev/null and b/images/7-1.png differ
diff --git a/images/7-2.png b/images/7-2.png
new file mode 100644
index 0000000..1208f4d
Binary files /dev/null and b/images/7-2.png differ
diff --git a/images/7-3.png b/images/7-3.png
new file mode 100644
index 0000000..94c4d3f
Binary files /dev/null and b/images/7-3.png differ
diff --git a/images/7-4.png b/images/7-4.png
new file mode 100644
index 0000000..140647b
Binary files /dev/null and b/images/7-4.png differ
diff --git a/images/7-5.png b/images/7-5.png
new file mode 100644
index 0000000..24fde75
Binary files /dev/null and b/images/7-5.png differ
diff --git a/images/7-6.png b/images/7-6.png
new file mode 100644
index 0000000..664b37d
Binary files /dev/null and b/images/7-6.png differ
diff --git a/images/7-7.png b/images/7-7.png
new file mode 100644
index 0000000..37e6be6
Binary files /dev/null and b/images/7-7.png differ
diff --git a/images/8-1.png b/images/8-1.png
new file mode 100644
index 0000000..4ec17fd
Binary files /dev/null and b/images/8-1.png differ
diff --git a/images/8-2.png b/images/8-2.png
new file mode 100644
index 0000000..2c3725e
Binary files /dev/null and b/images/8-2.png differ
diff --git a/images/8-3.png b/images/8-3.png
new file mode 100644
index 0000000..190e582
Binary files /dev/null and b/images/8-3.png differ
diff --git a/images/8-4.png b/images/8-4.png
new file mode 100644
index 0000000..aa67c8c
Binary files /dev/null and b/images/8-4.png differ
diff --git a/images/8-5.png b/images/8-5.png
new file mode 100644
index 0000000..a49a8c1
Binary files /dev/null and b/images/8-5.png differ
diff --git a/images/8-6.png b/images/8-6.png
new file mode 100644
index 0000000..5b09a0a
Binary files /dev/null and b/images/8-6.png differ
diff --git a/images/8-7.png b/images/8-7.png
new file mode 100644
index 0000000..d5f4d2d
Binary files /dev/null and b/images/8-7.png differ
diff --git a/images/9-1.png b/images/9-1.png
new file mode 100644
index 0000000..fe8678b
Binary files /dev/null and b/images/9-1.png differ
diff --git a/images/9-10.png b/images/9-10.png
new file mode 100644
index 0000000..d2c3aaa
Binary files /dev/null and b/images/9-10.png differ
diff --git a/images/9-11.png b/images/9-11.png
new file mode 100644
index 0000000..c15cf25
Binary files /dev/null and b/images/9-11.png differ
diff --git a/images/9-4.png b/images/9-4.png
new file mode 100644
index 0000000..70aad89
Binary files /dev/null and b/images/9-4.png differ
diff --git a/images/9-5.png b/images/9-5.png
new file mode 100644
index 0000000..e52e8a4
Binary files /dev/null and b/images/9-5.png differ
diff --git a/images/9-6.png b/images/9-6.png
new file mode 100644
index 0000000..f30e289
Binary files /dev/null and b/images/9-6.png differ
diff --git a/images/9-7.png b/images/9-7.png
new file mode 100644
index 0000000..591f4b9
Binary files /dev/null and b/images/9-7.png differ
diff --git a/images/9-8.png b/images/9-8.png
new file mode 100644
index 0000000..d7458c3
Binary files /dev/null and b/images/9-8.png differ
diff --git a/images/9-9.png b/images/9-9.png
new file mode 100644
index 0000000..fe8678b
Binary files /dev/null and b/images/9-9.png differ
diff --git a/images/bitbucket-logo.png b/images/bitbucket-logo.png
new file mode 100644
index 0000000..00bee2d
Binary files /dev/null and b/images/bitbucket-logo.png differ
diff --git a/images/cover-art.png b/images/cover-art.png
new file mode 100644
index 0000000..9f8d9f7
Binary files /dev/null and b/images/cover-art.png differ
diff --git a/images/icons/download.png b/images/icons/download.png
new file mode 100644
index 0000000..c2562fd
Binary files /dev/null and b/images/icons/download.png differ