· devops git

Learning Git

I have started using git lately, to contribute to projects at work, and git is both simple to start and use but at the same just a huge concept to get your head around. Its safe to say, whilst cloning, committing, merging and rebasing, I have made a few ‘mistakes’ so here is my guide on git so far. Initial Install and configuration of git

git is the repositories for Red Hat, Ubuntu and Debian and should be in any distribution based on those, ie Fedora, Kubuntu etc. This will only need to be done once but configuration can be changed later, ie a different email address. The settings are stored in ~/.gitconfig and because we are updating the global configuration the directory you are in doesn’t effect the commands.

yum install git
git config --global 'user.name' 'Your Name'
git config --global 'user.email' '[email protected]'

Initial repository set-up

This is how you get started if you’re the one with the original files. The “init” command must be run in the top-level directory of your codebase; after that, any git commands you run will work against the repository as long as you’re somewhere in it. You do this once per project, at repository creation time.

mkdir NewProject
cd NewProject
git init
git add .
git commit -m 'First commit'

Initial repository setup (contributor to existing project)

Alternatively, if you’re not the one with the original files (in other words, if you’re downloading and/or contributing to a project that already exists), you’ll do something like this. Run this in any directory, and a subdirectory will be created with the project files in it.

git clone '[email protected]:aaronmehar/quick_scripts.git'
Per-repository (local) configuration of git

Once you’ve created your local repository (either by initializing your own or cloning someone else’s), you can (but don’t have to) configure git with local (per-repository) settings. The syntax is the same as above, but without the “–global” option. Again, this step is optional, and only necessary if you need to override the global git settings in a specific project. These settings are stored in …/.git/config and these commands must be run from somewhere in the repository directory tree.

cd quick_scripts
git config 'user.name' 'Your Name'
git config 'user.email' '[email protected]'

Making changes

This is overlapping the beginning of the tutorial a little bit, but since I’m aiming for absolute beginners, it’s probably worth explaining. Once you’ve got a repository, you’ll be making changes to it. Once you’ve made some changes (represented by the “vim” command below), you apply them to the repository by doing a commit. The “git add” command tells git to start tracking any currently-untracked files (don’t worry that you don’t know what that means…just be sure not to have any files in your repository that aren’t part of the project). Then the commit: “-a” tells git to add “all” changes to the commit (technically you can commit different parts of your changes separately, but that’s a bit more advanced) and “-v” tells git to be verbose. When you do the commit, git will pull up an editor for you to type a commit message; the editor will already contain a full diff of your changes, thanks to the “-v” flag. Review the diff to make sure it’s right, delete it so it doesn’t clutter up the commit, then type your commit message and save.

~/quick_scripts % vim myfile.txt
~/quick_scripts % git add .
~/quick_scripts % git commit -av
Quick note about commit message formatting

In order to play optimally with others, you need to observe the following guidelines when composing your commit messages:

The first line of the commit message is the summary, and must be 50 characters or less. Git’s commit log display tools are basing their UI assumptions on this length, so stick to it. No, you are not a special snowflake. FIFTY CHARACTERS. :) Vim’s syntax highlighting will give you a visual cue, if you use it as your commit message editor in git. (If you think 50 characters is unreasonably short for a given commit, chances are you’re stuffing too much into one commit and need to break things up.) The second line separates the summary from the main body of the commit message, and must be blank. That means completely blank, no whitespace.

The third and subsequent lines are the main body. They can contain anything, but must be word-wrapped at 80 characters or less. My personal recommendation (and pretty much the de facto standard) is 72 characters, because that length allows for several levels of quoting if your patch winds up getting emailed around. Again, Vim will handle this for you out of the box if you use it for your commit message editor.

  • LinkedIn
  • Tumblr
  • Reddit

Aaron Mehar

Berkshire, UK