lecture 7: version control - cse442

48
LECTURE 7: VERSION CONTROL CSE 442 – Software Engineering

Upload: others

Post on 17-Nov-2021

4 views

Category:

Documents


0 download

TRANSCRIPT

LECTURE7:VERSIONCONTROLCSE442–SoftwareEngineering

Bersoff’sFirst"Law"

Nomatterwhereyouareindevelopingasystem

thesystemwillchange&youwillfind

continueddesiretochangeit

¨  CreatedbyLinusTorvaldsforLinuxdevelopment¤ Needwasgreatandsojoinedbymanykerneldevelopers¤ Usedbypopularhostingservicesbecauseofstability¤ SinceLinuxchangesarefrequent,speedemphasized¤ Namemeaningless(Linussuggestsmultiplepossibilities)

¨  Specialmachinesorconnectionsarenotrequired¤ Sharedrepohostedbyanydevicerunningservercode¤ Alsonothingspecialtocreatingsharedrepo¤ Onlyrequirementisrepoexistsandteamcanbegin

HowWorks…

HowWorks…

Membersagreetocollaborateusing(central)sharedrepository

HowWorks…

EVERYmemberofgrouphaspersonalrepository

HowWorks…

EVERYmemberofgrouphaspersonalrepositoryAND

separatesetoffilestoworkon

Using

Usereditsfile

Using

Usereditsfile

&commitssavestolocalrepo

Using

Canthenpush

changesto

remoterepo

Using

Otherscanlaterpull (&update)

changestotheirrepos

Using

Helpfultobeonlatestupdatetoedit

Using

Helpfultobeonlatestupdatetoedit

Using

Buteveryone

canedit

Using

Buteveryone

canedit&

commit

Using

Onlyrepoonlatestreleasecan

push,however

Using

Ifeditsareonsamelineas

commit,pull

createsconflict

Pulloften

¨  pullrequestscancreatemergeconflicts¤ Local&remotechangespreventautomatedmerging¤ Notjustchangetosamefile;mustbeonsameline¤ Doyourbesttoavoidthis;reallypainfultosolve¤ Noeasysolution–needtomakechangesmanually¤ Manualoverrideneededforgittomoveforward

¨  Communicationhelps,BUTPULLEARLYANDOFTEN!

GitKeyConcept#1

Avoidmergeconflicts

PULLFREQUENTLY

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

BranchingKeyConcept#1

NeverDirectlyCommittomaster

StandardModelforgit

developmergedbackintomasteronlywhencodereadyforrelease

DevelopingEachFeature

¨  Startworkonuserstoryasbranchoffdevelop ¤ Storysinglefeature–smallestunitformerging¤ Withbranchingcheap,allowsforsimplemanagement¤ Finehavingmanybranchesdevelopedinparallel

FeatureKeyPoint

¨  Startworkonuserstoryasbranchoffdevelop ¤ Storysinglefeature–smallestunitformerging

BranchingKeyConcept#2

EveryUserStoryStartsAsBranchOffdevelop

DevelopingEachFeature

¨  Some,butnotall,featuresworkasexpected¤ Avoidconfusion:prunebranchesfromfailedideas¤ Afteracceptancetestspass,mergeintodevelop ¤ Beforemergingbranch,canalsoperformcodereview¤ Nevercommittomaster;avoidbugsgettingthrough

MergeHistoryComparison

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

CommitMessageKeyConcept

Describewhatcommitdoes

TagSINGLEtasktohelpexplain

WHYthismatters

IfYouHaveTooMuchTime

PictureofGoodgit Repo

gitCommandStructure

SecrettoGit