This long weekend I seriously decided to dive to Git. Everybody heard about a distributed revision control system, but most were afraid to try this Linus Torvalds child. I was one of that guy, despite the fact I used more that 10 GitHub projects before and watching for many projects.
- Yes, it’s hard to start and not easy to use.
- It’s not like SVN, but really about another way to think.
- Sometime processes seem too complicated, but after a few days everything looks reasonable.
- There were two reasons I kept going to this for a while.
Open source
More and more project I use from Github. Sometimes I improve them, but don’t “commit” back to the main repository. So morally I wasn’t paying tribute to developers and the community (beautiful community graph). As well in practice I have problems with updating modified sources with new one from GitHub. No chance for merging. It’s just unnatural.
Own source
The second problem I felt for past months is about organizing own classes. Since we started to work together as a team It’s become really actual to build a common repository with reused classes.
 |
| SVN to Survive |
But now it’s a discomfort in collaboration inside the team and over the #iphonedev community. For example, two weeks ago we created 3 (THREE!) version of the same application to verify ideas. It was about MGSplitViewController from GitHub. Moreover after we found a solution it’d be better to commit changes to the GitHub, but didn’t do that. Yes, it’s our own fault, but tools have to encourage to go right way. Now we have two different own splitControllers in two projects. It’s representative, isn’t it?
- I started to read about GIT from several articles. It helped me (ru) to understand what problems people have and how they solve them. Read a few in russian.
- Then I started to try. After many hours of experiments I felt a lack of theoretical knowledge, so I found a good book – Pro Git. It’s translated to many languages, e.g. russian.
- Move common Categories and low level classes to common repository. E.g. AvatarManager, Settings, LocatorSingleton, etc.
- Determine and move base classes to the repository. I always had a few, but they migrate from project to project and have 10 different versions. This wrong way of source organizing makes more and more discomfort. Examples: BaseViewController with messages, delegates and activity indicator; ListViewController, SearchViewController, etc.
- Then move more powerful Controllers that are very similar and used more than twice. E.g. SplashController, SynchTableViewController and NearOnMapsController. Such controllers should be refactored and tested. That’s why it’s actual for active project only. And it’s better to extract them during a real project or refact two old projects simultaneously.
The challenge is to support own lib with numerous branches, often pushes (commits to the origin/master) back and keeping other branches fresh. The terminal is only way to manage this process because it’s easy to be confused by a list of 5–10 branches of one lib for different projects, if you see them all together in a GUI client. Maybe we’ll think about automatic update mechanism.
- learn to work in Git team and product style and test knowledge on next customer project
- determine more common classes and organize Alterpaly library (APLib) as a GitHub private project
- to convert inner SVN projects to GitHub and implement Git’s submodules
- open the Alterplay Lib to the iPhone development community part by part
