fbpx

Tag: Git

How Git fits into your Linux scripting process

When you begin to learn the basics of the Linux command line, you also find that you want to automate commands by gathering them in scripts. This will prove to be a valuable time-saver as you grow your Linux skills.

But when you have scripts that are longer than, say 20 lines, and you go back to modify and build on them, the complexity increases. Whether you are the only one working on and using the scripts, or if it is a team effort, you will want to use revision control. This helps you track changes to the scripts over time and can also save time so you don’t have to ask yourself, “What on earth was I thinking when I added command x?”

This is where Git comes in handy. Git is a distributed version control system. As such, you use it to track changes in computer files. It is often associated with developers and their toolset, but as the IT industry grows more concerned with durability and transparency, Git also becomes a useful tool for IT Operations staff and data scientists. Just to name a few.

Use Git to control changes and improve transparency

Even if you write and use your scripts exclusively, as your scripts begin numbering in the hundreds (not uncommon), you will find that you need to recall why some changes were made. Git comes to the rescue in this case. Of course, that depends on whether the git commit comments are descriptive and clear.

Read more about Git here (its homepage) and here (Wikipedia page).

Happy scripting! And go ahead and create your first git repository.

5 reasons for you to store your Bash scripts in Git repositories

1 Maintain a history of your script improvements – Force yourself to continuously improve

Git will help you to get a clear overview of how your scripts have evolved. Maybe you need to go back a version or two and fork a script from there. If you have added proper comments in your scripts, than you and others can follow your reasoning easily.

A funny thing happens when you start adding code in Git repositories and update them as you add or change code. You become more prone to improving your code as you know which parts needs some more work. Maybe even a #ToDo note somewhere that signifies a totally new feature – That #ToDo comment will nag you more when you have a Git repository and constantly go there to check it out. Add the reasoning in reason number 2 and you also feel the peer pressure from others to continue building on your useful scripts.

2 Others might take over your scripts for regular usage

Think of the Linux users that you will work with and that will need the same toolchest that you have. Show some team spirit and share your work, of course with proper attribution to you as a script programmer. This gives you a lot of respect

3 Understand the fallacy of “the perfect script” thinking

There are no perfect scripts. No silver bullets to any IT problem of a larger scale. In the Linux world we are also used to many ways to solve simple tasks on the commandline in many ways. This statement can then be used to argue that your solution has no need to be hidden away or not to be covered by version control. With version control you introduce the idea of newer and better versions of your Bash script. It is a nice trick to show yourself and others that yes, improvements and new ideas are welcome.

4 DevOps and Test-Driven Development ask for iteration and cross-border approaches

These two paradigms really show that more collaboration is expected between subject matter experts, whether a Linux user, a Python scripter, or a LAMP Engineer (to give only three examples). We get inspiration from each other’s solutions to tasks on the commandline. These solutions are stored in Bash scripts. By using Git you show that you are open to the idea of sharing your scripts as well as reject the notion of the “write once, all good, don’t argue” type of mentality.

5 Git is used to version control more than you think

These days you will find that Git is used by many more than programmers. From technical writers to scripters and data scientists. The idea of applying version control and having central repositories that can be forked and worked on by many people is simly very appealing. It also deals with the number one silo: The expert that sits on all the knowledge but that is so tremendously useful to others as well.