1.5 Ekkomenci - Unua Momento uzante Git Setup

Nun ke vi havas Git sur via sistemo, vi volas fari kelkajn aferojn por personecigi vian Git medio. Vi devas fari tion nur unu fojon; ili devos algluita ĉirkaŭ inter ĝisdatigojn. Vi povas ankaŭ ŝanĝi ilin en ajna momento por kuri tra la komandoj denove.
Git venas kun ilo nomita git config kiu permesas akiri kaj starigis agordo variabloj kiuj kontrolas ĉiujn aspektojn de kiel git aspektas kaj funkcias. Tiuj variabloj povas esti stokita en tri malsamaj lokoj:

• /etc/gitconfig dosieron: Enhavas valoroj por ĉiu uzanto en la sistemo kaj ĉiuj iliaj deponejoj. Se vi pasas la opcion --system al git config , legas kaj skribas de dosiero specife.
• ~/.gitconfig dosiero: Specifaj por via uzanto. Vi povas fari Git legi kaj skribi al la dosiero specife aprobante la --global opcion.
• config dosiero en la git dosierujo (te .git/config ) de ajna deponejo vi aktuale uzas: Specifaj al tiu sola deponejo. Ĉiu nivelo anstataŭigas valoroj en la antaŭa nivelo, tiel valoroj en .git/config trumpetsono tiuj en /etc/gitconfig .

Sur Vindozo sistemoj, Git serĉas la .gitconfig dosiero en la $HOME dosierujo ( C:\Documents and Settings\$USER por multaj homoj). Ĝi ankaŭ daŭre serĉas / etc / gitconfig, kvankam ĝi estas relativa al la MSys radikon, kiu estas kie vi decidas instali Git sur via Fenestra sistemo kiam vi kuros la instalilo.

via identeco

La unua afero vi devus fari kiam vi instalas Git estas fiksi vian salutnomon kaj retadreso. Tiu estas grava ĉar ĉiu Git commit uzas tiun informon, kaj ĝi estas immutably bakita en la interna pasas ĉirkaŭe:

 $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com 

Denove, vi devas fari tion nur unu fojon, se vi pasos la --global opcion, ĉar tiam Git ĉiam uzi tiun informon por io vi fari en tiu sistemo. Se vi volas nuligi tiun kun malsama nomo aŭ retadreso por specifaj projektoj, vi povas kuri la komando sen --global opcion kiam vi estas en tiu projekto.

via Redaktoro

Nun ke via identeco estas instalita, vi povas agordi la defaŭlta tekstoredaktilo kiu estos uzita kiam Git bezonas vin tajpi en mesaĝo. Defaŭlte, Git uzas vian sistemon defaŭlta redaktilo, kiu estas ĝenerale Vidis aŭ Vim. Se vi volas uzi malsaman tekstoredaktilo, kiel Emakso, vi povas fari la sekvajn:

 $ git config --global core.editor emacs 

Via Diff Ilo

Alia utila eblo vi volas agordi estas la defaŭlta malsamoj ilo uzi por solvi kunfandi konfliktoj. Diru vi volas uzi vimdiff:

 $ git config --global merge.tool vimdiff 

Git akceptas kdiff3, tkdiff, Meld, xxdiff, emerĝi, vimdiff, gvimdiff, ecmerge kaj opendiff kiel valida merge iloj. Vi povas ankaŭ agordi kutimo ilo; vidu Ĉapitro 7 por pliaj informoj pri fari tion.

Kontrolanta Via Agordo

Se vi volas kontroli la agordojn, vi povas uzi la git config --list ordonas al listo ĉiujn agordojn Git povas trovi en tiu punkto:

 $ git config --list user.name=Scott Chacon user.email=schacon@gmail.com color.status=auto color.branch=auto color.interactive=auto color.diff=auto ... 

Vi povas vidi klavoj plurfoje, ĉar Git legas la saman ŝlosilon el diversaj dosieroj ( /etc/gitconfig kaj ~/.gitconfig , ekzemple). Tiukaze, Git uzas la lastan valoron por ĉiu sola ŝlosilo vidas.
Vi povas kontroli ankaŭ kio Git pensas specifa ŝlosilo valoro estas tajpante git config {key} :

 $ git config user.name Scott Chacon 

prev | sekva

1.4 Ekkomenci - Instalado de Git

Ni enir uzante iuj Git. Unuaj aferoj unua-vi devas instali ĝin. Vi povas akiri ĝin laŭ kelkaj manieroj; la du plej gravaj estas instali ĝin el fonto aŭ instali ekzistantan pakaĵon por via platformo.

Instalado de Fonto

Se vi povas, ĝi estas ĝenerale utila instali Git de fonto, ĉar vi ricevos la plej freŝa versio. Ĉiu versio de Git emas inkluzivi utilaj UI plibonigoj, do akiranta la plej lastan version Ofte la plej bona vojo, se vi sentas komfortan kompilita programaro de fonto. Estas ankaŭ la kazo ke multaj Linukso distribuoj enhavas tre malnova pakoj; do se vi estas sur tre supren-ĝis-dato distro aŭ abonas backports, instalante el fonto povas esti la plej bona veto.
Instali Git, Vi devas havi la jenajn bibliotekoj kiuj Git dependas: kirlo, zlib, OpenSSL, expat kaj libiconv. Ekzemple, se vi estas sur sistemo kiu havas yum (kiel Fedora) aŭ apt-get (kiel ekzemple Debiano bazita sistemo), vi povas uzi unu el tiuj komandoj instali ĉiujn dependecojn:

$ yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev 

Kiam vi havas ĉiujn necesajn dependaĵojn, vi povas iri antaŭen kaj ekpreni la plej lastan ekrankopion de la Git retejon:

 http://git-scm.com/download 

Tiam, kompili kaj instali:

 $ tar -zxf git-1.6.0.5.tar.gz $ cd git-1.6.0.5 $ make prefix=/usr/local all $ sudo make prefix=/usr/local install 

Post ĉi estas farita, vi povas ankaŭ preni Git tra Git mem aktualigojn:

 $ git clone git://git.kernel.org/pub/scm/git/git.git 

Instalado en Linukso

Se vi volas instali Git sur Linukso tra binara instalilo, vi povas ĝenerale fari ĝin tra la baza pako-mastrumado ilo kiu venas kun via distribuo. Se estas en Fedora, vi povas uzi yum:

 $ yum install git-core 

Aŭ se vi estas sur Debian-bazita distribuo kiel Ubuntu, provu apt-get:

 $ apt-get install git 

Instali en Mac

Estas du facilaj manieroj por instali Git sur Mac. La plej facila estas uzi la grafikan Git instalilo, kiun vi povas elŝuti el la SourceForge paĝo (vidu Figuro 1-7):

 http://sourceforge.net/projects/git-osx-installer/ 

Figuro 1-7. Git OS X instalilon. La alia grava maniero estas instali Git tra MacPorts ( http://www.macports.org ). Se vi havas MacPorts instalita, instali Git per

 $ sudo port install git-core +svn +doc +bash_completion +gitweb 

Vi ne devas aldoni ĉiujn ekstraj, sed vi verŝajne volas inkludi + SVN se vi iam devus uzi Git kun Subversion deponejoj (vidu Ĉapitro 8).

Instali en Windows

Instali Git sur Vindozo estas tre facila. La msysGit projekto havas unu el la pli facile instalado proceduroj. Simple elŝuti la instalilon exe dosiero de la GitHub paĝo, kaj ruli ĝin:

 http://msysgit.github.com/ 

Post ĝi estas instalita, vi havas ambaŭ komando-linia versio (inkluzive de SSH kliento kiu eniros oportunan poste) kaj la norma GUI.

prev | sekva

1.3 Ekkomenci - Git-Bazoj

Do, kio estas Git en malmultaj vortoj? Tio estas grava sekcio por sorbi, ĉar se vi komprenas kion Git estas la bazfaktoj de kiel ĝi funkcias, tiam uzanta Git efike verŝajne estos multe pli facila por vi. Kiel vi lernas Git, provi malbari vian menson de la aferoj vi eksciu pri aliaj VCSs, kiel Subversion kaj Perforce; faranta helpos vin eviti subtila konfuzo uzinte la ilo. Git tendencas kaj pensas informo multe malsama ol tiuj aliaj sistemoj, kvankam la uzanto-interfaco estas sufiĉe similaj; kompreni tiujn diferencojn helpos malhelpi vin de fariĝanta konfuzita dum uzante ĝin.

Instantáneas, Ne Diferencoj

La ĉefa diferenco inter Git kaj ajna alia VCS (Subversion kaj amikoj inkluzivita) estas la maniero Git pensas liajn datumojn. Koncepte, la plej multaj aliaj sistemoj stokas informon kiel listo de dosiero bazita ŝanĝoj. Tiuj sistemoj (CVS, Subversion, Perforce, Bazaro, kaj tiel plu) pensas de la informo kiun ili tenas kiel aro de dosieroj kaj la ŝanĝoj faritaj al ĉiu dosiero en la tempo, kiel ilustrita en Figuro 1-4.

Figuro 1-4. Aliaj sistemoj emas stoki datumojn kiel ŝanĝoj al bazo versio de ĉiu dosiero. Git ne pensi aŭ stoki liajn datumojn tiamaniere. Anstataŭe, Git pensas liaj datumoj pli kiel aro de instantáneas de mini dosiersistemo. Ĉiufoje vi faras, aŭ savi la staton de via projekto en Git, ĝi esence faras foton de kio ĉiuj viaj dosieroj aspekti tiumomente kaj stokas referenco al tiu instantánea. Esti efika, se dosierojn ne ŝanĝis, Git ne stokas la dosieron denove-nur ligilon al la antaŭa identa dosier ĝi jam stokitaj. Git pensas liaj datumoj pli kiel Figuro 1-5.

Figuro 1-5. Git tendencas datumoj kiel instantáneas de la projekto dum tempo. Tio estas grava distingo inter Git kaj preskaŭ ĉiuj aliaj VCSs. Ĝi faras Git rekonsideri preskaŭ ĉiu aspekto de versitena ke plejparto de aliaj sistemoj kopiita el la antaŭa generacio. Tio igas Git pli kiel mini dosiersistemo kun iuj nekredeble potencaj iloj konstruita sur supro, prefere ol simple VCS. Ni esploros iuj de la avantaĝoj vi gajnos per pensado de via datumo tiel kiam ni kovras Git branĉantaj en Ĉapitro 3.

Preskaŭ Ĉiu Operacio Ĉu Loka

Plej operaciojn en Git nur bezonas lokajn dosierojn kaj rimedoj por funkcii - ĝenerale neniuj informoj bezonas de alia komputilo en via reto. Se vi uzis al CVCS kie plej operacioj havas tiun reton latencia superkape, tiu aspekto de Git faros vin pensas ke la dioj de rapido benas Git kun unworldly potencoj. Ĉar vi havas la tutan historion de la projekto Dekstre sur via loka disko, plej operacioj ŝajnas preskaŭ instantánea.
Ekzemple, tralegi la historion de la projekto, Git ne bezonas iri al la servilo por preni la historion kaj vidigi ĝin por vi-ĝi simple legas gxin rekte el via loka datumbazo. Tiu signifas ke vi vidu la projekto historio preskaŭ senprokraste. Se vi volas vidi la ŝanĝojn enkondukitaj inter la nuna versio de la dosiero kaj la dosiero monato, Git povas rigardi la dosieron monato kaj fari lokan diferencon kalkulo, anstataŭ devi aŭ petu fora servilo fari ĝin aŭ tiri pli malnovan version de la paĝo el fora servilo fari ĝin loke.
Ĉi tio ankaŭ signifas ke ekzistas tre malmulta povas fari se vi estas senkonekta aŭ malŝalti VPN. Se vi akiras sur aviadilo aŭ trajno kaj volas fari iom laboron, vi povas fari feliĉe ĝis vi atingos retan konekton al alŝuto. Se vi iros hejmen kaj ne povos atingi vian VPN kliento funkcias taŭge, vi povas ankoraŭ labori. En multaj aliaj sistemoj, farante tiel estas aŭ neebla aŭ dolora. En Perforce, ekzemple, vi povas fari tre kiam vi ne estas konektita al la servilo; kaj Subversion kaj CVS, vi povas redakti dosierojn, sed vi ne povas fari ŝanĝojn al via datumbazo (ĉar via datumbazo estas offline). Tio povas ŝajni kiel granda interkonsento, sed vi povas esti surprizita kiom granda diferenco povas fari.

Git Has Integreco

Ĉio en Git estas check-sumita antaŭ ĝi estas stokita kaj tiam estas referita sub tiu checksum. Tio signifas ke ne eblas ŝanĝi la enhavon de ajna dosiero aŭ dosierujo sen Git sciante pri ĝi. Tiu funcionalidad estas konstruita en Git ĉe la plej malaltaj niveloj kaj estas integrita al lia filozofio. Vi ne povas perdi informon en trafiko aŭ akiri dosieron korupteco sen Git povi detekti ĝin.
La mekanismo kiu Git uzas por tiu checksumming nomiĝas SHA-1 hash. Jen 40-signoĉeno formita de deksesumaj karakteroj (0-9 kaj-f) kaj kalkulita surbaze de la enhavo de dosiero aŭ dosierujo strukturo en Git. A SHA-1 hash aspektas io tiamaniere:

24b9da6552252987aa493b52f8696cd6d3b00373 

Vi vidos tiujn haketvaloro ĉie en Git ĉar ĝi uzas ilin tiel. Fakte, Git stokas ĉiu ne de dosiernomo sed en la Git datumbazo direccionable per la hash valoro de ĝia enhavo.

Git Ĝenerale Nur Aldonas Datumoj

Kiam vi faros agojn en Git, preskaŭ ĉiuj el ili nur aldoni datumojn al la Git datumbazo. Ĝi estas tre malfacila akiri la sistemon por fari ion kiu ne undoable aŭ fari ŝin viŝi datumojn iamaniere. Kiel en ajna VCS, vi povas perdi aŭ fuŝas ŝanĝojn vi ne faris ankoraŭ; sed post fari ekrankopion en Git, estas tre malfacile perdi, speciale se vi regule puŝi vian datumbazon al alia enciklopedio.
Tio igas uzi Git ĝojo ĉar ni scias ke ni povas sperti sen la danĝero de severe tedas aĵojn. Por pli detala rigardi kiom Git stokas liajn datumojn kaj kiel vi povas rekuperi datumojn kiu similas perdita, vidu "Sub la Kovriloj" en Ĉapitro 9.

La Tri ŝtatoj

Nun atentu. Tiu estas la ĉefa afero memori pri Git se vi volas ke la resto de via lernado procezo iri glate. Git havas tri ĉefajn statojn ke viaj dosieroj povas loĝi en: farita, modifita, kaj enscenigis. Farita signifas ke la datumoj estas sekure stokitaj en via loka datumbazo. Modifita per kiuj vi ŝanĝis la dosieron sed ne faris ĝin al via datumbazo ankoraŭ. Enscenigita rimedoj kiujn vi markis modifitan bildon en lia aktuala versio, por iri en vian proksima commit instantánea.
Tio kondukas nin al la tri ĉefaj sekcioj de Git projekto: la Git dosierujo, la labordosierujon kaj la surscenigo areo.

Figuro 1-6. Laborante dosierujo, surscenigo areo, kaj git dosierujo. La Git dosierujo estas kie Git stokas la metadatos kaj objekto datumbazo por via projekto. Tiu estas la plej grava parto de Git kaj estas kio estas kopiita kiam kloni deponejo de alia komputilo.
La laboranta dosierujo estas ununura kaso de unu versio de la projekto. Tiuj dosieroj estas tirita el la kunpremita datumbazo en la Git dosierujo kaj metitaj en disko por vi uzi aŭ modifi.
La surscenigo areo estas simpla dosiero, ĝenerale enhavita en via Git dosierujo, kiu stokas informojn pri kio iros en vian proksima commit. Ĝi estas iam referis al kiel la indekso, sed ĝi igas normon por rilati al ĝi kiel la surscenigo areo.
La baza Git laborfluo iras io kiel tio:

1. Vi modifi dosierojn en via laboranta dosierujo.
2. Vi enscenigi la dosierojn, aldoni fotojn de ili por via surscenigo areo.
3. Vi oni faras, kiu prenas la dosierojn kiel ili estas en la surscenigo areo kaj tendencas ke instantánea konstante al via Git dosierujo.

Se apartan version de dosiero estas en la git dosierujo, ĝi estas konsiderita aktiva. Se ĝi estas redaktita sed estis aldonita al la surscenigo areo, ĝi enscenigas. Kaj se ĝi estis ŝanĝita kiam ĝi Taksis sed ne estis enscenigita, ĝi estas modifita. En ĉapitro 2, vi lernos pli pri ĉi tiuj ŝtatoj, kaj kiel vi povas aŭ utiligi ilin aŭ preterpasi la enscenigita parto tute.

prev | sekva

1.2 Ekkomenci - Mallonga historio de Git

Kiel pluraj el la bonaĵoj en la vivo, Git komenciĝis per iom da kreiga detruo kaj granda disputego. La Linux-kerno estas malfermitkoda programaro-projekto kun sufiĉe granda amplekso. Dum la plejparto de la tempo en kiu la Linux-kerno estis prizorgata (1991–2002), oni disdonis ŝanĝojn al la programaro kiel flikaĵoj kaj enarkivigitaj dosieroj. En 2002, la Linux-kerna projekto komencis uzi proprietan DVCS-sistemon nomita BitKeeper.
En 2005 rompiĝis la rilato inter la komunumo, en kiu la Linux-kerno evoluis, kaj la komerco firmao, kiu produktis BitKeeper; oni senvalidigis la senkostan statuson de la ilo. Tio instigis la komunumo, kiu sin prizorgis pri la evoluo de Linux—kaj precipe Linus Torvalds, la kreinto de Linux—krei sian propran ilon, tenante en la menso la lecionojn, kiujn ili lernis, dum ili uzis BitKeeper. Jen kelkaj el la celoj de la nova sistemo:

• Rapideco
• Simpla desegno
• Bona subteno por nelinea konstruado (miloj da paralelaj branĉoj)
• Tute disa sistemo
• La ebleco rendimente trakti grandajn projektojn (kiel la Linux-kerno) koncerne al rapideco kaj datuma grandeco

Ekde ĝia naskiĝo en 2005, Git evoluis kaj prenkreskiĝis por esti facile uzebla kaj tamen reteni tiujn dekomencaj ecoj. Ĝi estas nekredeble rapida; ĝi estas tre rendimenta kun grandaj projektoj; kaj ĝi havas bonegan branĉigan sistemon por nelinea konstruado (vidu Ĉapitro 3).

prev | next

1.1 Ekkomenco - Pri versikontrolo

Pri versikontrolo

Kio estas versikontrolo, kaj kial vi okupiĝas pri tio? Versikontrolo estas sistemo kiu registras ŝanĝojn pri dosiero aŭ dosieraro dumtempe por ke vi povas revoki specifajn versiojn poste. Por la ekzemploj en ĉi tiu libro vi uzos programaran fontkodon kiel la dosierojn versikontrolataj, sed vere vi povas fari ĉi tion pri ĉiaj dosieroj komputilaj.
Se vi estas grafika aŭ retpaĝa dizajnisto kaj vi volas manteni ĉiujn versiojn de bildo aŭ aspekto (kion vi nepre volu), versikontrola sistemo (VCS, version control system en la angla) estas tre uzinda. Ĝi permesas al vi remeti dosierojn al antaŭa stato, kompari ŝanĝojn laŭ la tempo, vidi kiu ŝanĝis ion kio povus kaŭzi problemon, kiu enmetis problemon kaj kiam, kaj pli. Uzante VCSon kutime ankaŭ signifas ke se vi ion fuŝigis aŭ se vi perdis dosierojn, vi facile povas reiri. Aldone, vi ĉion tion havas kun malmulta superŝarĝo.

Lokaj versikontrolaj sistemoj

La preferata versikontrola metodo de multaj homoj estas kopii dosierojn al alia dosierujo (se ili prudentas, kun hormarko en la nomo). Ĉi tiu maniero estas tre komuna ĉar ĝi estas tiom simpla, sed ĝi ankaŭ malfermas la pordon al multaj problemoj. Facilas forgesi en kiu dosierujo vi estas kaj akcidente skribi al la malĝusta dosiero aŭ kopii super dosierojn pri kiuj vi tion ne volis.
Por ataki tiun problemon, programistoj antaŭlonge disvolvis lokajn VCSojn kiuj havis simplan datumbazon kiu mantenis ĉiujn ŝanĝojn al dosieroj sub kontrolo (vidu bildon 1-1).

Bildo 1-1. Diagramo pri loka versikontrolo. One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the rcs command when you install the Developer Tools. This tool basically works by keeping patch sets (that is, the differences between files) from one change to another in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.

Centralized Version Control Systems

The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2).

Figure 1-2. Centralized version control diagram. This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client.
However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything.

Distributed Version Control Systems

This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3).

Figure 1-3. Distributed version control diagram. Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.

prev | next

Unua Cxapitro - Ekkomenco

Ĉi tiu ĉapitro ni komencas pri Git. Ni komencos je la komenco, klarigante iom da fonaj aferoj pri versikontrolaj iloj, poste pluiros pri kiel ruligi Git en via sistemo kaj fine kiel agordi por ekuzi ĝin. Je la fino de ĉi tiu ĉapitro vi estos komprenante kial Git ekzistas/funkcias, kial vi uzas ĝin kaj vi estos pretiĝinta por ekuzo.

prev | next

Pro Git book, written by Scott Chacon and Ben Straub (in esperanto language)

Book

1st Edition (2009)

The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com.

1. 1. Ekkomenci

   1. 1.1 Pri versikontrolo
   2. 1.2 Mallonga historio de Git
   3. 1.3 Git Basics
   4. 1.4 Installing Git
   5. 1.5 First-Time Git Setup
   6. 1.6 Getting Help
   7. 1.7 Summary

2. 2. Bazoj de Git

   1. 2.1 Ekhavi Git-deponejon
   2. 2.2 Registri ŝanĝojn en la deponejo
   3. 2.3 Viewing the Commit History
   4. 2.4 Undoing Things
   5. 2.5 Working with Remotes
   6. 2.6 Tagging
   7. 2.7 Tips and Tricks
   8. 2.8 Summary