This is an extremely short read. While it provided everything expected, it is
still quite the crash course. There is enough to get you started, but that is
all. You'll need to follow up if you are doing more than the most basic of
operations. That said, it was a great introduction to whet you appetite.
The book follows the typical introductory tech book format: first an
explanation of version control is given, using a basic example of saving
multiple copies of a file with different (dated) names. Git, as the author
states multiple times, is simply a more complex, and powerful, way of doing
Apparently Git also provides a very low level of abstraction and doesn't hide
much, which can be a blessing or a curse depending on your perspective. What is
nice is that Git won't do anything unless you explicitly tell it to.
From here it moves through the most basic commands: init, clone, status, add,
and commit. These should cover most of your day-to-day use claims the author.
With my minimal understanding of Git, using it only locally, I can mostly
Next branches are covered, but it an high level fashion. There is no concrete
tutorial like examples. Instead you get advice like: branches should, although
there are no hard and fast rules, contain topics; you shouldn't let your master
and topic branches get too far apart; you should merge the master into topic or
vice versa to keep them reasonably up to date.
That said, some teams use branches differently. One team may say: everything on
master is deployable. Another might have release branches while master is
cutting edge and less tested.
Merging is covered, also in high level detail. When merging a commit is made
automatically, but you can override this to customize the message, but that is
probably not necessary. The dreaded merge conflict and their resolution is
touched on, again in high level.
Remote repositories are covered, but, like the other coverage, only in the most
basic fashion. There is a good explanation of SSH and HTTPS remote access and
there is a simple discussion of the basic remote commands: push, pull, fetch.
While it mentions that anyone can easily set up their own private remote, there
are no details on how to do this. It does belabor that SSH will be read and
write access, while HTTP can allow for only read access (or read/write).
Lastly how to look through the history with the log command is covered. Again,
little detail beyond formatting is looked at.
Overall I'd say it is a worthwhile read, although there is nothing but the most
basics here. If you want to learn more, there are several references to more
detailed books and tutorials provided.
Scott Chacon’s excellent reference book Pro Git
Tim Pope’s “A Note About Git Commit Messages”
Chris Beams’s “How To Write A Git Commit Message”
Atlassian’s Git tutorials
Table of Contents
01: Thinking in Versions
- // Pages numbers from the actual book.
- you can tell git checkout to create and switch to a new branch at the same
time by passing in the -b option, like so:
(master) $: git checkout -b new-homepage
Switched to a new branch 'new-homepage'
- Once the merged snapshot has been automatically generated, by default Git
seals the deal and commits it for you, with an automatically generated commit
message: “Merge branch ‘update-contact-info’ into master.” This is only a
default, of course: you can pass the –no-commit option to git merge to ask Git
just to generate and stage the merged-together version of your work, but wait
for you to commit it yourself. One reason you might do this is to craft your
own commit message
- So, from time to time, you’ll want to merge new commits from master into your
branch to bring it back up to date:
(new-homepage) $: git merge master
Makefile | 7 ++
Rakefile | 15 ++--
- Ideally, the final state of each working branch should differ from master
only in ways that are relevant to its topic.
- The goal of keeping master and topic branches up to date with each other
isn’t to prevent conflicts, but rather to make conflicts easier to manage by
keeping the differences between two branches small.
- Server-side repos are what are called “bare” repos, consisting only of the
actual repository data (old versions, branches) and no working copy (which also
means no staging area). A directory containing a bare Git repo is usually
marked by appending .git to its name,
Git’s SSH protocol is the exact same one many of us use to log in to remote
servers every day. In fact, any SSH server you have access to can probably be
used as a host for remote Git repositories. SSH remotes support both reading
and writing, and you can use any authentication method SSH supports.
Whereas SSH must be private, and must allow read and
write access to your repositories, HTTPS offers more flexibility. You
can allow anyone on the internet to pull down changes from your repo, while
restricting push access to members of your own team.
- It’s important to remember that merging is implicitly part of pulling (and,
for that matter, pushing). Or, to flip it around, it’s helpful to remember that
both pushing and pulling are the remote form of merging. Both commands do the
exact same job: they move a branch to another computer, then merge it into
- always pull before you push to make sure your own
local copy is up to date. There’s rarely any harm to pulling changes,
and frequently lots of benefit.
- The simplest way to set up a tracking relationship is to include the
--set-upstream (or -u) option when invoking git push.
Although by default the git branch command will only tell you what branches
exist on your local copy, you can give it the --remote (-r) flag to ask it to
instead show you all of the branches Git knows about from your remotes
git pull origin master is, in fact, just a shortcut for a git fetch, followed
by git merge origin/master.
- The --pretty option allowsyou to select from a number of predefined formats,
or specify your own using a format string. Here’s the built-in oneline format,
which shows only the commit ID and log message on a single line:
$: git log --pretty=oneline
45b1ec87cd2fde95a110dfe3028e93d25c9af186 Rename styles.css to main.css
bf8144d4690d3f6052dc7f42135e3e9944b96b5a Initial commit
- This is best for seeing a list of what differs in a topic branch since we
branched off. Here, we’ll ask git log to show all the commits that have been
added to new-homepage that aren’t yet merged into master, using the --oneline
option to make the log output easier to scan:
$: git log --oneline master..new-homepage
bce44eb Bigger navigation buttons
056c8fd Update hero area w/ new background image
7e53652 Make font loading async
Our range is listed here as start..end, or rather, olderbranch..newerbranch
The simplest way to explain what git log branch-a..branch-b does is that it
shows you a list of all the commits in branch-b that aren’t in branch-a. In the
previous example, we see three commits from new-homepage that aren’t yet merged
What’s really cool is that we can ask git log to show us a list the other way
around—to give us a list of commits in master that aren’t in new-homepage:
$: git log --oneline new-homepage..master
4af326c Support for Microsoft Edge