Now that I moved my blog to github-pages generated by octopress, using git is the only way to make progress. Rather than digressing about my experiences @migrating from wordpress to octopress- I would rather keep this post as my notes on git
getting started
I find it interesting to learn by jumping-in rather than reading tons of volumes first. To get started you need to let git know that you are going to be setting a repository, this needs to happen in a particular directory- which contains stuff you want to manage. The command is:
|
|
Once an empty git repo is initialized now the next step is to add some content for git to track. Lets start by adding a a script that fetches weather information (just for fun). Once I have the script the next step is to let git know about it.
|
|
This will add all sh
files to git, this is two step process:
git add
will add the files to a staging area, more on that shortlygit commit
will commit files in git repo
Now that scripts have been added. Say you need to tweak the script and recommit the changes.
|
|
From git's
perspective following stages occur:
- you started with an unmodified file, that’s the
unmodified stage
in pic below - you edited the scripts, git tracks filesystem for changes- that’s the
modified stage
- you add file back- your intent is to eventually commit this file- but you haven’t done that yet. Thus
staged
stage - on commit, git takes the
staged
changes and commits them
Here is an image from git scm book, which explains how the files are tracked by git very well:
checking status of files
We have been creating and committing things. With projects you will generally have lot more files that just one/two files. And generally I keep an eye on what is modified and what is staged- to get a better picture of what things have changed and what I am committing. That’s where git status
comes into picture. For eg: this blog post hasn’t been committed yet so if i do git status
on my blog root directory I get:
|
|
Few things to note here:
- I am on
master
branch git
tells me I have modified the file and can undo withgit checkout
command or stage withgit add
command
Let’s add a few more files to our scripts directory to go with- namely the pic for git-lifecycle and a README.md Now we have two newly added files and a staged file, git would generate something like this:
|
|
tracking & staging files
Now that we know new files have to be added for tracking (and are staged) and modified files have to be added as well (for staging). However one of the things to note is git add
command stages file based on it’s contents and at that time.
|
|
Let’s add a few things to README.md
and then stage the file. After staging file you realize you missed a few thingsi to note so tweak README.md
again and if you check git status
now you will see:
|
|
You thought you already staged the file- which you did but that was at earlier point of time, contents have changed. Thing to note is git tracks/stages file based on contents, it internally generates SHA1 HASH.
The right way to fix things is to re-stage the README.md
file and then commit. Simplest way is to use command git add --all
, this will take care of adding/removing/stating files- but it does for everything. For managing what get’s staged you should setup .gitingore
file- so you can neglect generated/intermediate stuff that you don’t care about tracking.
gitconfig
helps customize your global git
settings or just for your repo. Here is list of configs for my local repo. Most common config is to provide for user.name
and user.email
and a few more tweaks. Even signing commits is a config.
From git-scm:
First, a quick review: Git uses a series of configuration files to determine non-default behavior that you may want. The first place Git looks for these values is in the system-wide /etc/gitconfig file, which contains settings that are applied to every user on the system and all of their repositories. If you pass the option –system to git config, it reads and writes from this file specifically.
The next place Git looks is the ~/.gitconfig (or ~/.config/git/config) file, which is specific to each user. You can make Git read and write to this file by passing the –global option.
Finally, Git looks for configuration values in the configuration file in the Git directory (.git/config) of whatever repository you’re currently using. These values are specific to that single repository, and represent passing the –local option to git config. If you don’t specify which level you want to work with, this is the default.
|
|
to display entire list of what you can git config --list
& press tab
|
|
ignoring files
not every file needs to be tracked in git repository. With C++ compilers generate tons of obj/archives and other temp files which we don’t care about to track. to let git know about what not to track you should. For eg: I was checking Rakefile
in blog root dir for pushing stuff to git as part of deploy. I have it open in vim
and made a few changes. vim
being vim
will create a temporary Rakefile.swp
, which I don’t care about, so is ideal candidate for ignoring. Here we go about ignoring things: :)
A quick check on my blog root directory says these files are set to be ignored
|
|
to add more to it i would vim .\.gitingore
and add *.swp
at the end and that’s it. You can add files/directories to .gitignore
and it should just work fine. Here are a few rules to keep in mind, source
The rules for the patterns you can put in the .gitignore file are as follows:
- Blank lines or lines starting with # are ignored.
- Standard glob patterns work.
- You can end patterns with a forward slash (/) to specify a directory.
- You can negate a pattern by starting it with an exclamation point (!).
viewing changes
Now that things have been set, it’s time start checking what changes are there before committing or staging. This is one of my most common workflow. I keep on staging and diffing files- love reviewing my own code :)
I just added *.swp
to .gitignore
, if i do git diff
command with no arguments it will tell me about all the files that have changed and the differences:
|
|
git diff
shows you diffs in what is in your working directory vs staging area- so it highlights changes that have been made since you last staged the file. git diff
takes in a lots of parameters but one of the most common is to see what you are committing and can be checked with --staged
options.
I have staged the .gitignore
file so this is what i will be committing
|
|
In case you want to see list of files that have been staged the command would be:
|
|
committing
we have been committing changes all this while, this is the last in the various stages we saw earlier. You can directly issue git commit
command it will open an editor for you to enter comments, vim
for me. In case you have terse comments you can bypass this with -m
option with git commit
as we have done already.
|
|
git commit
commits files that have been staged- at times with small changes two step process is a bit too much. I often make small changes and commit often. For this you can pass -a
flag with commit command, would have worked the same
|
|
removing files
This is a infrequent task and I would be careful with it. But comes in very handy when you have got un-neccessary files staged/committed. To remove the files from staging command would work.
|
|
I would ask you to refer git-scm book for details
statistics and history
I have been committing things as I wrote this post. To check the commit history git log
is the command:
|
|
Or I can check in more details what was committed, -p
shows difference in each commit and i am limiting it to last commit with 1
as option
|
|
For a brief summary I could alternatively have passed --stat
option. Or to generate a list of commits i have done so far with this blog- but in a bit less verbose and human readable form i would do:
|
|
Options to pretty=format
are:
1. `%h` - will give you abbreviated commit hash
2. `%an` - will give you author-name
3. `%ad` - will give you the commit date-time
4. `%s` - subject or short description from commit message
For complete list of options visit this page
in the end of beginning
this is just scatching the surface of what git provides- there is still lot to explore:
- branching
- merging
- various tools and tweaks
- local server hosting, not sure if i will ever want to get into this
Well, this is most of the stuff I need to get started with git and octopress. Here are few resources that came in handy:Additional details (click to expand..)