VRJB - Team 5

Keskkonna ülesse seadmine

Järgnevalt on toodud juhised projekti arenduskeskkonna ülesse seadmiseks. Kui keskkond on üles seatud nende juhiste põhjal, siis peaks olema väiksem tõenäosus keskkonna seadistusest tulenevate vigade ja ühilduvus probleemide tekkeks (sisuliselt on keskkonna seadistamis juhend kirjutatud erinevate probleemide põhjal, mis ilmnesid selle aine näitlike rakendustega tegeledes).

Antud projekti jaoks tundub kõige paremini sobivat täiesti iseseisva arenduskeskkonna loomine, mis tähendab, et kõik vajalikud komponendid tuleb eraldi alla laadida ja üles seada - selle tulemusel tekib keskkond, mis on võimalikult vähesel määral seotud ülejäänud süsteemiga. Samas ei ole sellise keskkonna üles seadmine üldsegi mitte keeruline, kuna midagi pole vaja installida ning pea kõik vajaliku saab teha vastavate graafiliste vormide või vahendite abil.

Vajalik tarkvara

Esiteks tuleks hankida Eclipse'i viimane EE versioon. Eclipse IDE for Java EE Developers on vajadusel kätte saadav sellelt lingilt.

http://www.eclipse.org/downloads/

Sealt saab võtta siis oma süsteemile vajaliku paki (hetkel on viimaseks Eclipse'i versiooniks 4.2).

Täiendavalt oleks kasulik alla laadida ka viimane Apache Ant (Eclipse'iga on kaasas vanem 1.7.* versioon). Ant'i saab alla laadida järgnevalt lingilt.

http://ant.apache.org/bindownload.cgi

Sealt valida näiteks ZIP vormingus fail (hetkel apache-ant-1.8.4-bin.zip).

Kuna Apache Ivy on Ant'i eraldi seisev lisa komponent, siis tuleks ka see alla laadida. Ivy saab järgnevalt lehelt.

http://ant.apache.org/ivy/download.cgi

Sealt võib samuti võtta ZIP vormingus faili, kusjuures see võiks olla with dependencies versioon (näiteks apache-ivy-2.3.0-rc1-bin-with-deps.zip).

Lisaks võiks veel eraldi alla laadida ka Apache Tomcat'i, et seda ei peaks pärast Eclipse'iga alla laadima.

http://tomcat.apache.org/download-70.cgi

Sellelt lehelt valida viimase versiooni jaotisest "Core" kategooriast näiteks zip vormingus pakk.

Tarkvara paigaldamine

Kui kõik eelnevalt mainitud pakid on alla laetud siis võiks luua ühe eraldi kausta - aine nimest tulenevalt nimetatakse seda edaspidi VRJB kaustaks - ja need kõik sinna sisse lahti pakkida. Seejuures tasub meeles pidada, et mõned programmid loovad lahti pakkimisel täiendava kausta lahti pakitud failide algse kausta ümber - seda on kasulik teada, kuna see võib tekitada segadust path'ide määramisel vajalike komponentide kaustadesse (näiteks võib jääda mulje, et viidatakse õigele kaustale, ent tegelikult on õige kaust hoopis viidatava kausta sees).

Kõikide kaustade lahti pakkimisega on Ant ja Tomcat sisuliselt installitud - edasises tuleb Ant'ile lisada Ivy ning seadistada Eclipse.

Kuna Ivy on sisuliselt nagu Ant'i lisa moodul, siis tuleb selle installimiseks kopeerida Ivy kaustast ivy*.jar fail (näiteks ivy-2.3.0-rc1.jar) Ant'i lib kausta, ning kui alla sai laetud Ivy "with dependencies" versioon (nagu eelnevalt soovitatud), siis võiks kopeerida ka kõik Ivy lib kaustas olevad failid Ant'i lib kausta - sellega ongi Ivy installitud.

Lõpuks tuleb seadistada ka Eclipse. Seejuures, enne Eclipse'i käivitamist peab Eclipse'i kaustas olevasse eclipse.ini faili lisama rea -Dfile.encoding=UTF-8 kohe -vmargs rea järele - ehk täpsustuseks, -Dfile.encoding=UTF-8 peab olema täiesti eraldi real ning järgnema -vmargs reale (-vmargs'ile järgnevad parameetrid, mis lähevad Java VM'ile).

Pärast eclipse.ini's tehtud muudatuste salvestamist võib Eclipse'i käivitada - edasine seadistamine toimub juba Eclipse'is. Seejuures tasub märkida, et üldjuhul ei pane Eclipse oma konfiguratsiooni süsteemis mujale, kui vaid oma enda kausta ja workspace kausta - tänu sellele on Eclipse'i üsna lihtne uuesti installida, kui seadistuses peaks midagi valesti minema. Eclipse'i käivitamisel tuleb määrata workspace kaust, mis võiks olla näiteks VRJB kaustas - võibolla VRJB/workspace.

Kui Eclipse on käivitunud, siis võiks esimese asjana valida Java arenduse vaate - selleks valida ülevalt menüüst Window > Open Perspective > Java. Järgmisena tuleks siis seadistada erinevad Eclipse'i komponendid - seejuures tasub veel märkida, et nii JDK, Ant'i, kui ka Tomcat'i kausta valimisel annab Eclipse'i seadete aken üleval servas väikse vea teate, kui valitud kaustast vajalikku asja ei leita (seda infot saab kasutada kausta valiku korrigeerimiseks).

JDK

Window > Preferences > Java > Installed JREs

Kontrollida, kas loetelus leidub mõni JDK, ehk jdk*, mille versiooniks on 7

Kui JDK oli loetelus olemas, siis kontrollida, et selle ees oleks linnuke

Kui JDK'd ei olnud, siis jätkata järgnevate sammudega

Klikkida paremast servast Add ning valida Standard VM

JRE home väljale valida Directory alt kaust, kus asub JDK 7

Windows'is on selleks reeglina C:\Program Files\Java\jdk*

Linux'is tasub alla laadida Sun/Oracle JDK ning valida selle kaust

Lõpuks tuleb panna linnuke lisatud JDK ette, et Eclipse seda kasutama hakkaks

Kui JDK 7't ei õnnestunud leida, siis tuleks see hankida

Linux'i jaoks saab Sun/Oracle JDK alla laadida järgnevalt lingilt (vajadusel leiab sealt ka Windows'i versiooni). Hetkel on uusimaks JDK versiooniks Java Platform (JDK) 7u7.

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Linux'i jaoks mõeldud JDK saab ilma installimata lahti pakkida suvalisse kausta (jällegi sobib selleks hästi VRJB kaust) ning viidata Eclipse'ist siis sellele kaustale.

Ant

Window > Preferences > Ant > Runtime

Classpath tab'ist valida Ant Home Entries

Klikkida paremal servas oleval nupul Ant Home

Valida kaust, kuhu Ant on lahti pakitud

Tomcat

Window > Preferences > Server > Server Runtime Environments

Klikkida paremal servas oleval Add nupul

Valida Apache alt Apache Tomcat'i viimane versioon (hetkel 7.0)

Klikkida Next nupul ning vajutada nuppu Browse

Valida kaust, kuhu Tomcat on lahti pakitud

EGit

Täiendavalt võib Eclipse'ile lisada veel ka EGit graafilise liidese Git'i kasutamiseks.

EGit'i installimiseks valida Eclipse'i menüüst Help > Eclipse Marketplace, panna otsingusse EGit ning kui otsingu tulemused on käes vajutada Install nupul.

Restart Eclipse

Kui Eclipse taaskäivitada peaks kõik seadistused paigas olema ning kogu üles seatud arenduskeskkond on kasutamiseks valmis.

Näite rakenduse käivitamine

Näite rakenduse tööle saamiseks tuleb vaid järgida samme, mis on toodud Praktikum 1 "Project set up screencast" juhendis (arvestades seejuures muidugi teistsuguse projekti kausta nimega). Screencast'is käsurealt tehtavaid asju ei ole võimalik ise käsurealt järgi teha, kui Ant ei ole süsteemi path'i seatud (eelnevates juhistes Ant'i süsteemi path'i ei pandud) - kõik muu peaks aga korralikult toimima.

Kuna näite rakendusse on pandud ka index.jsp, mis kasutaja kohe õigele rakenduse lehele edasi suunab, siis tuleb andmesisestus vorm koheselt ise ette, kui rakendus on käivitunud. Rakendus ei kontroll sisend andmeid, mistõttu võib sobimatute andmete sisestamisel saada exception'i.

Mõned märkused screencast'i osas

Kuna antud rakendusel on teeke rohkem kui üks, siis seetõttu tuleb pärast Ant'i compile target'i jooksutamist build path'i lisada kõik lib/build kaustas olevad failid.

Lihtsama seadistamise huvides on järgnevalt toodud ka screencast'i alguses projekti kausta nimele /bin asemel lisatav path.

/WebContent/WEB-INF/classes

Väike EGit juhend

Projekti võtmine GitHub'ist

Esiteks valida Eclipse'i menüüst Window > Show view > Other ja võtta loetelust Git > Git Repositories.

Ühel Eclipse'i paneelidest (tavaliselt on selleks all keskel olev paneel) avaneb Git Repositories vahekaart.

Kui Git Repositories vahekaardis pole ühtegi hoidlat (repository), siis on selles vaates kolm valiku linki - samas, hoolimata selle vahekaardi seisust on need kolm valikut alati ära toodud ka reas, mis asub vahekaarti lipikust paremal pool.

Vajutada tuleb nupul Clone a Git repository... ning avanenud aknasse sisestada järgnevad andmed - seejuures ülejäänud välju ise täita pole vaja (need täituvad ise, kui vaja).

URI: - siia tuleks kirjutada projekti GitHub'i hoidla (repository) aadress.

User: - sellele väljale kirjutada GitHub'i kasutajanimi.

Password: - see väli on GitHub'i parooli jaoks.

Pärast Next nupul vajutamist avaneb harude valiku vaade, kust võib samuti kohe Next vajutada.

Avanenud vaates tuleb valida kaust, kuhu salvestatakse hoidlast (repository) alla laetavad projekti failid - soovitavalt võiks see kaust olla VRJB keskkonna workspace'is.

/eelnev/tee/VRJB/workspace/projekt

Kõik ülejäänud seaded võib muutmata jätta ning vajutada nupul Finish, mispeale laetakse projekti failid eelnevalt määratud kausta.

Projekti lisamine Eclipse'i

Kui projekti failid said laetud VRJB kausta workspace'i (nagu varasemalt soovitatud), siis tuleks edasi järgida Praktikum 1 "Project set up screencast" juhendis toodud samme (arvestades muidugi, valitud projekti kausta nime - eelnevas näites oli selleks siis projekt).

Git menüü lisamine projektile

Pärast projekti Eclipse'i üles seadmist võiks sellele lisada ka hoidla (repository) kasutamist võimaldava menüü - seda pole küll tingimata vaja, kuna vastavaid toiminguid saab teha ka eelnevalt avatud Git Repositories vahekaardis, ent selle kasutamine võib ehk vahel mugavam olla ning lisaks veel annab see vastava projekti failidele täiendava märgistuse, lihtsustades seeläbi erinevate failide eristamist Git'i kontekstist lähtuvalt.

Git menüü lisamiseks teha projekti kaustal parem klõps, võtta menüüst Team > Share Project ja valida avanenud aknast Git ning vajutada Next ja seejärel Finish.

Kui pärast menüü lisamist teha projektil parem klõps, siis Team valiku alt avanevad erinevad Git käsud.

Järgnevates juhistes on toimingud kirjeldatud eeldusel, et projektile on parema klikiga avanev menüü lisatud - Git Repositories vahekaardis saab vastavaid valikuid avada, tehes parema kliki vastava projekti kausta nimel.

Projektis tehtud muudatuste laadimine GitHub'i

Commit

Projekti kaustal teha parem klõps ja valida avanenud menüüst Team > Commit.

Kui tegu on esimese korraga, mil sellist toimingut teostatakse, siis avaneb aken, kus tuleks täita järgnevad väljad.

User name - see on teksti string, mida hakatakse kuvama iga GitHub'i laetud faili juures (ei pea olema sama, mis GitHub'i kasutajanimi, ega olema üldse tavalise kasutajanime moodi).

User e-mail - see on e-posti aadressi kujuline teksti string (ei pea olema sama, mis GitHub'i kasutajanimi, ega isegi mitte e-posti aadress, ainus tingimus on, et see sisaldaks @ märki).

Järgmiseks avaneb aken, mille alumises osas saab valida, millised muudetud failid soovitakse sel korral kohalikku hoidlasse (repository) lisada, üleval on aga kast selgitava sõnumi lisamiseks.

Kui valikud tehtud ja selgitus kirjutatud, saab vajutada nupul Commit, aga enne seda võiks panna ka linnukese akna all vasakul nurgas olevasse kasti Push the changes to upstream - kui selles kastis on märge, siis üritatakse muudatused automaatselt GitHub'i lisada, ehk teostatakse Push operatsioon ilma vastavat akent kuvamata.

Push

Kui Commit toiming teostati ilma, et oleks pandud linnuke kasti Push the changes to upstream, siis ei ole muudetud failid veel GitHub'i laetud - nende ülesse laadimiseks on vaja teostada Push operatsioon eraldi.

Selleks, et käivitada Push operatsioon tuleb teha projektil parem klõps ja valida Team > Remote > Push.

Avaneb aken, kus võib koheselt vajutada nupule Finish.

Muudatused laetakse üles ning avaneb muudatuste raport, mille võib pärast üle vaatamist sulgeda.

Olulised märkused Push operatsiooni puhul

Pärast push operatsiooni tasub alati vaadata raporti vasakut üla nurka - kui raporti kirjelduses, või ülemises loetelus on punane märk, siis push ei õnnestunud ja muudatusi pole GitHub'i hoidlasse (repository) salvestatud. Lisaks võib push operatsioon ebaõnnestuda ka nii, et raporti asemel kuvatakse vastav teade väiksemas teate aknas. Võimalike probleemide selgitused ja lahendused on toodud järgnevalt.

"rejected - non-fast-forward"

Selle teate põhjuseks on see, et mõni teine kasutaja on vahepeal oma muudatused GitHub'i hoidlasse (repository) üles laadinud ja need pole sealt veel alla laetud.

Lahenduseks on teostada all pool kirjeldatud Pull operatsioon.

"Pushing to ... has encountered a problem. Can't connect to any repository: ... (... not authorized)" või siis "... not authorized"

See teade tuleneb sellest, et kasutajanime ja parooli ei ole sisestatud, kui neid on nõutud, või siis pole need õiged.

Probleem peaks lahenema lihtsalt õige kasutajanime ja parooli sisestamisel.

Kui probleem siiski ei lahene, võib ehk proovida ka järgmises punktis toodud juhiseid.

"Pushing to ... has encountered a problem. Can't connect to any repository: ...."

See teade (ilma mingi täiendava lisa teateta) kuvatakse siis, kui GitHub'i hoidla (repository) jaoks on kasutaja arvutis salvestatud valed andmed (reeglina on nendeks andmeteks kasutajanimi ja parool).

Probleemi lahendamiseks tuleb avada Window > Show View > Other ja võtta loetelust Git > Git Repositories.

Seejärel tuleb Git Repositories vahekaardis teha lahti vastava projekti nime all paiknevad jaotised Remotes > origin.

Sealt alt leiab kaks projekti hoidla (repository) aadressiga jaotist - mõlemal neist tuleb teha parem klõps ja valida Clear Credentials (märkuseks veel, et kui valida Change Credentials, siis tahab Eclipse sisestatud andmeid panna Secure Storage'isse ilma, et annaks võimalust sellest keelduda).

Nüüd tuleks proovida uuesti eelnevalt kirjeldatud iseseisvat Push sammu, mis sel korral nõuaks kasutajanime ja parooli sisestamist.

Kui eelnevad sammud antud probleemi ei lahendanud, siis võiks proovida neid samme uuesti pärast järgnevalt kirjeldatud sammu teostamist. Seejuures tasub tähele panna, et lahendatava probleemiga seonduva teate tekst on väga sarnane järgnevalt kirjeldatud teatele - kasulik oleks teade üle kontrollida, ega probleem ise pole eelnevalt teostatud sammude tulemusel muutunud.

Eclipse'i menüüst avada Window > Preferences > Team > Git > Configuration ja User Settings vahekaardist kustutada user key - sellega koos kustuvad ka selle alla kuuluvad andmed.

Kui probleem pole ikka lahenenud, siis tuleb arvatavasti proovida all pool kirjeldatud viimast hädapärast lahendust.

"Pushing to ... has encountered a problem. Can't connect to any repository: .... error occurred during unpacking on the remote end: index-pack abnormal exit"

Antud teade on põhjustatud sellest, et kui millalgi varem sai GitHub'ist alla laetud kasvõi üks fail, mille sisu Git mõne juba olemas oleva faili sisuga automaatselt kokku ühendas, siis peab seda kajastama antud kasutaja poolt teostatud muudatusena (sisuliselt üritab Git muutunud faile kokku ühendada automaatselt, ent alati ei pruugi see ka õnnestuda - kirjeldus sellest, mis saab siis, kui see ei õnnestu on toodud järgnevas punktis).

Probleemi lahendamiseks tuleb teostada eelnevalt kirjeldatud Commit samm - selle sammu valikul võib avaneda aken küsimusega "... Do you wish to amend the last commit?", millele vastata Yes.

Avanenud Commit Changes aknas tuleb teostada vajalikud toimingud ja seada soovitavad valikud ning vajutada nupule Commit - seejuures võib failide valiku loetelu olla ka tühi, kui kuvati eelnevalt kirjeldatud teade.

Olenevalt sellest, kas oli pandud linnuke kasti Push the changes to upstream võib osutuda vajalikuks ka eelnevas kirjeldatud Push sammu teostamine eraldi.

Kui probleem pole siiski veel lahenenud, siis jääb vist üle proovida vaid all pool kirjeldatud viimast lahendust.

Muudetud projekti laadimine GitHub'ist

Projekti kaustal teha parem klõps ja valida avanenud menüüst Team > Pull.

Muudatused laetakse alla ning avaneb muudatuste raport, mille võib pärast üle vaatamist sulgeda.

Kui raporti keskmisel real oli kirjas Result Conflicting, siis tähendab see, et Git ei suutnud vähemalt ühe alla laetud faili sisu automaatselt kokku ühendada vastava olemas oleva failiga (kui võimalik, siis tavaliselt teeb Git seesugused ühendamised automaatselt) - seega on failide sisude vahel tekkinud ühendamis konflikt, mille programmerija peab ise lahendama.

Konfliktsed osad vastavates failides märgistab Git teatava tekstilise märgistusega (<<<<<<< ======= >>>>>>>), et programmeerija saaks vastavad kohad üles leida ja ära korrigeerida - kui projektile on varasemast lisatud ka Git menüü, siis hakatakse projekti konfliktseid faile näitama vastava punase tähisega (see tähis laieneb ka mööda kaustahierarhiat üles, kuni projekti nimeni, võimaldades konfliktseid faile lihtsal viisil leida).

Pärast konfliktsete osade korrigeerimist failis tuleb korrigeeritud failil teha parem klõps ning valida Team > Add to Index, mille tulemusel vastava faili konfliktne staatus kaob (antud teguviis on muidugi kasutatav vaid siis, kui Git menüü on projektile lisatud - analoogset toimingut saab teostada ka Git Repositories vahekaardis vastava projekti all oleva Working Directory jaotise alt, ent seal ei ole konfliktse staatusega failid teistest kuidagi eristatud).

Alles siis, kui kõik konfliktsed failid on korrigeeritud ning ka korrigeerituks kuulutatud, saab need GitHub'i hoidlasse (repository) üles laadida - seejuures lähevad nendega kaasa ka kõik ülejäänud muudatused, mis enne konfliktsete failide alla laadimist veel üles laadimata olid, kusjuures nende üles laadimist ei saa vältida (niisiis tasub tähele panna, et kui varasemalt oli salvestatud mõni mitte kompileeruv fail, siis laetakse see samuti üles, ning selle tulemusel võib kogu projekt mittekompileeruvaks muutuda).

Niisiis tuleb lõpuks teostada tavalised Commit ja Push operatsioonid, et korrigeeritud failid ka GitHub'i hoidlasse (repository) jõuaksid.

Veel tasub märkida, et kui laetakse üles varasemalt konfliktsete failide korrektsioone, siis ei saa nendega kaasa panna faile, mis olid loodud konfliktide lahendamise ajal - seepärast tuleb need failid GitHub'i hoidlasse (repository) laadida täiendava Commit ja Push operatsioonide paariga (jällegi tuleb märkida, et kui nendest konfliktide lahendamise ajal lisatud failidest sõltub projekti kompileerumine, siis võib nende lisamise ununedes projekt samuti mittekompileeruvaks muutuda).

Olulised märkused Pull operatsiooni puhul

Pärast pull operatsiooni on kasulik vaadata raporti keskmist rida - kui seal on kirjas Result Merged, siis tasuks enne push toimingu teostamist teha Commit (kui seejuures avaneb aken küsimusega "... Do you wish to amend the last commit?", vastata Yes), muidu saab vastava Push toimingu puhul ühe teatava eelnevas punktis kirjeldatud vea teate (muidugi pole see viga tõsine ning on kergesti ka hilisemalt lahendatav).

"Checkout conflict with files: ...."

Antud teate põhjuseks on see, et vähemalt ühe GitHub'i hoidlas (repository) oleva faili sisu on mõne teise kasutaja poolt muudetud, ent Git ei saa seda lokaalses hoidlas (repository) oleva vastava failiga ühendada, kuna vastav fail pole selleks sobivas seisus.

Probleemi lahendamiseks tuleb esmalt teostada Commit, ja valida avanevas aknas ära vähemalt konfliktsed failid - lisaks tasub veel mainida, et kui konfliktseid faile antud loetelus poleks, siis ei oleks seda viga tekkinud.

Samas ei õnnestu muidugi konfliktseid faile veel Push operatsiooniga GitHub'i saata, kuna enne tuleb vastavad failid alla laadida ja konfliktid lahendada - lisaks tasub veel märkida, et isegi kui enne eelnevat Commit sammu teostati Pull operatsioon, ei laetud siiski alla ühtegi faili, kuna vähemalt mõned konfliktsed failid ei olnud siis veel Commit sammu läbinud.

Nüüd tuleb teostada Pull operatsioon, mis saab sel korral failid alla laadida - edasi tasub toimida vastavalt eelnevale Pull operatsiooni kirjeldavale punktile.

"Repository state: Conflicts"

See teade ilmub siis, kui üritatakse teostada Commit operatsiooni projektile, mille kõik konfliktsed failid ei ole veel ühendatuks kuulutatud.

Probleem laheneb, kui kõik konfliktsed failid ühendada ning ka ühendatuks kuulutada - neid toiminguid on lähemalt selgitatud eelnevas Pull operatsiooni kirjeldavas punktis.

Uue hoidla (repository) loomine uue projektiga

Esmalt tuleb workspace'i luua uus Java Project, mis võiks antud näites kanda nime projekt, ning vajutada projekti loomise aknas Next nupule.

Järgmises vaates on vaja Source vahekaardi all servas oleval teksti real kirjutada /bin asemele /WebContent/WEB-INF/classes (see osutub vajalikuks muidugi vaid siis kui soovitakse luua Java veebi projekti).

Kui projekt on loodud, siis teha Eclipse'is selle kaustal parem klõps, võtta menüüst Team > Share Project ja valida avanenud aknast Git ning vajutada Next.

Avanenud vaates panna linnuke üleval vasakul nurgas olevasse kasti Use or create repository....

Projektide loetelus (kus on ainult üks, äsja loodud projekt) tuleb valida hoidlasse (repository) lisatav projekt (selle ette linnukest vist teha ei saa, ent piisab ka selle projekti rea aktiivseks muutmisest).

Loetelust projekti valimise tulemusel muutub aktiivseks all vasakul servas olev Create Repository nupp, mida peab vajutama kohaliku hoidla (repository) loomiseks.

Nupu vajutamise tulemusel peaks projekti nime ees olevasse kasti tekkima linnuke ning nüüd võib vajutada Finish nupul.

Projekti failide loomine

Nüüd on projekt loodud ning projekti kausta võiks lisada .gitignore faili.

Kui soovitakse luua Java veebi projekti, siis tuleks siin kohal järgida Praktikum 1 "Project set up screencast" juhendit.

Uue projekti laadimine tühja GitHub'i hoidlasse (repository)

Selles osas tuleks toimida enamajaolt vastavalt Commit ja Push peatükkides toodud juhistele, kuigi mõningate erisustega Push sammu osas.

Esiteks tuleb Push toimingu aknas täita teatavad väljad ja vajutada seejärel Next (need väljad on kirjeldatud punktis Projekti võtmine GitHub'ist).

Teiseks peab seejärel avanevas aknas vajutama akna keskel olevat nuppu Add All Branches Spec, enne kui saab vajutada nupule Finish.

Märkuseks tuleb aga lisada, et selliselt loodud hoidlast (repository) ei ole võimalik ilma täiendava konfigureerimiseta teostada teatavaid operatsioone.

Kiireim viis nende operatsioonide teostamiseks võimaluste saamiseks Eclipse'i vahendusel on üles laetud projekti kustutamine ning sama projekti alla laadimine nii, nagu kirjeldatud punktis Projekti võtmine GitHub'ist.

Viimane lahendus probleemide puhul

Kui projektiga seonduvaid Git'i probleeme ei õnnestu siiski kuidagi lahendada, tuleks teha vastava projekti kaustast koopia (seda muidugi juhul, kui seal on olulisi faile, milledes leiduvaid muutusi soovitakse hiljem GitHub'i hoidlasse (repository) laadida) ning see kaust lihtsalt näiteks Eclipse'i kaudu ära kustutada (ehk siis teha projektil parem klõps, valida Delete ning panna linnuke kasti Delete project contents on disk).

Juhul kui järgiti eelnevalt toodud juhiseid projekti loomisel, siis kaovad koos projekti kaustaga ka kõik Git hoidla (repository) andmed, kuna need olid projekti kaustas (kui lahti on Git Repositories vahekaart, siis tuleks vajutada selle üla servas olevat Refresh nuppu, et muudatused ka seal kajastuks). Lisaks võib olla kasu ka sellest, kui Eclipse'i menüüst avada Window > Preferences > Team > Git > Configuration ja User Settings vahekaardist kustutada user key, millega koos kustuvad ka kõik selle all olevad andmed (need tuleb siis pärast uuesti sisestada).

Nüüd tuleks siis projekt uuesti GitHub'ist alla laadida, lisada sellele vajalikud muudatused (juhul kui neid muidugi oli) ja see siis koos muudatustega uuesti GitHub'i üles laadida - loodetavasti ei teki seejuures enam probleeme.

Lingid

http://www.vogella.com/articles/Git/article.html

http://www.vogella.com/articles/EGit/article.html

http://wiki.eclipse.org/EGit/User_Guide

http://git-scm.com/doc

https://help.github.com/