When we moved to git, the only way to do this was to use inotify, and monitor files, then script up the git commands to push it to a remote server.
This gave us a number of useful development features.
-
Infinite rollback (tried to solve a problem two ways, and the first turned out better, easy to go back to that stage - without having to remember to flag it as 'first effort')
-
Crash proof and disk failure proof - local failures in drives, accidental deletions, or bad upgrades did not result in us loosing any code changes.
-
Good tracking data for our customer billing (see person X was working on that file then, see all the changes..)
-
Rollback support in our GUI builder, that does not have much in the way of 'undo', and can easily delete stuff by accident..
Over the last 5 years we moved away from using
gnome seed/Gtk to using
Vala+Gtk, mainly as support for seed has diminished over the years, and introspection occasionally has a few issues with null pointers, and unavailable features. Also I rather enjoy coding in vala...
The first effort just continued the save->commit idea, and until recently this worked out fine, our commit history was not really reviewed by anyone externally, and our code review was based on a end of day diff by email. So thousands of 'changed' commit messages where fine.
However when I envisioned the gitlive concept, it was always a stop-gap solution to do deliver real commit messages. When one of our client's requested that we start using real commit's I was reluctant to sacrifice all the advantages of gitlive, so I started to look at how we could complete the gitlive development, and start producing real commits.
Work in progress branches.
The basic solution to this has been to integrate our ticketing (and eventually our time sheet system) into the gitlive system. So that we have a relatively seamless flow from task to commit. Our workflow generally looks like this.
- Request received from client, by email or meetings.
- Ticket is created. This is done in our integrated management portal normally, however the gitlive application can now create tickets.
-
Developer (or me) starts working on a ticket, looks at the requirements, and starts editing some code to address the issue
-
at this point Gitlive detects a modification on the codebase, and requests that we specify which ticket is being worked on (or create one if necessary)
-
gitlive then creates a WIP branch so that all subsequent changes are made to that branch
-
when that task is complete, or when we think it's done.. then we can select 'merge' from the gitlive pulldown menu - which then shows us the proposed commit (diff between the branch and master), along with the original ticket so we can review it. You can also flag something as a partial fix (leave the ticket open) - or just flip back to master to work on another issue without merging.
-
if you close a ticket, we merge (squash) the code into master, write the correct commit log, and mark the ticket as resolved (needing review)
-
testing done, ticket closed or re-opened .. and we can push to live or carry on improving.
This works fine for us, obviously in larger organizations, some kind of push request mechanism might work. But it takes quite a bit of hastle out of working with Git and our ticketing system. And has improved our git history on the projects.
Since the commit's now include references to the ticket's that they fix, our ticketing system (a loose fork of mtrack), can now show the diff's done to fix each ticket - improving our QA code review on closing tickets as well..
Since we have over 100 git repositories on our server, we also added a few fun tools to manage the locally checked out repositories, and monitor what state they are compared to the remotes - push/pull, reset show diff's etc.
In theory the code could be tweaked to work with github or other git hosting systems with API's. as it's all quick simple and clear. My next task is to integrate it better into our time management system.
git repo: http://git.roojs.org/?p=gitlive;a=summary
git checkout http://git.roojs.org/gitlive
