Jag lägger upp mina stories i pivotal och prioriterar genom drag and drop. Jag gör även en snabb estimering, som pivotal använder för att planera vad som borde hinnas med i sprinten baserad på teamets tidigare utvecklingshastighet.

När det är dags för mig att jobba på något så skriver jag:

➜ git feature
Retrieving latest features from Pivotal Tracker…
Story: Revert account link in prefs / account
URL: http://www.pivotaltracker.com/story/show/11125931
Updating feature status in Pivotal Tracker…
Enter branch name (will be prepended by 11125931) [feature]: revert-account-link
Creating 11125931-revert-account-link branch…
Switched to a new branch ‘11125931-revert-account-link’
/Users/matti/projects/fooproj git:(11125931-revert-account-link) ✗

Det hämtar den senaste storyn från trackern och skapar en ny lokal feature branch. Fördelen med feature branches är att man alltid har en körbar version i master trunken. Man kan enkelt jobba på flera features samtidigt genom att ha dom i olika branchar. Man håller de lokala brancharna ajour med master branchen via sk. rebasing.

Man committar delstegen man gör på storyn. När man är klar så skriver man
➜ git finish

Det markerar storyn som klar i pivotaltracker som håller koll på hur lång tid det tog att genomföra storyn jämfört med hur komplex man hade estimerat den till att vara = din utvecklingshastighet). Sen tar den bort feature branchen och mergar in i master trunken.

Det blir inte enklare än så här. Det är agilt utan skitsnack. Jag har bara kört på soloprojekt hittils, men det borde ju vara ännu bättre i team.

Sedan några år tillbaka så finns det en ny typ av versionshanteringssystem som till skillnad från de gamla är decentraliserade. Exempel på de här nya systemen är Git, Mercurial och Bazaar. I ett decentraliserat versionshanterinssystem (DVCS) så har varje användare en lokal kopia av hela projektets versionshistorik. Det betyder INTE att man inte kan ha ett centralt repository som alla i projektet arbetar mot, och det leder heller inte till anarki. Med ett DVCS kan man göra allt som man kan med Subversion, och dessutom en massa andra saker.

För mig är de viktigaste fördelarna med DVCS lokala commits och lokala branchar. En vanlig pattern i Subversion-land är att man på stora projekt inte vågar checka in kod eftersom det kan sabba bygget för resten av laget. Det leder till att man sitter och kodar på sin nya feature under en längre tid och väntar med att checka in tills det är testat och klart – vilket ibland kan ta lång tid. Under tiden man arbetar på sin feature så kan man hämta hem ny kod från sina medarbetare via svn update, men man har ingen versionshistorik på sin nya feature. Ett DVCS råder bot på det här problemet genom att tillåta lokala commits. När man är klar pushar man upp sina ändringar till den centrala servern, antingen som en enda commit eller med hela lokala versionshistoriken för featuren.

Under tiden som man arbetar på sin nya oincheckade feature så är det väldigt vanligt att man inte kan köra resten av systemet på sin lokala maskin eftersom det är en enda stor byggarbetsplats. Med ett DVCS som Git så är det busenkelt att skapa lokala branchar. Vana Git-användare gör det flera gånger om dagen! För varje ny feature som man börjar arbeta på så skapar man en lokal branch. När man är nöjd med featuren så mergar man tillbaka det till sin lokala trunk innan man pushar upp den till det centrala repot. Man kan även brancha i Subversion, men det är krångligare så det brukar man bara göra vid större releaser.

Förutom lokala commits och branchar så finns det en massa andra anledningar till att gå över till ett DVCS. Det känns helt enkelt mer kraftfullt och modernt. Dessutom så vågar jag hävda att det gör ditt liv som utvecklare roligare, för det ger dig en ny frihetsgrad.

Jag vet inte om Git eller någon av de andra DVCSerna kommer slå igenom på bred front, men inom open source så har de redan gjort det. Jquery, Linux, Rails, Drupal och andra stora projekt kör eller är på väg till Git. Det som talar emot Git är att det är lite svårare att lära sig än Subversion. Git används av de flesta via kommandotolken, och det är tveksamt om man kan få med sig .NET och Java-utvecklarna tills att det finns bra integration med deras utvecklingsmiljöer. På sistone har det kommit GUI-frontar både till Windows och OSX.

Jag har använt Git sen ett tag tillbaka och jag är fast! Jag känner inte till någon som har lärt sig Git och som har valt att gå tillbaka till Subversion. Som tur är så kan jag köra Git även om alla andra i mitt projekt vill fortsätta använda Subversion. Det finns nämligen en git-svn brygga som är väldigt enkel att använda. Med den så kör jag Git lokalt fast den centrala Subversion servern ser mig som en vanlig subversion klient.

Fortfarande inte övertygad om att Git är bättre än Subversion? Läs det här!: Why Git is better than X och Git Svn Comparison.

Här är några länkar jag rekommenderar er att utforska om ni vill lära er mer om Git:
Git Community Book
Pro Git Book
Effectively using Git with Subversion
A Successful Git Branching Model

require 'set'
unless ARGV.length == 1
   puts "usage: display_colors_in_css.rb [css_file]"
   exit 1
end

css = IO.read(ARGV[0])
color_refs = css.scan /\#[0-9A-Fa-f]{3,6}/
color_set = Set.new( color_refs.map(&:upcase) )
puts color_set.to_a.sort