The Basics

In a few min­utes we’ll step through a sim­ple work­flow using Git. But first let’s review a few of the basics of Git that we need to under­stand before mov­ing forward.

We’ll cov­er:

  • Repos­i­to­ry
  • Branch­es
  • Com­mits
  • Remote Repos­i­to­ry
  • Branch­ing & Merging

Repos­i­to­ry #

The repos­i­to­ry is a col­lec­tion of files and direc­to­ries and their his­to­ry of changes. These changes are record­ed with com­mit objects. These com­mit objects are ref­er­enced by oth­er items in Git (branch­es and tags, to name just two).

A new repos­i­to­ry can be cre­at­ed by any­one at any time using the git-init com­mand. By default repos­i­to­ries are local only and don’t require a remote.

Branch­es #

Every Git repos­i­to­ry has at least once branch. When you first ini­tial­ize your Git repos­i­to­ry, you have a branch called master. You can have addi­tion­al branch­es in your Git repos­i­to­ry and name them as you see fit. They are inde­pen­dent from each oth­er unless you choose to merge one branch into another.

Com­mits #

A com­mit is a record of what the repos­i­to­ry looked like at a giv­en point in time.

Each com­mit has a com­mit mes­sage, which should briefly explain what the changes were. You can also access a diff to show where the changes were made in a spe­cif­ic commit.

Com­mits should be cre­ate as atom­i­cal­ly as pos­si­ble, so you have as many points in the his­to­ry of repos­i­to­ry as pos­si­ble. More com­mits will give you more pre­ci­sion in undo­ing break­ing changes.

Remote Repos­i­to­ries #

By default Git is com­plete­ly local to your com­put­er. You can option­al­ly have remote copies of the repos­i­to­ry (either on a cen­tral serv­er or ser­vice — like Github — or on a co-work­ers computer).

To get your copy of the repos­i­to­ry up to a remote serv­er you use the com­mand git-push. If you want to retrieve oth­ers’ changes to the repos­i­to­ry you use git-pull.

We’ll cov­er all of this is more detail lat­er on in the class.

Branch­ing & Merg­ing #

Ear­li­er I men­tioned branch­es. Pri­or to using Git, my expe­ri­ence with ver­sion con­trol sys­tems was using Sub­ver­sion, and before that CVS. My expe­ri­ence with Sub­ver­sion was that branch­ing — and espe­cial­ly merg­ing — was not a fun thing to do. It often didn’t work prop­er­ly and left the project in a state of conflict.

In Git, branch­ing and merg­ing are sim­ple and safe. Lat­er on we’ll talk about com­mon Git work­flow pat­terns. Most of them rely heav­i­ly on branch­ing and merging.

A few notes about branch­ing in Git:

  • A branch is typ­i­cal­ly cre­at­ed local­ly first and then pushed to a remote (if desired).
  • As we’ll see lat­er in the Work­flows sec­tion, Git is set up to be branch-heavy. Cre­ate a lot of branch­es and cre­ate them lib­er­al­ly. It’s the ben­e­fit of hav­ing a merge process that works so nicely.
  • Branch­es can be only local, if you want. There’s no require­ment to push all of your branch­es to a remote serv­er. I use branch­es a lot for local exper­i­ments that I lat­er delete.