Just enough GiT for Puppet Automation – Part3

by Ramdev · December 1, 2021

+ summary of this article :

All Posts in this Series

Committing and inspecting Git changes
What happened when we ran the above commands?
How often should I commit?

All Posts in this Series

Committing and inspecting Git changes

Let’s make a change to the manifest and then use Git to see some information about it.

1. Edit the file modules/nginx/manifests/init.pp and find the section defining the nginx service:

service { ‘nginx’:
ensure => running,
require => Package[‘nginx’],
}

2. Add the following line:

service { ‘nginx’:
ensure => running,
enable => true,
require => Package[‘nginx’],
}

3. Save the file and run the following command:

igurkul@demo:~/puppet$ git status
# On branch master
# Changes not staged for commit:
# (use “git add …” to update what will be committed)
# (use “git checkout — …” to discard changes in working directory)
#
# modified: modules/nginx/manifests/init.pp
#
no changes added to commit (use “git add” and/or “git commit -a”)

4. Use git diff to show you how the code differs from the snapshot taken at the last commit:

igurkul@demo:~/puppet$ git diff
diff –git a/modules/nginx/manifests/init.pp b/modules/nginx/manifests/init.pp
index b152f17..f272a7c 100644
— a/modules/nginx/manifests/init.pp
+++ b/modules/nginx/manifests/init.pp
@@ -5,6 +5,7 @@ class nginx {

service { ‘nginx’:
ensure => running,
+ enable => true,
require => Package[‘nginx’],
}

5. Add the changed file to the set that will be included in the next commit:

igurkul@demo:~/puppet$ git add modules/nginx/manifests/init.pp

6. Commit the change:

igurkul@demo:~/puppet$ git commit -m “Have nginx start at boot time”
[master ad71988] have nginx start at boot time
1 file changed, 1 insertion(+)

7. Check the log of changes:

igurkul@demo:~/puppet$ git log
commit ad719887ef68535dd6b76bab8bcee9b76edb3c98
Author: John Arundel <john@bitfieldconsulting.com>
Date: Mon Oct 22 17:08:34 2012 +0000

Have nginx start at boot time

commit 36f88cbf36782bd8e74499bb23a3a8aa5cc44ef9
Author: John Arundel <john@bitfieldconsulting.com>
Date: Mon Oct 22 16:38:58 2012 +0000

Importing

8. Use git whatchanged to have Git display a diff showing what was changed in the commit:

igurkul@demo:~/puppet$ git whatchanged -p -n 1
commit ad719887ef68535dd6b76bab8bcee9b76edb3c98
Author: John Arundel <john@bitfieldconsulting.com>
Date: Mon Oct 22 17:08:34 2012 +0000

Have nginx start at boot time

diff –git a/modules/nginx/manifests/init.pp b/modules/nginx/manifests/init.pp
index b152f17..f272a7c 100644
— a/modules/nginx/manifests/init.pp
+++ b/modules/nginx/manifests/init.pp
@@ -5,6 +5,7 @@ class nginx {

service { ‘nginx’:
ensure => running,
+ enable => true,
require => Package[‘nginx’],
}

What happened when we ran the above commands?

The line you added to nginx.pp is useful; it tells Puppet to configure the nginx service so that it starts when the machine boots.

enable => true,

You have now changed the code so that it differs from that stored in Git’s database, and you can see which files are different using git status:

# modified: modules/nginx/manifests/init.pp
To see exactly what the differences are, use git diff:
service { ‘nginx’:
ensure => running,
+ enable => true,
require => Package[‘nginx’],
}

The + indicates a line was added.

The next step was to tell Git to include this change in the next commit, by using the git add command:

igurkul@demo:~/puppet$ git add modules/nginx/manifests/init.pp

Now you make the actual commit, with a suitable explanatory message:

igurkul@demo:~/puppet$ git commit -m “have nginx start at boot time”

The change (or more accurately, set of changes; in this case we only made one) is now stored in Git’s database, and we can see it using the git log command:

igurkul@demo:~/puppet$ git log
commit ad719887ef68535dd6b76bab8bcee9b76edb3c98
Author: John Arundel <john@bitfieldconsulting.com>
Date: Mon Oct 22 17:08:34 2012 +0000

Have nginx start at boot time

commit 36f88cbf36782bd8e74499bb23a3a8aa5cc44ef9
Author: John Arundel <john@bitfieldconsulting.com>
Date: Mon Oct 22 16:38:58 2012 +0000

Importing

The long string of hexadecimal characters following commit is called the commit hash, and it uniquely identifies the commit in this repo:

commit ad719887ef68535dd6b76bab8bcee9b76edb3c98

Whenever you need to refer to a particular commit, you can use this hash to identify it.
As time goes on, you will still be able to see every change you’ve committed to the repo right back to the initial import. The git whatchanged command shows you the effect of each change, just like git diff does for uncommitted changes:

service { ‘nginx’:
ensure => running,
+ enable => true,
require => Package[‘nginx’],
}

Note : You can skip the git add step by using the -a flag to git commit, as follows:

git commit -a -m “Have nginx start at boot time”

This automatically adds all changed files to the commit. However, it’s a good idea to use git status and git add to see precisely what changes you are committing. Sometimes you may want to split your changes into two or more separate commits.

Also, if you have added new files that Git doesn’t know about yet, you’ll still need to use git add to tell Git they should be placed under its control.

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 quite 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.