Scott is an expert software developer with over 30 years experience, specialising in education, automation and remote data.
Git is great, I have about 100 repos, but I do still find issues that I would like to talk about.
This particular issue is about particular patterns, in particular the pattern where a change is a single commit...
This document is still a work in progress...
The pattern which is a single change is a single commit is quite common. Even before projects used version control, and specifically distributed version control, patches where submitted to the gate keeper. And effectively that patch was a feature or bug fix.
Git allows this to be done easily and distributed. Projects have a gate keeper will pull commits that could be hundreds of lines long, possibly even 1000s.
The point of a commit is that it is a thing - maybe a bug fix, maybe a new feature or enhancement.
There is many advantages to this model:
But there is a few things that I miss...
My bug fix may take days, perhaps even weeks. Where do I backup to? Normally I would just 'push' to a repository, possibly even my local 'bak' repository I usually attach.
But that only works if I commit.
By committing regularly, you keep all changes. If you accidentally delete that file, you can get it back. What if you just accidentally deleted a section of code, and didn't notice for a few days.
My model is to commit very regularly, often multiple times in an hour.
I work on multiple computers. This is pretty normal, sometimes like me people moving between laptop and desktop, others that have to move to special machines for testing (e.g. testing off site, or in the field).
We work across computers, across the world, we often can't have a shared disk todo collaborative or agile development. Easy way to work around this is to use a VCS to share and some form of real time communication (IRC, Jabber, Skype ...).
However you might commit something that does not even compile. This would break the one time commit. Even if it does compile, it is probably not a complete fix.
By committing regularly (see Local backup) I keep my decision making. Those changes can be important for finding out why something was done.
Good development technique, especially agile development, suggests that you fix up and clean up code as you go. If you see a missing comment, fix it. If you find a spelling mistake fix it. Maybe you just wanted to clean up white space or unnecessary compiler directives.
In a shared repository, such as SVN, each time someone commits, that is it forever. This has lots of down sides, but also one up side. It is a transaction, there forever. But with GIT, you can overwrite changes, changing history. So transactions are lost.
One model is to:
Another way to squash feature branch into another branch