Git What is Git?

Git: Key Concepts

Git’s unusual relationship with the file system

Git plays a kind of slight-of-hand with the contents of your local file system. The contents of all of the branches in a Git repo appear to occupy the same place on your local disk. No other CVS does this, so it’s a paradigm shift that you need to comprehend to really understand the nature of Git. E.g., You check-out a particular branch, and then cd to one of its directories. You open a file in that directory (called index.rst say), and it contains one sentence of text. Next, you checkout another branch, and open the same file, in the same directory. This time however, the file contains an entire paragraph of text (for example) – same place on the hard drive, but different contents.

Git repository

A Git repository contains all of the information needed to transform its working directory file structure into a snapshot of any commit in any branch. Take a look in any repository’s “.git” directory – especially the “objects” directory, to see the bits that Git assembles it from. By convention, I store my repositories in %USERPROFILE% in a directory called src.

Git branch

A branch holds a set of incremental changes to files and folders in a repository (snapshots, HSAs). Internally, Git represents branchs as tree objects. Branches are identified by a reference on the last commit. At any time, the state of the files that you’re working on belong to a snapshot called “the Working Directory”. As your work progresses, you frequently save your work in progress (using the file system save feature). Each time you save your work, Git updates a branch snapshot called “index”. If you have staged changes, and you create a new branch and then switch to it, the state of the staging area isn’t changed. You can use the index like any ref. I.e., you can diff between index and the last commit.

Git changeset

Leverage Git branching to help you manage documentation updates

In the project I was workikng on, my mainline on Origin was a branch called feature/api_doc. I’d merge my completed work into this branch, and then push it to origin.

Note: Don’t use feature/api_doc for your work in progress.

Instead, create a new branch for the new work (e.g., named after the new feature), and complete the work in that branch, and then merge the new branch into feature/api_doc – after you’ve completed the update (which includes draft, technical review, update content per technical review, second review, etc.). Then you Push your merge commit up to origin, and then send a pull request to the lead dev to have your new content merged into mainline.

Base the new branch on feature/api_doc.

  1. Checkout feature/api_doc.

  2. Update feature/api_doc (Pull) to ensure that you’re in synch with origin.

  3. Create a new branch (e.g., git branch -b Verify_Code_Sample_Update)

    1. In Eclipse, switch to the Git Repository view.

    2. Right-click the repository that you want to create the new branch in.

    3. Click Switch To > New Branch.

    4. Enter a name for the new branch (e.g., Verify_Code_Sample_Update).

      No Pull Strategy.

      Checkout new branch.

      When you commit content to this branch, Git manages a reference (SHA) to it named: refs/heads/Verify_Code_Sample_Update.

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).

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.