Bersoff’sFirst"Law"
Nomatterwhereyouareindevelopingasystem
thesystemwillchange&youwillfind
continueddesiretochangeit
¨ CreatedbyLinusTorvaldsforLinuxdevelopment¤ Needwasgreatandsojoinedbymanykerneldevelopers¤ Usedbypopularhostingservicesbecauseofstability¤ SinceLinuxchangesarefrequent,speedemphasized¤ Namemeaningless(Linussuggestsmultiplepossibilities)
¨ Specialmachinesorconnectionsarenotrequired¤ Sharedrepohostedbyanydevicerunningservercode¤ Alsonothingspecialtocreatingsharedrepo¤ Onlyrequirementisrepoexistsandteamcanbegin
Pulloften
¨ pullrequestscancreatemergeconflicts¤ Local&remotechangespreventautomatedmerging¤ Notjustchangetosamefile;mustbeonsameline¤ Doyourbesttoavoidthis;reallypainfultosolve¤ Noeasysolution–needtomakechangesmanually¤ Manualoverrideneededforgittomoveforward
¨ Communicationhelps,BUTPULLEARLYANDOFTEN!
SharingProblems
¨ Sharingcodedifficultwhenaddingordebugging¤ Wantallbenefitsofversioncontrolasyoudevelopcode¤ Oncechangescomplete,needtopushchangesback¤ Wantanyupdates&limitconflictsforlaterpush¤ Yourhalf-completedcodeshouldnotpollutecolleagues
ARepoSharingStory
¨ Susanbusyfixingbackendofsystem¤ Overhauloptimizescode&improvesperformance…¤ …oritwillonceSusancompletesthiswork¤ Mayfirstmakesystemunstable(orworse)untildone¤ Majortasktakesweeks,sopushestoavoidlosingwork
¨ Johntinkeringonfrontendmakingcosmeticchanges¤ ButgetsSusan'scodeinpull&seesnewsideeffects¤ Assumeshecausedchangesandstartslookingforbugs¤ Experienceisofbugswhichappear&getfixedrandomly
ARepoSharingStory
¨ Susanbusyfixingbackendofsystem¤ Improvesperformance,butonlyoncecomplete
¨ Johntinkeringonfrontendmakingcosmeticchanges¤ Seessystemandtriestoassociatehischangeswithbugs
ARepoSharingStory
¨ Hugeargumentaboutpushingincompletecode¤ Avoidissuebyhavingallsavelocallyuntilworkcomplete
ARepoSharingStory
¨ Hugeargumentaboutpushingincompletecode¤ Avoidissuebyhavingallsavelocallyuntilworkcomplete
¨ Badscenario:loseweeksofworkwithdiskfailure
ARepoSharingStory
¨ Hugeargumentaboutpushingincompletecode¤ Avoidissuebyhavingallsavelocallyuntilworkcomplete
¨ Worsescenario:everyonepushesweekofdeadline
ARepoSharingStory
¨ Hugeargumentaboutpushingincompletecode¤ Avoidissuebyhavingallsavelocallyuntilworkcomplete
¨ Worsescenario:everyonepushesweekofdeadline
ARepoSharingStory
¨ Hugeargumentaboutpushingincompletecode¤ Avoidissuebyhavingallsavelocallyuntilworkcomplete
¨ Worstscenario:everyonepushesdayofdeadline
ManuallyFixingConflict
¨ Rejected(best)option:gothroughfiles&fixmerges¤ Firstneedtofindalllocationswhereconflictsoccurred¤ Thenwillhavetochoosewhichsetofchangestokeep¤ Fixallerrorscreatedbydeletinglinesyoudonotwant
"Solving"Conflict
¨ Worstoption:deleteproject,reclonerepo,&update¤ Makecertaintosavefilesbeforeprojectisdeleted¤ Thenwillhavetorecreatechangesincleanrepo¤ Fixallerrors&bugscreatedasyoumergechanges
SolvingConflict“Source”
¨ Jerkoption:usegit push --forcetooverwrite ¤ Praythatnobodywantedchangesonremoterepo¤ Helpgroupfindnewmemberswhodonothateyou
BranchingtotheRescue!
¨ Branchesenablesbetterapproachtotheseproblems
¨ Allowsdeveloperstoworkindependently¤ Changesandupdatessavedinversioncontrol¤ Totalindependencenotneeded;otherscanjoinbranch
¨ Alwaysabletoprunebranchandrejoinrestofteam¤ Noteverythingissuccess,simplifyif/whenbackingout
¨ Mergeintodevelopwhenworkiscomplete¤ Shouldnotinterferewithothers;yougotitworking!
BenefitsofBranching
¨ Branchesenablesbetterapproachtotheseproblems
¨ Allowsdeveloperstoworkindependently¤ Changesandupdatessavedinversioncontrol¤ Totalindependencenotneeded;otherscanjoinbranch
¨ Alwaysabletoprunebranchandrejoinrestofteam¤ Noteverythingissuccess,simplifyif/whenbackingout
¨ Mergeintodevelopwhenworkiscomplete¤ Shouldnotinterferewithothers;yougotitworking!
masteranddevelop
¨ Twostandardbranchescommonlyusedingit
master develop¨ Stable,releasedcodeonly
¨ Tagsusedtomarkeachversionreleased¤ Makesfindingclient's
releaseeasy
¨ Neveruseddirectly
¨ Storescompletedfeatures
¨ Codeaddedwhenreadyforinclusioninrelease¤ Sprintcompletiongauged
byhowwellitpassestests
¨ Sourceofbranchesduringeachsprint
masteranddevelop
¨ Twostandardbranchescommonlyusedingit
master develop¨ Stable,releasedcodeonly
¨ Tagsusedtomarkeachversionreleased¤ Makesfindingclient's
releaseeasy
¨ Neveruseddirectly
¨ Storescompletedfeatures
¨ Codeaddedwhenreadyforinclusioninrelease¤ Sprintcompletiongauged
byhowwellitpassestests
¨ Sourceofbranchesduringeachsprint
DevelopingEachFeature
¨ Startworkonuserstoryasbranchoffdevelop ¤ Storysinglefeature–smallestunitformerging¤ Withbranchingcheap,allowsforsimplemanagement¤ Finehavingmanybranchesdevelopedinparallel
FeatureKeyPoint
¨ Startworkonuserstoryasbranchoffdevelop ¤ Storysinglefeature–smallestunitformerging
DevelopingEachFeature
¨ Some,butnotall,featuresworkasexpected¤ Avoidconfusion:prunebranchesfromfailedideas¤ Afteracceptancetestspass,mergeintodevelop ¤ Beforemergingbranch,canalsoperformcodereview¤ Nevercommittomaster;avoidbugsgettingthrough
Commitmessages
¨ Manydifferentconventions¤ All(butyours)sucks;choosewhogetstocomplain
¨ Makemessagesmeaningfulanddescriptive¤ Youwillbethankedbyyourfutureself&contributors¤ Criticalforbiggerprojectssincevitalhistoryofwork
GoodCommitMessages
¨ Summarizeschangessooutsiderscanunderstand¤ Recreateprojecthistoryknowingwhychangeneeded¤ Whatwaschangedincluded,sotheyfollowthinking¤ Alsoexplainoutcomes:anyside-effectsshouldbenoted
¨ Listofchangesimportantforotherstoknow,too¤ Becausesomecommitsverybig,thiscangetlong¤ Detailedinformationrarelyneededbycasualreviewer¤ Butautorecorded;doNOTincludeinmessage