Git What is Git?

The Problems with Git that You’re Likely to Encounter at First

You’ll make notes about what Git is, how it works, and how to use it. But as you build your knowledge, parts of it will evolve-as you have epiphanies.

You’ll execute Git commands, thinking that because they have the name names as the old system, that they do pretty much the same things – but they actually do quite different things. And Git commands produce different results depending on the context.

For example, you’ll spend three months thinking that git checkout is just like a Source Depot checkout, without really knowing what git checkout does. Here’s the difference:

You can switch to any branch just by changing the commit that HEAD points to. In Git, you use the “Checkout” command to switch branches (which is confusing for CVCS users, because it doesn’t mean what you think).

You’ll try to branch the Source Depot way, and you’ll get confused because it produces inexplicable results, and it didn’t work so well because you really should have been branching the Git way – by cloning repositories, not by trying to do the things that work in Source Depot.

In GitHub (an online Git host), the term “Fork” is used to refer to a clone of a repository – cloned under your account on GitHub. This is confusing because you’re apt to think of a fork as just another branch. You use Fork when you work on a project that you don’t have permission to write to. To Push your changes up to Origin, you issue a Pull Request (which gets someone with write permissions to integrate your changes into the mainline).


What exactly are Git Commands?

Git cammands do one of three things:

  • Add files and directories to the staging area.

  • Build commits (a new node in the graph).

  • Move labels from one node to another.

    • E.g., git checkout feature.
    • When you type “git commit”, you’re just moving the label for that branch to the node Git created when you staged content (HEAD now point to INDEX).

Git refers to a label as a reference. References make commits reachable (like address pointers). Local branch references move when you perform commands like “git commit”, “git merge”, “git rebase”, “git reset”. Remote branch references move when you perform commands like “git push”. Think of a branch as a time-line (alternate universes).


Experimentation Strategy

Before you attempt a Git operation…

  1. Create a new branch (like you would a saved game).
  2. Start gitK – so you can see the current state of the branch visually.
  3. Make your change (perform the operation).
  4. Before you refresh gitK, try to guess at what the change will look like.
  5. Run gitK and check the result.
Git What is Git?

The Git Repository

Git manages repositories as a data structure layered on top of the file system. In Git, you think about changesets, also known as commits. A changeset means conceptually different things on different levels (and this trips-up newbs). A change set is a:

  • Concise list of the changes between one revision and the next.
  • Commit.
  • Snapshot.
  • Hash.
  • Reference ID.
  • Pointer.
  • Tree.
  • Node in a graph.

A Git repository is an object-oriented database. The schema of its data structure is that of an Acyclic Directed Graph. The Objects in the database are the nodes in the graph (trees, folders, tags). Each node is a change-set. It’s a snap-shot of the current state of a branch, and it is called a “Commit,” and the edges are pointers to the previous node.

Commits are objects that contain pointers to the previous commit (parent – child relationship). Merges are commits that point to two or more parent commits.

Git What is Git?

What is Git?

Simply – Git is a utility program for managing versions of your source code files

Git is a version control system. If you didn’t already know this, version control systems are programs used in software development projects that provide a convenient way to backup a development team’s work in progress.

Note: In development projects involving multiple developers, Git provides a way for the developers to develop their individual contributions independently, and then when the code is ready, to merge their bits into the code base.

Learning resources

The following table contains links to the learning resources that I used to write this cookbook.

Resource Description
Git for Ages Four and Up To speed up your climb up the learning curve, you’ve got to see this video.
The Pro Git Book A comprehensive Git reference manual.
Think like a Git A good conceptual discussion.
The official Git documentation Straight from the horse’s mouth.
EGit/Git For Eclipse Users If you’ve installed EGit for Eclipse, then I recommend that you take a look at this help topic.

Git is a distributed version control system

Source Depot and Subversion are centralized version control systems. At the heart of these systems is a central database (or repository). All merges occur at the central database. Git doesn’t work like that. Everyone working on a project using Git takes a copy (an enlistment in the parlance of Git) of the entire repository, and there isn’t a central database. But there is a remote repository that serves as the master or funnel point. By default, this is called origin. Everyone working on the same project synchronizes their local enlistment with the origin repository. That way everyone keeps up to date with everyone else’s work.

Git isn’t based on the file system

Unlike all other version control systems, Git isn’t file system-based. The Git system is abstracted on top of the file system. To use Git successfully, you have to understand the nature of Git, and the way that Git works. The road to getting there isn’t easy because it requires comprehending a paradigm shift. To an extent, you must unlearn what you understand about source control systems per se. So, to be successful, you must – free your mind!

Eclipse cheat sheets

In Eclipse, if you click Help > Search, the Help tab appears and it has an input field for searching the local help system. If you type git into it and press Return, a list of candidate topic links appears. The first one is “Cloning a Git Repository”. Click it, and the “Cheat Sheets” tab appears. This is interesting. This seems to be a help system that is tied to a Wizard-driven interface, which makes it into a cool tutorial/walk-through system.

Rules of thumb Technical Writing

Common Technical Writing Mistakes

When I perform an editorial pass over content written by developers, I often come across the same kinds of technical writing mistakes, over and over again.

  • Couching things in the future tense, when the present tense is considered more concise. E.g., “Clicking Print will print the document.” Would be better written as “You can print the document by clicking Print”. This helps ground the reader in the here and now.
  • Use of passive voice instead of active voice. When you use active voice, the sentence has a subject that acts upon its verb, which is easier to understand. E.g., “You can instantiate the object”, as opposed to “The object can be instantiated.
  • When referring to the developer user, authors use sentence constructs like “The developer can..”. Instead, the you should speak directly to the reader. You do this by speaking in the second person. E.g., “You can…” This forces the reader to imagine themselves performing the action, which provides a better user experience.
  • The use of bulleted list items, when numbered list items should be used. Any list of items that should appear in sequence should be numbered.
  • Don’t say “please” when you’re giving direction. Save “please” for personal communications.
  • In a procedure, performing multiple steps in a single step. Steps should be for completing one task only.