..traces left on one November 27, 2019 01:30

Wanna use Git? Here are further improvements.

So now You know how You may benefit from Git, as far as Your creative work is concerned. Whenever You are a writer, a blogger, a webdesigner, or even a computer graphic artist (You name it) - You could take advantage out of this interesting invention.

In one of the previous posts I described in general, how You can set Git up and use it under Windows. BTW, I find it fantastic that it can be used on other - i.e. non-GNU/Linux - platforms (it wasn’t so obvious, as there are many fantastic tools which are restricted to GNU/Linux and You can’t benefit from them anywhere else).

Now, let’s get things further, making it even easier, faster, and more friendly in everyday use :) . In the meantime You’ll learn some more stuff which also comes in handy and may significantly widen what You could do with all of that. So let’s get started:

Quick survey on what’s coming:

1. Open terminal window always in the right place.
2. Learn how to copy&paste in Cygwin.
3. Harness a text editor of Your preference.
4. Use more intuitive commands.
5. Your project status always at hand.
6. Track Your work progress.
7. Embrace snapshots.
8. Embrace multi-version approach.

Earlier on I showed You how You can enrich Windows in-built terminal with proper functionality needed when it comes to Git. There is yet another approach, though, which You might find much easier to handle: You could call it Just stick to the Cygwin :) .

As You may remember, Cygwin is the tool to install when You need GNU/Linux commands (or GNU/Linux-like apps) under, let’s say, Windows. Our first approach did not incorporate Cygwin much, at least not in front of Your eyes - reserving “the creamy stuff” for Windows own console, with which You might be already familiar (in case You find the nomenclature confusing, I recommend You to take a look at this note on terminal, console, and other similar terms - explained in a nicely, straightforward way).

As such, Cygwin seems to be a pretty interesting bit of software. At first glance it looks like just another terminal, nothing really special - but then You may realize that it has additional power under the hood, providing You with a whole bunch of stuff well-known for many GNU/Linux users. In this respect Cygwin may take You a long way deep down its own adventure, as a result of which You may find Git just one of many stops during the journey.

Sticking with Our main subject today, which is Git, it is fine to say that Cygwin may be Your (much) better command prompt under Windows - for a number of reasons. First of all, You can skip the whole part of “teaching” Windows terminal anything in order to use Git - because we won’t use this terminal at all. Have Cygwin installed? Great, You are good to go :) . Second, it is way more flexible: You can customize many things which are virtually a no-go when it comes to Windows classic terminal - like, for example, a nice elegant smoky-glass transparency effect which You may apply to its window - or interesting copy&paste approach You may have never encountered before, which automatically copies the selected text (You don’t even need to use a keyboard shortcut!) and paste it via simple right click (!). Blows the mind ;) !

Open a terminal window always in the right place.

Remember custom terminal shortcuts? It’s a nice little trick to make things easier by skipping several steps, otherwise needed to be taken each and every time You want to use Git. Today I’ll present You with yet another, even more extravagant method ;) , which saves much time, doesn’t require creating any custom shortcuts and will allow You to launch terminal window always opened in the desired place, whenever it would be. This is possible thanks to AutoHotkey - a fantastic powerful tool, which I’ve mentioned several times before, through various occasions.

In case You don’t know AutoHotkey, this survey may be an interesting road to take.

Today I’ll tell You how You can harness AutoHotkey to elevate Your terminal experience to the next level :) . Here You are how this is supposed to work:

1. Whenever You want to use Git, open a window displaying Your project folder first, and then press a keyboard shortcut of Your choice.

2. This will results in opening a Cygwin window with Your working directory already set in place.

3. Whatever folder You’ll open on Windows, the same keyboard shortcut acts accordingly, opening new Cygwin terminal window with the proper directory in place - so You don’t need to navigate toward it any more.

As a curiosity: there are many things You could achieve much easier and faster just using a sole terminal, instead of anything else. One example (described in details later) is searching for files containing a particular word or a phrase and then automatically opening them in a text editor - You can perform this action with one single command. There seem to be no way to do it faster than this. And this is just one example - as I’ve mentioned, there are many more. In case You’d like to use it on a daily basis, the trick with terminal on-demand, launched always in the right place (i.e. accordingly to what You have opened on Your desktop) may be of much wider help than a sole Git-related purpose.

The easiest way of achieving this concept is to download this script and make it running automatically with every Windows launch.

Learn how to copy&paste in Cygwin.

It may be somewhat of surprise that in case of various terminals the classic way of copy&paste is not available (here is an in-depth answer why it is that way). The good news is that in Cygwin there are several other ways to do that, some of which You might find even more appealing than the traditional one. Let’s see...

1. Copy and paste by Ctrl/Shift+Insert.
   Open Cygwin options (click on the small icon in the left top corner of its window and You’ll find it there) › Keyboard features › check Copy and Paste (Ctrl/Shift+Ins).
2. Copy on selecting a text.
   Options... › Selection and clipboard › check Copy on select.
3. Paste by right mouse button.
   Options... › Mouse functions › Click actions › choose Paste.

Note that the ability to copy on select is especially handy, because You don’t have to perform an additional step of pressing a keyboard shortcut to copy what You’ve selected.

Harness a text editor of Your preference.

Later in this article You’ll learn of a fantastic feature of commenting Your project’s progress key steps. Thanks to this it will be much easier to find the particular point of its development - or to remind Yourself what was all about - especially in the long run, i.e. after months (or years) passed by.

The thing is that sole terminals may not be of the best choice when it comes to write anything longer than ordinary, usually concise commands. It’s not only that the font is pretty small and lacks readability - the more important thing is that You’ll be in the need to learn from scratch how to use Your terminal-based text editor. As long as You are not a GNU/Linux user with the emphasized preference of using such a tool, You definitely need more convenient way for writing Git comments, the one which is already familiar to You: Your current favorite text editor. In My case it is a Notepad++ - a fantastic tool with many helpful tricks up its sleeve. I use it for everything I can: from blogging to coding. A nice thing is that You can also use it to write Git comments :) .

If You, however, consider using terminal also for non-Git purposes - harnessing Your Own text-editor of preference may also be a good move. Consider just one example mentioned a moment ago: You need to find text files containing a particular phrase, then You need to open each of them to inspect which one is indeed the one You are looking for. All of this You can achieve with one single command, which will both find the files and automatically open them within Your text-editor. We’ll take a closer look on that concept after a while in this article.

First, let’s talk about

Custom text editor for Git.

You can simply set up Your Own text editor in Git with the following command:

git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession"

If You don’t use Notepad++, just replace C:/Program Files/Notepad++/notepad++.exe with the path to Your text editor, remove -multiInst -notabbar -nosession and You’re good to go :) .

Custom text editor for Cygwin.

In case You’d appreciate using Your Own text editor paired with a terminal also for non-Git purposes, here what You can do:

1. In Your text editor open the .baschrc file (by default it should be placed on C:\cygwin\home\YourUserName).

2. Add the following code snippet to the very end of the file:

   npp () { /cygdrive/c/Program\ Files/Notepad++/notepad++.exe -multiInst -nosession $(cygpath -w -- "$@") }

You can replace “npp” with Your Own abbreviation to initiate the text editor from the command line (as in, for example, npp text.txt).

Again, if You don’t use Notepad++, correct the path to the editor of Your preference (remember to keep /cygdrive/ part, as well as the backslash within Program\Files if Your editor is placed somewhere there) and remove -multiInst -nosession part.

Kind credits for Greta “Jade” Krafsig and Her post Cygwin Tutorial: Use External Editor Notepad++.

Now, You can recall the idea of searching text files and opening the ones founded - all with a single command:

IFS=$'\t\n' && npp $(grep -l -r 'cat')

The command above will search for files (within the current directory) containing a “cat” and open the ones which do contain it in Notepad++.

The IFS=$'\t\n' part ensures You that files containing spaces within their names will be properly handled.

Use more intuitive commands.

In this section we will dive a little bit deeper into Git everyday usage. All in all, it could be great if it could perform anything You need - in a fast and convenient fashion. Wonderful news is that, indeed, it can be that way :) ! Moreover, it can reach such a convenience point which You might find surprising :) . So, let’s get to the nitty-gritty without any further ado:) .

As You already know, using Git comes down to harnessing several “geeky” commands, like - for example - git commit for saving the current state of Your project. One interesting thing is that Git allows You to replace those commands with Your Own wording (so-called “aliases”), which You may find much more intuitive in everyday use. For instance, You could replace git commit with a simple git save :) .

Moreover, there are cases in which You need to use more complex, much longer commands - which are especially inconvenient when You need to perform them repeatedly from time to time. In such a case You could either type the whole thing each and every time... or You could ascribe Your Own (i.e. much simpler) wording to do the same thing. As an example take a look on this long command which results in displaying Your project’s history:

git log --format="%n %h %Cgreen %cr %Creset (%Cred%an%Creset) %n %s %n" --reverse

You could replace it all with a simple - say - git story. Once You do that, it will be enough to simply type git story every time You need to see it in Your Own carefully tailored way (see the longer variant mentioned earlier).

Here You are examples of how to ascribe Your Own wording to already existing Git commands:

git save (for git commit)

git config --global alias.save "commit -a"

Note that in the example above I use commit -a which always add all the changed files to a snapshot. Besides, as it does not include an -m appendix, the command will result in opening Your default text-editor for You either to inspect changes and/or provide a comment to the snapshot You are about to create (more on comments a little bit later).

git story (for git log.........)

git config alias.story 'log --format="%n %h %Cgreen %cr %Creset (%Cred%an%Creset) %n %s %n" --reverse'

Taking a closer look You will notice that this command wraps the actual Git command with apostrophes - while the previous one used quotation marks. The reason is that if the command to wrap has already quotation marks within it, then it should be wrapped with apostrophes to make it work right.

If You’d like to fix or change anything within the aliases You’ve already created, just use the same command with --replace-all attached to it after a space.

Your project status always at hand.

In this section we will explore a handful of good habits which may significantly improve Your workflow. Furthermore, You’ll learn about several useful procedures which come in handy when working with Git on a daily basis.

Since Git pays much attention to details, caring about Your work and its progress’ tracking - it is a good idea to follow suite, at least to some degree :) . This way You will ensure that everything will work as You expect. The essential good habit here comes with a git status command (which I replaced with git s for convenience and speed). It will give You a clear picture of what has happened to Your project - i.a. which files have been changed, which are completely new (and therefore require to be included within “Git’s tracking mind” ;) ). Using this command You can, for example:

1. Ensure Yourself that Your project does (not) require taking another snapshot to save its progress.
2. Remind Yourself which particular files You’ve been working on recently (sometimes it’s easy to loose track).

Here is how the result of using git status may look like:

In this case it tells that one file (“style.css”) has been changed. Note that it is red-colored - You will notice here and there that Git incorporates colors to make information more clear and readable.

Track Your work progress.

With Git You can very easily check not only on what - but also when You’ve been working on something. This is why it’s a great tool to inspect “how are things” in terms of a particular project, e.g. when was the last time You’ve dropped it, or how intensively You’ve been engaged.

Although the proper commands already exist, their default result is not so convenient - i.e. there is much room for readability improvement. By default it may look like this:

Fortunately, Git provides You with a whole bunch of smaller commands acting like “building blocks” to tailor a bigger one, which would suit You much more. A command made like this, however, may be often pretty long - so it is a great opportunity to apply Your Own wording here (i.e. aliases).

I did that with git story, which in My case results in something like this:

But first I needed to create a much longer command, with the help of which I wanted to achieve:

• more readability thanks to applying different colors and blank lines,
• reverse history order, thanks to which I instantaneously see the most recent stage of My project development;

Keeping the above in mind I’ve ended up with this:

git log --format="%n %h %Cgreen %cr %Creset (%Cred%an%Creset) %n %s %n" --reverse

which did its job well and therefore had been ready to be replaced with git story mentioned earlier on.

Embrace snapshots.

Let’s begin with a thing which You might call “snapshots”. In general, this is about saving Your project’s state every time You consider a key point on its development (not necessarily a milestone). Usually those “key points” refer to some task or a stage which You’ve just completed. Then it’s always a good idea to make “a snapshot” of Your work in that point in time, i.e. when one particular step has been achieved. In the long run it’s easy to imagine a nicely-grown history of Your work, clearly organized into logical steps, labeled with timestamps and, more importantly, with Your comments. Those are great things: every time You save a snapshot of Your work, You can describe it as precisely and clearly as You can. While creating such a comment, think of Yourself reading it after a longer while (a couple of months or even longer), therefore describe the snapshot in such a way which should be comprehensive to You (or someone else) even regardless of the passage of time.

The actual command for saving a snapshot looks as follows:

git commit -a -m "Your comment here."

I, however, prefer to use much more intuitive git save for that task, which turns the thing into this:

git save -m "Your comment here."

Now, before You go any further, let’s focus on comments as such for a moment. In Git each snapshot should be described - which may come in handy especially in the future, when You don’t necessarily remember what the particular work was all about. Then comments may turn out to be the key information needed to quickly figure things out - provided they’ve been written in the right manner, i.e. concise, precise, and comprehensive.

Note, however, that although You indeed could summarize some snapshots with a single sentence - there may be other cases in which it could be a good idea to provide more detailed information about what work has been done. In such cases You can take a little bit different approach: still stick to summarizing the whole thing in one sentence, but then elaborate on it (still in a form of a summary) via further sentences.

From the command-line perspective it looks like this:

A single-sentenced comment:

Just use one of those commands:
git commit -m "Type the comment here."
or
git save -m "Type the comment here."

A more-detailed (multi-sentenced) comment:

1, Use git commit or git save - but without anything added at the end of the command. Confirm. 2. Git should initiate Your default text editor and open a file. 3. At the very bottom of this file write the main summary in a form of a single sentence. 4. Create a blank line and then provide more detailed summary in a form of further sentences (perhaps a numbered list?). 5. Save and close the file.

An interesting approach to Git comments You’ll find here.

It’s worth noticing that git story we were talking about earlier on presents only those very first sentences alongside each snapshot. If You’d like to see full comment, use this command:

git show ID

• where “ID” stands for a snapshot “hash” (You’ll learn about it soon).

So let’s practice a little bit. Suppose You’ve just finished the next step of Your project development - which is a good time to make its snapshot. Before You’ll do that, a good habit is to ensure that everything will be included in the snapshot:

• if You didn’t create any new files, just use git status (or git s if You’ve created the abbreviation of this command) and You’ll see all the files which have been modified,
• if You did create some new files, use git add . first, and then git s (as a curiosity if You revert the order and use git s first - You’ll see that Git differentiates newly created files from already existing modified ones - every time You create a new file, You need to tell Git that it should include it within further snapshots - and You do that via git add . command);

Once You’ve ensured that all the files You want to include - in fact will be included, You can create the actual snapshot. Keeping all of the information above in mind, the complete procedure would look like this:

To create a snapshot of Your project:

1. Inspect what files should be included within the snapshot:
   git status (or git s).
2. If there are any new files, include them by
   git add . (note the period at the end of the command is important)
3. Create a snapshot:
   git commit -a -m "Your comment here..."
   or
   git save -m "Your comment here..."
4. Optionally You can ensure that everything went well by git s again - and throw an eye on the project’s history with Your newly created snapshot via git story.

Now, speaking of the git story - You may remember how I’ve described it a little bit earlier. It refers to this exact “history” thing we’re exploring now. It could look like this:

Note those random strings of characters just before green timestamps: they are called “hashes” and You could consider them to be snapshots’ “IDs”. They are very important and You will often rely on them - so at this point it’s worth to remember of their existence and how to recognize them.

You might wonder when git story may come in handy. There are multiple answers to this question. For example, with git story You could easily tell:

1. When was the last time You’ve worked on some particular project.
2. How intense Your engagement had been (based on snapshots frequency and maybe also their character).

But an even greater thing may be that You can go back and forth in time, picking one particular snapshot and switching to it. As a result, Your project files will be reverted to the point at which they were at the time You’ve created the snapshot. In other words, this is a great way of undoing things: in case something went wrong, You can always go back to the newest stable state (a snapshot consisting of such one) and all Your project files will be fine again.

What is fantastic here is that this mechanism is not confined by traditional ctrl+z history or even to a current session at Your computer till it’s turned off. With Git You can undo changes at any given time, even years and many further snapshots later.

So let’s take a closer look on how to travel in time and also how to revert Your project to one of its previous snapshots:

Go back and forth in time:

1. First, You need to find out to which particular snapshot You’d like to switch. Use
   git story
   to view Your project snapshots history.
2. Once You know to which snapshot You want to switch, copy its ID/hash (see Learn how to copy&paste in Cygwin). Important: note on the side also the newest snapshot’s ID, which will come in handy whenever You want to go back to it again.
3. To switch to the previous chosen snapshot, use this:
   git checkout ID
   where “ID” stands for the snapshot’s hash.
4. Once You want to go back to the newest snapshot again, grab its ID from the previous git story (or from notes on the side) and repeat the step 3, then confirm by
   git checkout master

Undo changes (revert the project to the chosen snapshot for good):

1. First, You need to find out to which particular snapshot You’d like to revert Your project. Use
   git story
   to view snapshots history and find out.
2. Once You know to which snapshot You want to revert, copy its ID/hash (see Learn how to copy&paste in Cygwin).
3. To revert to this snapshot, use this:
   git reset --hard ID
   where “ID” stands for the snapshot’s hash.

Sometimes, however, what You’d like to do is to cancel a sole snapshot, not changes introduced by it. In such a case perform the instruction above, but instead of “hard” enter “soft”. Then create a new snapshot as usual (one of the previous instructions in this article).

Embrace multi-version approach.

One of incredible things which Git enables You to do, is a multi-version approach to Your work. Suppose You are a graphic artist, designing in Photoshop. Working on a new project You might want to explore every avenue of its development, or, to put it differently, You might have more than one idea for the directions it could go - and You’d like to see the results of all of them. To do so, You could multiply layers and folders within Your source .psd file in order to organize multiple versions inside it - or You may simply prefer to copy&paste the file storing Your preferred “starting point”, and then work on each version separately. Either way it’s a bit of a hassle: You need to properly name all those files in order for You to easily find the particular version You need at the time, and Your file library is growing and growing... And there is one more thing: how easily You will be able to figure out what is what - after a few months or so of not working on it?

On the contrary, let’s see what Git has to say in a similar case. Once again imagine that You have Your project .psd file containing the starting point from which You would like to develop it down multiple different roads, i.e. creating a couple of different versions, different ideas of how this project could look like. Multiple approaches, multiple styles. Before You begin to work on the first version, You save in Git the starting point... as “the starting point” (ascribing that comment to the snapshot). Now You’re ready to work on the first version.

When You want to develop the other approach to Your project (second version), the other idea out of the same starting point - You can easily switch to the beginning (the starting point) and once again start from scratch (!). Just one important thing to remember is that You need to save the first version in order not to get it lost. You could comment it as Your “First Version” - or in some much better way which could give You an idea of what it really is - especially in the long run, i.e. after months (or years?) passed by. Then You switch to Your starting point and begin the work on the second approach. Once You finish that, You repeat the same thing: save the work as Your “Second Version” (apply Your Own wording) and that’s all.

Notice that all the time You’re working with one single .psd file. Git does not create its copies for You - it just tracks what have been changed, and is able to recreate any changes made down the road. In the meantime it’s well-organized, especially given that You’ve applied comprehensive comments to each of Your versions. Now, You can switch to any of them at any given time - and Your .psd file will act accordingly, i.e. if You’ve switched to the starting point and then open Your .psd file, it will show You the starting state. If You, however, switch to the first or second version of it in Git - the .psd file will show You those particular work instead of the starting point. It’s like magic, but it does work that way :) . One single .psd file - no additional layers and folders, no file copies. Just one .psd and... travelling back and forth in time :) .

To achieve that kind of a multi-version approach in Git, I’d recommend You to use so-called “branches”. Imagine Your project’s starting point as “the root” of a tree - and Your various ideas of developing it as its independent “branches”. It’s pretty simple: first You develop a project to the point which You consider “the root”, i.e. from which You’d like it to grow toward different directions. By default, Git comes with one single branch already in place. The branch is called “master” - it’s up to You if You prefer Your First Version to sit on this branch or not. Suppose You want to reserve the master branch for the starting point - while create separate branches for the First and Second Version. You can achieve this in the following way:

Set up multi-version approach:

1. Create Your “starting point” snapshot first (one of the previous instructions in this article).
2. Create Your “First Ver.” branch:
   git branch FirstVer

Unfortunately Git allows to use only a single word as a branch name. therefore “FirstVer”...

3. Use git branch to see which branch is currently active (now it should still be “master”).
4. Switch to the newly created branch:
   git checkout FirstVer
5. You can use git branch once more to ensure that You are already on this branch.
6. From this moment forward You can develop Your project in the desired direction, saving multiple snapshots related to it. Just remember that all of this development history will be put on the “FirstVer” branch.
7. Whenever You’d like to switch back to Your project’s starting point, use this command:
   git checkout master. Once You are back on “master” branch, You can repeat the procedure, starting from the step 2, to create another branches (“SecondVer”, etc.).

Just as a reminder: note that Your project files will act accordingly to what You do within Git, i.e. to what particular snapshot and/or branch You’ve switched.

Another thing which may come in handy is the situation in which You might want to add some changes to the already existing (the newest) snapshot. In such a case the command may look like this:

git commit --amend test.txt -m "test.txt updated."

This example adds “test.txt” file to the newest existing snapshot - and overwrite its comment with “test.txt updated”.

Now, it was a pretty big chunk of knowledge - congrats if You’re still here, and wish You much fun, satisfaction and positive difference thanks to incorporating Git into Your Own workflow.