Thursday, 28 January, 2016 UTC
Summary
For a long time I thought of Git as just another version control system, and I did not care much about its distributed nature, and that it does not require a remote repository.
Almost a year ago I started to use Git to complement some of my workflows, as it can easily add version controlling with all it’s niceness to almost anything that involve files on the local disk.
In a nutshell it goes as follows:
- 1) Decide to do something, for example, write an outline for a meeting, or sketch a HTML page with some Javascript to pilot a function or use-case.
- 2) Navigate to the relevant directory in the terminal. (A subfolder of documents or a directory in a local webserver.)
- 3) Init a new gitrepo (git init) and commit (git add ., git commit -m “init”) the appropriate files to it. Maybe even set up a gitignore file if needed. Now we finished setting up local versioning support for all the important files.
- 4) Start working. Commit files to mark important changes in the history whenever it makes sense.
It’s really simple as it only takes a few short commands to set it up, and gives tight control about file versions, thus it’s making easy to track progress.
I use it for quite some time for various ad-hoc tasks, and I it came handy in many situations.
For example if I have to quickly hack together a proof of concept about an idea, usually I spend a lot of time trying different things. This way usually a lot of stuff turns out as a dead end. Versioning saved me many times when I added another feature, as I could always revert to the last working version. And finally when I got a part working, I can see and review what lines are changed in the attempt, and history serve as a worklog to overview what’s accomplished. More importantly, there is an easy way to remove all unnecessary code that left from trying different things.
I did not use this myself yet, but it seems interesting to try various concepts in different branches, then switch between and compare the results easily rather than to mess around with copies of whole directories.
Another thing I use Git locally is to track memos. When I prepare for a meeting, I usually make an outline about the important subjects that I’d like to discuss. In the meeting I just write the answers into the relevant parts of the outline. By committing the file before the meeting, I can see every important information in the Git diff, while I can still see the whole document that provides context. This is also very helpful with items that span across multiple meetings.
It’s really convenient to integrate this version controlling to most workflows, since many editors support Git. And even if Your favourite tool would not do so, versioning can be easily controlled from the terminal. Most of the time I use it this way, with really few Git commands:
- add and commit to add history entry
- stat and diff to review changes since last commit
These tools are usually more than enough, but since I use Vim for general text editing I try to take advantage of the plugins released to aid Git. I find vim-gitgutter the most beneficial, as it displays recently changed lines in the sidebar.
I use it to quickly skim over the file to see fresh modifications.
The other plugin I use is the famous fugitive.vim, a wrapper that makes many commands more convenient to use from Vim. While I prefer to use the terminal, this plugin can greatly simplify interactions with Git related to the currently edited file. In my simple workflow I tend to use the following commands:
- Gwrite to add current file to index
- Gcommit commit changes
- Gread to revert current file to the last committed state
- Gstatus to check working tree status
- Glog to see commit messages related to the current file
Git is a powerful general purpose tool to track file changes, and it does not necessarily need a remote repository to work. It can be easily integrated with many tools, and it’s easy to use from the command line. Because of these it’s a good candidate to aid various local workflows with versioning support.