With multiple programmers, you can probably expect a versioning system, perhaps a centralized versioning system like SVN or Perforce. With that system, each programmer would make his/her changes and then would check in his/her changes into the repository. From there, the programmer’s peers would review the code.

What’s the problem with this system? The code is already checked in. The pressure is on the peers to ensure that the code is good, and it’s likely that this could slip through the cracks. I mean, those peers are working on getting 10 features complete themselves.

Enter Git

Well, I would argue that Git has a strong code review process built right in. This is due to the process of how distributed version control works.

Programmer A creates a fork of the master project. A makes his changes and commit his code; however, the code is committed to his local repository and not the master origin. This is because A does not have write access to that repository.

A has to contact programmer B, who has write access. A tells B that he should pull his code. Since B has to pull the code, this means that B has to review the code coming in.

It’s this workflow that promotes code review. Now that’s not to say that you can’t do code reviews in a centralized model, it just fits a little better in a distributed model

Ticgit takes a simplistic approach to issue tracking as Lighthouse has done. You can comment, add tags, manage the state of an issue, save views, and change to whom an issue is assigned. There is still more planned, like keeping track of milestones and syncing the tickets to Lighthouse.

As mentioned, there is a web interface to ticgit; however, it wasn’t my cup of tea. So I have started my own web interface, tiwatchtower. It’s still a little rough around the edges, but I would love to hear any thoughts.

Conclusion

So far, I like it and it’s exciting to see how git can be pushed. It’s great for keeping track of things that are on my mind without worrying about having to setup trac or having to use up a Lighthouse project. It’s simple, effective, and worth a look at.

I bought a Flex book to, well, teach myself Flex. The book right now is taking me though one application and is building it out piece by piece. So I began to think: “What if I just keep track of all my changes through git?”

For one, Flex is nice because it’s all XML, so that makes revision tracking fairly easy. Also, git is very easy to get started because you don’t have to do any server setup. Just issue a git init command and get going. Then after each chapter, I can tag the repository for posterity’s sake. And I have to say, it’s been great to see how the code has changes, especially since Flex Builder generates code.

That’s one thing I love about git, and mercurial, it’s so easy to start using version control for even the littlest of tasks.