Creating a Git repo

It's very easy to create a Git repo. Follow these steps:

1. Make a directory to hold your versioned files using the following commands:

   cd
   mkdir puppet
   

2. Now run the following commands to turn the directory into a Git repo:

   cd puppet
   git init
   Initialized empty Git repository in /home/ubuntu/puppet/.git/

Making your first commit

You can change the files in your repo as much as you like, but Git will not know about the changes until you make what's called a commit. You can think of a commit as being like a snapshot of the repo at a particular moment, but it also stores information about what changed in the repo since the previous commit. Commits are stored forever, so you will always be able to roll back the repo to the state it was in at a certain commit, or show what files were changed in a past commit and compare them to the state of the repo at any other commit.

Let's make our first commit to the new repo:

1. Because Git records not only changes to the code, but also who made them, it needs to know who you are. Set your identification details for Git (use your own name and email address, unless you particularly prefer mine) using the following commands:

   git config --global user.name "John Arundel"
   git config --global user.email john@bitfieldconsulting.com
   

2. It's traditional for Git repos to have a README file, which explains what's in the repo and how to use it. For the moment, let's just create this file with a placeholder message:

   echo "Watch this space... coming soon!" >README.md
   

3. Run the following command:

   git status
   On branch master
   Initial commit
   Untracked files:
     (use "git add <file>..." to include in what will be committed)
           README.md
   nothing added to commit but untracked files present (use "git add" to track)

4. Because we've added a new file to the repo, changes to it won't be tracked by Git unless we explicitly tell it to. We do this by using the git add command, as follows:

   git add README.md
   

5. Git now knows about this file, and changes to it will be included in the next commit. We can check this by running git status again:

   git status
   On branch master
   Initial commit
   Changes to be committed:
     (use "git rm --cached <file>..." to unstage)
           new file:   README.md

6. The file is listed under Changes to be committed, so we can now actually make the commit:

   git commit -m 'Add README file'
   [master (root-commit) ee21595] Add README file
    1 file changed, 1 insertion(+)
    create mode 100644 README.md

7. You can always see the complete history of commits in a repo by using the git log command. Try it now to see the commit you just made:

   git log
   commit ee215951199158ef28dd78197d8fa9ff078b3579
   Author: John Arundel <john@bitfieldconsulting.com>
   Date:   Tue Aug 30 05:59:42 2016 -0700
       Add README file

How often should I commit?

A common practice is to commit when the code is in a consistent, working state, and have the commit include a set of related changes made for some particular purpose. So, for example, if you are working to fix bug number 75 in your issue-tracking system, you might make changes to quite a few separate files and then, once you're happy the work is complete, make a single commit with a message such as:

Make nginx restart more reliable (fixes issue #75)

On the other hand, if you are making a large number of complicated changes and you are not sure when you'll be done, it might be wise to make a few separate commits along the way, so that if necessary you can roll the code back to a previous state. Commits cost nothing, so when you feel a commit is needed, go ahead and make it.

Branching

Git has a powerful feature called branching, which lets you create a parallel copy of the code (a branch) and make changes to it independently. At any time, you can choose to merge those changes back into the master branch. Or, if changes have been made to the master branch in the meantime, you can incorporate those into your working branch and carry on.

This is extremely useful when working with Puppet, because it means you can switch a single node to your branch while you're testing it and working on it. The changes you make won't be visible to other nodes which aren't on your branch, so there's no danger of accidentally rolling out changes before you're ready.

Once you're done, you can merge your changes back into master and have them roll out to all nodes.

Similarly, two or more people can work independently on their own branches, exchanging individual commits with each other and with the master branch as they choose. This is a very flexible and useful way of working.

Note

For more information about Git branching, and indeed about Git in general, I recommend the excellent book 'Pro Git', by Scott Chacon and Ben Straub, published by Apress. The whole book is available for free at https://git-scm.com/book/en/v2.