Git notes

From Helpful
Jump to: navigation, search
This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Git is a content/source versioning system.

One of many. Currently popular.

Git's focus and niche seems to be a swiss army knife - more flexible than most, though with a steeper learning curve.

Previous systems often had a central repostory / working copy model. You can use git that way -- in fact github mostly does this -- but it's now one specific use, and your choice.

Whether git has added value over something simpler probably depends on your project, and the way you would like to manage it. For example, for tight-knit teams with clear responsibilities, or individuals just wanting code history, it has no added value over simpler ones.

Free-form use like huge projects, or enthusiasts hacking and forking other people's code (see also github) may find its flexibility more useful. In that case, pull requests are a slightly nicer way to communicate diffs.

But basically: compare to subversion, mercurial, bazaar and such.

And in practice, if you use a GUI frontend, the choice of that may actually be more important than what backs it.

Relevant snark:

  • Github has a lot of actually-quite-nice tooling -- to deal with all the thing that happen only when there is zero communication with upstream before a lot of code is written (that upstream maintainers will typically reject the first version of)
  • 90% of people don't need 70% of git.
  • some of the neat stuff comes more from wrappers like github than from git itself
and in part from imitating a classical repository (rather than using all its features)
  • more power means more edge cases, that you will have to learn sooner or later
(though all of these systems have them. If you want to learn just one, git may still be the better even if it's more complex)

Mental model, and "For those coming from other versioning systems..."

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


  • all git copies are created equally (no repository / working copy distinction)
also meaning you have all the revision history
  • You commit to your own copy
first you stage the changes you want to commit (more focus on creating useful bundles of differences)
commits are purely local things - recording your own changes

  • if you want to communicate such changes between copies, you need to
    • tell git how copies relate
    • explicitly trigger what to communicate
The "we use this one spot as a repository" is possible, and because it's easier on the mind, fairly common (see github)
often such interactions are merges
you can use git much more decentralized if you want
(git clone usually sets up such a relationship with where you got it)

  • most people can get started with
    • a github account
    • adding your first repository there (assuming that's why you wanted to use git)
    • git clone
      to get a copy of one of your repositories, and automatically have it be related to github for pushes
    • git add
      to stage changed files
    • git status
      to see what's staged
    • git commit
      to commit the staged changes to your own copy
    • git push
      to push your committed changes to github
  • when working in a repository style, you'll also want
git pull
(which does a git fetch and a git merge FETCH_HEAD)
which is similar to (but technically more complex than) what in other systems is an update

all branches and forks are public and (ideally) interlinked

The idea is that this makes it a little easier when more disparate people work on software.

Including some implied democratization of that situation.

Ideally that makes things more participatory.

Though after a learning curve, so if all you care about is history for a small team, it's overkill.

Some nitty gritty

Some initial config

How you'll be identified elsewhere:

git config --global "My Name"
git config --global

If you like colors, you may like:

git config --global color.ui true

Starting to work with versioned code

To start your own:

git init

To fetch a copy of a hosted copy

git clone url

Starting projects on github (the easy way)

Create a project, find the clone link, clone it. This sets

Starting projects on github (the hard way)

Some common stuff to do


See recent changes, e.g. date:

git log

Show origin URL:

# brief
git remote -v
git ls-remote --get-url 
git config --get remote.origin.url # previous line preferred?

# more about remote branches
git remote show origin


git describe   # "Describe a commit using the most recent tag reachable from it"
git rev-parse HEAD

See also:


Interacting with connected repos

Pull requests basically mean you saying "hey collaborator, I've completed adding this feature to your code, might you want to integrate it?".

Pull requests aren't central concepts in git, they're extra communication that sites like github add. And they make more sense to do with such a more centralized place.

On (local) branches

Branches and communication

On using someone's branches

Basic branching example (create, merge)

shared branches


See also: (TODO: do so myself)



Discussions and other:

git GUIs

In no particular order:

  • gitg (lin)
  • comes with git:
    • git gui
      (more for management - more complete than most, not so polished)
    • gitk
      (mostly a viewer)
  • qGit (mostly a viewer)
  • giggle (mostly a viewer)