We have few teams who have used Subversion for a very long time. When they were told that Subversion is past and Git is future and that eventually we will move all our source code to Git, they weren’t really happy.
So I decided to gather a list of things which make developer’s life easier when using Git, focus being in the stuff which is real.
You are in control
- You decide when (and how) to integrate changes from others.
- You decide when and what to commit
- You decide when the commits are published to others
- You decide how your commits will look like when published
- You decide what kind of workflow you want to use
You can truly isolate your tasks
- You can do as many local branches as you want
- You can stash your changes aside (or in a branch) whenever you want
- You can start a branch from any point in the history
- There’s never need to have same repository checked out more than once on your computer
You can do things fast
- Really many operations are local
- You’re not limited by the access speed to the source code server
- If source code server is offline, you’ll be able to continue working
- Even though Git repositories come with full history, Git uses disk space sparingly. In most cases repositories on disk are smaller than equivalent Subversion repositories.
You can learn from the past
- You can really easily check out any version of any file at any time. You don’t even need access to the source code server.
- You have full history of the repository available at all times.
- You can quickly view log, blame, branch or diff whatever and whenever you want
You can easily correct your mistakes
- You can perfect your commits before you publish them. If you want, you can squeeze your 28 commits into one.
- Totally messed up everything? Just scratch everything since last update from the server and start over.
- Want to revert what you already published? No problem, you can safely revert any commit when ever.
- Want to correct type in a commit message? If you didn’t publish your commits yet, it’s easy as taking a lollipop from a child.
You have plenty of backups
- Every clone of your repository is the whole repository. If your source code server blows up, repositories can be restored really quickly.
You can focus on the most important things
- Want to ignore some files relevant only for you? Easy.
- Want to ignore certain files on all clones of your repository? Easy.
- Want to create a new repository? Shouldn’t take longer than few minutes.
- Want to publish your local branch to others? It’s one command.
A while ago I blogged about trying out a different method for sprint planning.
The sprint went well, but unfortunately I had to leave that team so I couldn’t continue my experiment for longer than one sprint. I gathered some feedback from the team members to get some idea about whether the experiment was in any way good and if it’s worth to continue it at some point.
Here are the results:
The method of planning tasks as tests-based during sprint planning session:
- Most team members thought that it wasn’t more complex than usual way of planning
- One team member thought that it was simpler than the usual way of planning
Benefits for the sprint planning part:
- Most team members thought it provokes thinking about how specific tasks will be tested
- One team member thought it makes it easier to find all tasks related to a certain story
- One team member thought that the tasks also work as acceptance criteria
- Half of the team members had to add more tasks during the sprint, because:
- wanted to make sure that some minor feature details were working ok
- the tasks in a story were too little to cover it
- Most team members thought the task granularity was good
- One team member thought the tasks were too big to be able to use them as unit-tests but too small for the story to get fulfilled. This team member wasn’t present in the planning.
Tasks as basis for the list of unit-tests:
- Most team members used the tasks as basis for their list of unit-tests
- One team member couldn’t use the tasks as basis for the list of unit tests. This person wasn’t present in the planning.
So, what did we learn from this experiment? To me this looks promising, there was no single person in the team who thought this was rubbish and shouldn’t be tried again. On the other hand, there were few team members who weren’t part of the planning session and the method wasn’t explained to them in more detail. As a result one team member thought we were trying ATDD, which wasn’t the case. Several people said one sprint is too short time to make any good conclusions and I fully agree.
Regardless of this, I have heard the team still does the sprint planning using traditional methods.
We recently decided to review all code produced by our team. By our team I mean the team which I’m currently coaching. I’m really happy that it wasn’t actually me who suggested this but it was one of the latest additions to the team. This senior developer had in his previous job used a tool called Review Board with good results. Good thing was that one of the other teams in our company had actually taken this tool in use already earlier so only things we needed to do was for all team members to signup for an account and ask Review Board admins to create a group for us.
I was really amazed, it took less than two hours to get all developers (and two TA engineers) to start using the Review Board. First reviews were made already during the same day.
We use Review Board with SVN, so the process goes like this:
- Developer does the changes to the codebase locally
- Developer runs svn diff >changes.diff in his local working directory
- Developer opens Review Board front page and clicks a button to create a new review request
- Developer writes a short explanation and uploads the diff of changes to Review Board
- All other developers get e-mail that there’s a pending review
- Developers go and read through the review request and give comments
- When enough “Ship It!” comments received, original developer commits the changes in and closes the review request
The process is still fairly light so it gets followed. In the beginning we had some problems, one developer didn’t put all his changes in RB, but committed some “obvious” changes directly. Also in the beginning the review requests were rather large so it was really laborious to review the changes. Soon people learned to not only put smaller review requests but also develop in smaller pieces.
After a while, the developer who originally came up with the idea of taking Review Board in use, started disapproving all review requests where there was code without unit tests, unless there was a very good reason for those missing. As a result, we now get decent size changes covered with unit tests. And this is good.
As I’m now working as a Scrum Master for duration of one sprint, I decided I could try some different ways of working. I recently started reading Lasse Koskela’s Test Driven, which I found really inspiring book. So, I decided that this time we’re going to write all tasks as tests. No tasks like “Implement method XYZ of the Foo API…” were allowed, instead we had tasks like “When this input is given by the user on this dialog, client should call method XYZ of the Foo API…”
Nobody objected with this style of planning, although I saw few really puzzled faces around me… Unfortunately we started the sprint with three days of Stop-the-Line due to too high (>30) amount of open defects (or mistakes as some might say) so we only got to start the actual sprint work today. Let’s see how it goes, I’ve got high hopes…
I’ve been working as a improvement coach in one of our teams for about nine months now. I’ve been mostly coaching the developers in the team, but as always the improvements usually affect the whole team. I’m fairly soon exiting the team in order to do improvements somewhere else in our company and my boss had a wonderful idea that the last two weeks I’m in the team I would work as the Scrum Master.
There are several reasons why this is a good idea:
- I haven’t been a Scrum Master in way too many years
- The previous Scrum Master of this team left on maternity leave few weeks ago
- New Scrum Master is still learning her role and could benefit in seeing how things can be done differently
- I’ve got a chance to push the team and be a hard-ass for the PdO 🙂
So far my journey as a Scrum Master didn’t start that well… Sprint planning yesterday went fairly well, we did a Test Driven Sprint Planning session, more about that later on. When I asked for “finger feedback” I got all fours except one three. Fair enough. Anyway, the reason for not that good start for the sprint is that we’ve got too many bugs open on the technology area we’re currently working. And because of that, there’s a Stop-the-Line in action until the amount of open bugs drops under bearable level. So we actually haven’t even started the sprint yet, we’re still paying quality debt introduced in the earlier sprints (by our team and several other teams as well).
One thing which I noticed right from the day one as a Scrum Master was that there’s A LOT of things to do. Most of the things are small but important so they easily take the whole day. Guess it’s goodbye for coding for the following two weeks for me.
Totally forgot this… I visited Tampere Goes Agile event last September and did a session about Git there.
I liked the event a lot and not only because it was free (as in free beer).
My session about Git was in two parts and we had a lunch in between them 🙂
During the first session I talked about what Git is, how does it compare to other version control systems and how Git helps you when you’re developing software with agile methods. During the second part we did some technical hands-on exercises with Git to see what are the benefits of using Git. I hope the attendees got what they need to convince their bosses and colleagues to start using Git.
The slides are available in Speaker Deck.
It’s almost a year since we started piloting GitHub:FI in our company. I had high hopes that by the end of 2011 everyone would be already using it. Or at least most of the people. Didn’t happen. Latest ambiguous estimate is that we could maybe get rid of most of the SVN (and CVS!) repositories by the end of this year.
We deliberately started piloting slowly and expected people to start taking GitHub in use after piloting phase was over. Didn’t happen. Those people who already had used Git earlier, were happy to start using GitHub. Several of them had already been using Git on another server… We managed to also mandate new development projects to start on Git instead of SVN and that worked reasonably well, but. Several projects were continuation of previous incarnations of same stuff, it’s anyway rare that something totally new is started. And as people were busy and projects on a tight schedule, no PdO wanted to include stories about moving repositories to Git.
Few teams spent their improvement allocation in moving the repositories to Git and started then learning new ways of working. Some hick-ups were experienced as well as some resistance from the SVN–ain’t-broken-no-need-to-fix-it -people. And yet, we’re still in the phase were few of the larger projects don’t have time and/or will to move those goddamn repositories away from SVN to a better place… And yet, using SVN hurts – it hurts every day, but apparently not enough.
I think I’m going to deliberately make all SVN related problems really visible.
And I think I’m going to try to sneak in stories about moving some repositories to Git when ever I have a chance. The battle is not over yet, it hasn’t even really started yet.
But this battle will be won. And it won’t take another year, I promise.