4.8 Git sur la servilo - GitLab

GitWeb estas sufiĉe simplista tamen. Se vi serĉas pli moderna, plene prezentita Git servilo, ekzistas kelkaj pluraj malfermita fonto solvoj tie ke vi povas instali anstataŭe. Kiel GitLab estas unu el la pli popularaj, ni kovras instalo kaj uzante gxin kiel ekzemplo. Tio estas iom pli kompleksa ol la GitWeb opcio kaj probable postulas pli bontenado, sed estas multe pli plene prezentis opcion.

Instalado

GitLab estas datumbazo subtenata apliko retejo, tiel ĝia instalado estas iom pli implikitaj ol iuj aliaj git serviloj. Feliĉe, ĉi tiu procezo estas tre bone dokumentita kaj apogis.
Estas kelkaj metodoj vi povas plutrakti instali GitLab. Akiri ion kaj kurante rapide, vi povas elŝuti virtuala maŝino bildo aŭ unu-alklako instalado de https://bitnami.com/stack/gitlab kaj tweak la agordo por kongrui kun via aparta medio. Unu bela tuŝo Bitnami inkludis estas la salutekrano (Montrita tajpante alt- →); ĝi diras vin la IP kaj defaŭlta salutnomon kaj pasvorton por la instalita GitLab.

Figuro 4-2. La Bitnami GitLab virtuala maŝino salutekrano.

Por io alia, sekvi la gvidon en la GitLab Komunumo Eldono README, kiuj troveblas ĉe https://gitlab.com/gitlab-org/gitlab-ce/tree/master . Tie vi trovos helpon por instali GitLab uzante Chef receptoj, virtuala maŝino sur Cifereca Oceano kaj RPM kaj DEB pakoj (kiu, de ĉi tiu skribado, estas en fazo beta). Ekzistas ankaŭ "neoficiala" gvidon sur akiranta GitLab kurante kun nenorma operaciumoj kaj datumbazoj, plene manlibro instalado skripton, kaj multaj aliaj temoj.

Administrado

GitLab administrado interfaco aliras super la TTT. Simple montri vian foliumilon por la gastignomon aŭ IP kie GitLab estas instalita kaj ensaluti kiel administranto uzanto. La defaŭlta uzantnomo estas admin@local.host kaj la defaŭlta pasvorto estas 5iveL!fe (vi estos petata ŝanĝi kiam vin eniras ĝin). Ensalutinte, klaku "Admin areo" ikono en la menuo ĉe la supra dekstra.

Figuro 4-3. La "Admin areo" eron en la GitLab menuo.

Uzantoj

Uzantoj en GitLab estas rakontas ke respondas al homoj. Uzanto kontoj ne havas multajn komplekseco; ĉefe estas kolekto de persona informo alfiksis ensaluti datumoj. Ĉiu uzantokonto venas kun nomspaco, kiu estas logika grupiĝo de projektoj kiuj apartenas al tiu uzanto. Se la uzanto jane havis projekton nomita project , tiu projekto url estus http: // servilo / jane / projekto .

Figuro 4-4. La GitLab uzanto administrado ekrano.

Forigado uzanto povas esti farita en du manieroj. "Blokante" uzanto malhelpas ilin arbohakanta en la GitLab ekzemple, sed ĉiuj el la datumoj sub tiu uzanto nomspaco estos konservita, kaj faras subskribita kun tiu uzanto retadreson ankoraŭ referencas al sia profilo.
"Detrui" uzanto, aliflanke, tute forigas ilin el la datumbazo kaj dosiersistemo. Ĉiuj projektoj kaj datumojn en ilia nomspaco estas forigita, kaj neniu grupoj posedas ankaŭ estos forigitaj. Tio estas evidente multe pli permanenta kaj detrua agado, kaj liaj uzoj estas maloftaj.

grupoj

A GitLab grupo estas arigo de projektoj, kune kun datumoj pri kiom uzantoj povas aliri tiujn projektojn. Ĉiu grupo havas projekton nomspaco (sammaniere ke uzantoj fari), do se la grupo training havas projekton materials , lia url estus http: // servilo / trejnado / materialojn .

Figuro 4-5. La GitLab grupo administrado ekrano.

Ĉiu grupo estas asociita kun numero de uzantoj, ĉiu el kiuj havas nivelon de permesoj por la grupa projektoj kaj la grupo mem. Tiuj intervalas de "Gasto" (aferojn kaj babili nur) por "Owner" (plena kontrolo de la grupo, liaj membroj kaj liaj projektoj). La tipoj de permesoj estas tro multnombraj por listo tie, sed GitLab havas helpema ligilo sur la administrado ekrano.

projektoj

A GitLab projekto malglate korespondas al sola git-deponejo. Ĉiu projekto apartenas al sola nomspaco, ĉu uzanto aŭ grupo. Se la projekto apartenas al uzanto, la posedanto de la projekto havas rektan kontrolon super kiu havas aliron al la projekto; se la projekto apartenas al grupo, la grupo de uzanto-nivelo permesojn ankaŭ efektiviĝas.
Ĉiu projekto havas ankaŭ videbleco nivelo, kiu kontrolas kiu legrajtojn por ke projekto paĝoj kaj deponejo. Se projekto estas Privata, la projekto posedanto devas eksplicite doni aliro al specifaj uzantoj. Interna projekto estas videbla por ajna ensalutantojn uzanto kaj Publika projekto estas videbla por neniu. Notu ke tiu kontrolas ambaŭ git "fetch" aliro tiel kiel aliro al la TTT UI por tiu projekto.

hokoj

GitLab inkludas apogon por hokoj, ambaŭ ĉe projekto aŭ sistemo nivelo. Por iu el ili, la GitLab servilo plenumos HTTP POST kun iuj priskriba JSON kiam adekvataj okazaĵoj okazas. Tiu estas granda vojo por konekti git deponejoj kaj GitLab ekzemple al la resto de via evoluo aŭtomatigo, kiel CI serviloj, babilejoj, aŭ deplojo iloj.

bazaj Uzado

La unua afero vi deziras fari kun GitLab estas krei novan projekton. Ĉi tio sukcesas klakante la "+" ikono sur la ilobretaj. Vi estos petita por la projekto nomo, kiun nomspaco ĝi devus aparteni al kaj kio lia videbleco nivelo devus esti. Plejparto de kio vi ĉi tie specifitaj ne permanenta, kaj povas esti re-adaptitaj poste tra la agordojn interfaco. Alklaku "Krei Projekto", kaj vi faris.
Iam la projekto ekzistas, vi probable volas konekti ŝin kun loka Git-deponejo. Ĉiu projekto estas alirebla super HTTPS aŭ SSH, ĉu de kiu povas esti uzata por agordi Git fora. La URLoj estas videblaj ĉe la pinto de la projekta hejmpaĝo. Cxar ekzistantan loka deponejo, tiu komando kreos fora nomita gitlab al la gastigita loko:

  $ Git fora aldonu gitlab https: //server/namespace/project.git 

Se vi ne havas lokan kopion de la deponejo, vi povas simple faru jene:

  $ Git clone https: //server/namespace/project.git 

La ttt UI disponigas aliron al pluraj utilaj vidoj de la deponejo mem. Ĉiu projekto ĉefpaĝon montras freŝa aktiveco kaj ligiloj kune la supro kondukos vin al opinioj de la projekto dosierojn farante ensaluti.

laborante Kune

La plej simpla maniero de labori kune en GitLab projekto donante alia uzanto rekta puŝo aliro al la git-deponejo. Vi povas aldoni uzanton al projekto de iranta al la "membroj" sekcio de tiu projekto agordojn kaj asociante la nova uzanto kun aliro nivelo (la malsama aliro niveloj estas diskutitaj iom en Grupoj ). Donante uzanto aliron nivelo de "Developer" aŭ supre, ke uzanto povas premi interna kaj branĉoj rekte al la deponejo senpune.
Alia, pli decoupled vojon de kunlaboro estas per uzo kunfandi petoj. Tiu trajto ebligas ajna uzanto kiu povas vidi projekto kontribui al ĝi en kontrolita maniero. Uzantoj kun rekta aliro povas simple krei branĉon, puŝo faras al ĝi, kaj malfermi merge peto de sia branĉo reen en master aŭ ajna alia branĉo. Uzantoj kiuj ne havas puŝo permesojn por deponejo povas "forko" ĝin (krei lian propran kopion), puŝo kompromitas al tiu ekzemplero, kaj malfermi merge peto de sia forko al la ĉefa projekto. Tiu modelo permesas la proprietulo por esti en plena kontrolo de kio iras en la deponejo kaj kiam, dum permesante kontribuojn de untrusted uzantoj.
Kunfandi petoj kaj demandoj estas la ĉefaj unuoj de longeviva diskuto en GitLab. Ĉiu merge peto permesas linion post linio diskuto de la proponita ŝanĝo (kiu apogas malpeza speco de kodo recenzo), tiel kiel ĝenerala entuta diskuto fadeno. Ambaŭ povas esti atribuita al uzantoj, aŭ organizitaj en mejloŝtonojn.
Tiu sekcio estas koncentrita ĉefe en la Git-rilataj trajtoj de GitLab, sed kiel matura projekto, ĝi havigas multajn aliajn funkciojn por helpi vian teamon laboro kune, kiel projekto vikioj kaj sistemo bontenado iloj. Unu avantaĝo al GitLab estas kiu, fojo la servilo instalita kaj kuranta, Vi malofte bezonas tweak agorda dosiero aŭ aliri la servilon tra SSH; plej administrado kaj ĝenerala uzado povas esti plenumita tra la en-retumilo interfacon.

prev | sekva

4.7 Git sur la servilo - GitWeb

Nun ke vi havas bazan legado/skribo kaj legado nur aliro al via projekto, povas esti utile starigi simplan ttt-bazita visualizador. Git venas kun CGI skripto nomita GitWeb ke foje uzita por tiu.

Figuro 4-1. La GitWeb ttt-bazita uzulinterfaco.

Se vi volas kontroli kio GitWeb aspektus kiel por via projekto, Git venas kun komando pafi supren provizoran Ekzemple se vi havas malpezan servilo en via sistemo kiel lighttpd aŭ webrick . Sur Linukso maŝinoj, lighttpd ofte instalita, do vi eble povas akiri ĝin kuri tajpante git instaweb en via projekto dosierujo. Se vi uzas Mac, Leopardo venas antaŭinstalitaj kun Ruby, Do webrick povas esti via plej bona veto. Komenci instaweb kun ne-lighttpd traktilo, vi povas ruli ĝin kun la --httpd opcion.

  $ Git instaweb --httpd = webrick
[2009-02-21 10:02:21] INFO WEBrick 1.3.1
[2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universal-darwin9.0] 

Kiu funkciigas kiel httpd servilo haveno 1234 kaj tiam aŭtomate komenciĝas retumilo kiu malfermas sur tiu paĝo. Ĝi estas sufiĉe facila viaflanke. Kiam vi faris kaj volas fermi la servilo, vi povas kuri la saman ordonon per la --stop eblo:

  $ Git instaweb --httpd = webrick --stop 

Se vi volas lanĉi la retinterfaco sur servilo tutan tempon por via teamo aŭ por malferma fonto projekto vi retprovizanton, vi devas agordi la CGI skripto por esti utilita de via normala retservilo. Kelkaj Linukso distribuaĵoj havas gitweb pako ke vi povu instali tra apt aŭ yum , tiel vi eble volas provi ke unue. Ni trairu instali GitWeb permane tre rapide. Unua, vi bezonos akiri la Git fontkodo, kiun GitWeb venas kun kaj generi la kutimo CGI skripto:

  $ Git clone git: //git.kernel.org/pub/scm/git/git.git
 $ cd git /
 $ Fari GITWEB_PROJECTROOT = "/opt/git" prefix = / usr gitweb
 SUBDIR gitweb
 SUBDIR ../
make[2]: `GIT-VERSION-FILE' is up to date.
 GEN gitweb.cgi
 GEN static/gitweb.js
 $ Ŝvitas cp -Rf gitweb / var / www / 

Rimarku ke vi devas diri la komando kie trovi vian Git deponejoj kun la GITWEB_PROJECTROOT variablo. Nun, Vi devas fari Apache uzo CGI por tiu skripto, por kiu vi povas aldoni VirtualHost:

 <VirtualHost *:80>
 ServerName gitserver
 DocumentRoot /var/www/gitweb
 <Directory /var/www/gitweb>
 Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
 AllowOverride All
 order allow,deny
 Allow from all
 AddHandler cgi-script cgi
 DirectoryIndex gitweb.cgi
 </Directory>
</VirtualHost> 

Denove, GitWeb povas utili kun ajna CGI aŭ Perl kapabla retservilo; se vi preferas uzi ion alian, ĝi ne devus esti malfacila starigi. Ĉe tiu punkto, vi devus povi viziti http://gitserver/ vidi vian deponejoj rete.

prev | sekva

4.6 Git sur la servilo - Smart HTTP

Ni nun aŭtentikigita aliro kvankam SSH kaj unauthenticated aliro tra git:// , sed ekzistas ankaŭ protokolo kiu povas fari ambaŭ samtempe. Starigadon Smart HTTP estas esence nur ebligante CGI skripto kiu estas provizita kun Git nomita git-http-backend sur la servilo. Ĉi CGI legos la padon kaj titolaj sendis per git fetch aŭ git push al HTTP URL kaj determini se la kliento povas komuniki super HTTP (kiu estas vera por ĉiu kliento ekde versio 1.6.6). Se la CGI vidas ke la kliento estas inteligenta, ĝi komunikos smartly kun ĝi, alie ĝi falos reen al muta konduto (tia estas retrokongrua por legas kun malnovaj klientoj).
Ni iras tra tre baza agordo. Ni povas tion supren kun Apache kiel la CGI servilo. Se vi ne havas Apache instalinstrukciojn, vi povas fari ĝin sur Linukso skatolo kun io tiamaniere:

  $ sudo apt-get install apache2 apache2-utils
 $ a2enmod CGI alias env reverki 

Ĉi ankaŭ ebligas la mod_cgi , mod_alias , mod_env kaj mod_rewrite moduloj, kiuj estas ĉiuj bezonataj por ĉi labori konvene.
Vi ankaŭ devas agordi la Uniksa uzanto grupo de la /opt/git dosierujojn al www-data tiel via retservilo povas read- kaj skribi-aliro la deponejoj, ĉar la Apache ekzemple kurado la CGI skripto estos (defaŭlte) esti kurante kiel tiu uzanto:

  $ Chgrp -R Www-data / opt / git 

Ni tuj devas aldoni kelkajn aferojn al la Apache agorda kuri la git-http-backend kiel la traktilo por nenio venanta en la /git vojon de via retservilo.

 SetEnv GIT_PROJECT_ROOT /opt/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/ 

Se vi ellasas GIT_HTTP_EXPORT_ALL Mediovariablo do Git nur utilos por unauthenticated klientoj la deponejoj kun la git-daemon-export-ok dosieron en ili, same kiel la Git-demono faris.
Fine vi volas diri Apache permesi petoj al git-http-backend kaj fari skribas legalizita iel, eble kun auth bloko tiel:

 RewriteEngine On
RewriteCond %{QUERY_STRING} service=git-receive-pack [OR]
RewriteCond %{REQUEST_URI} /git-receive-pack$
RewriteRule ^/git/ - [E=AUTHREQUIRED]

<Files "git-http-backend">
 AuthType Basic
 AuthName "Git Access"
 AuthUserFile /opt/git/.htpasswd
 Require valid-user
 Order deny,allow
 Deny from env=AUTHREQUIRED
 Satisfy any
</Files> 

Kiu postulos vin krei .htpasswd dosiero enhavanta la pasvortoj de ĉiuj validaj uzantoj. Jen ekzemplo de aldonanta "schacon" uzanto al la dosiero:

  $ Htpasswd -c /opt/git/.htpasswd schacon 

Estas tunoj de manieroj havi Apache autenticar uzantoj, vi devos elekti kaj efektivigi unu el ili. Tiu estas nur la plej simpla ekzemplo ni povus elpensi. Vi ankaŭ preskaŭ certe volas agordi tion, super SSL por ĉiuj ĉi tiuj datumoj estas ĉifrita.
Ni ne volas iri tro ege malsupren la kuniklotruon de Apache agorda specifaj, ĉar vi bone povus uzi alian servilo aŭ havas malsamajn autenticación bezonoj. La ideo estas ke Git venas kun CGI nomita git-http-backend ke kiam alvokebla faros cxiujn intertraktado por sendi kaj ricevi datumojn sur HTTP. Ne apliki ajnan identigan mem, sed kiuj povas facile esti kontrolita ĉe la mantelo de la retservilo kiu alpreĝas lin. Vi povas fari tion kun preskaŭ ajna CGI-kapabla retservilo, ke vi iru kun kiu vi scias plej bone.

noto

Por pli informo sur agordi autenticación en Apache, kontrolu la Apache dokumentojn tie: http://httpd.apache.org/docs/current/howto/auth.html

prev | sekva

4.5 Git sur la servilo - Git Daemon

Sekva ni starigis demono servanta deponejoj super la "Git" protokolo. Tio estas komuna elekto por rapida, unauthenticated aliro al via Git datumoj. Memoru ke ekde ĝi estas ne aŭtentikigita servo, ion vi servi super tiu protokolo estas publika ene lia reto.
Se vi uzas ĉi en servanto ekster via fajroŝirmilo, ĝi devus nur esti uzita por projektoj kiuj estas publike videbla por la mondo. Se la servilo vi uzas ĝin estas en via fajroŝirmilo, vi povus uzi ĝin por projektoj ke granda nombro da personoj aŭ komputiloj (kontinua integriĝo aŭ kreas serviloj) legis-nur aliro al, kiam vi ne volas havi aldoni SSH klavon por ĉiu.
En ajna kazo, la Git protokolo estas relative facila agordi. Esence, Vi devas kuri ĉi komando en daemonized maniero:

 $ Git demono --reuseaddr --base-vojo = / opt / git / / opt / git / 

--reuseaddr permesas la servilo rekomenci sen atendi malnovaj rilatoj al tempo el la --base-path opcio ebligas homojn kloni projektoj sen specifi la tuta vojo, kaj la vojo fine rakontas la Git-demono kie serĉi deponejoj eksporti. Se vi uzas fajroŝirmilo, vi ankaŭ bezonos trui truon en ĝi ĉe haveno 9418 sur la skatolo vi opcio ĉi supre sur.
Vi povas daemonize tiu procezo kelkaj manieroj, depende de la mastruma sistemo vi uzas. Sur Ubuntu maŝino, vi povas uzi Upstart skripto. Do, en la sekvaj dosieron

 /etc/init/local-git-daemon.conf 

vi metis tiun skripton:

 start on startup
stop on shutdown
exec /usr/bin/git daemon \
 --user=git --group=git \
 --reuseaddr \
 --base-path=/opt/git/ \
 /opt/git/
respawn 

Por sekureco, ĝi estas forte instigita havas ĉi demono kuri kiel uzanto kun nurlega permesojn al la deponejoj - vi povas facile fari tion per kreado de nova uzanto git-ro kaj kurante la demono kiel ili. Pro simpleco ni simple ruli ĝin kiel la sama git uzanto ke git-shell kuras kiel.
Kiam vi restartigu vian komputilon, via Git demono komencos aŭtomate kaj Respawn se ĝi iras malsupren. Akiri ĝin kurante sen devi restartu, vi povas kuri ĉi:

  $ Initctl komenci local -git-demono 

Sur aliaj sistemoj, vi povas deziri uzi xinetd , skripto en via sysvinit sistemo, aŭ io alia - tiel longe kiel vi havas tiun komandon daemonized kaj rigardis iel.
Sekva, vi devas diri al Git kiu deponejoj permesi unauthenticated Git servilo-bazita aliro al. Vi povas fari tion en ĉiu deponejo kreante dosieron nomita git-daemon-export-ok .

  $ cd /path/to/project.git
 $ Tuŝo git-demono-eksporto-ok 

La ĉeesto de tiu dosiero diras Git ke ĝi estas BONE servi tiun projekton sen aŭtentokontrolo.

prev | sekva

4.4 Git sur la servilo - Konfigurante la Servilo (

Setting U)

Ni marŝas tra la starigadon SSH aliro sur la servilo flanko. En ĉi tiu ekzemplo, vi uzos la authorized_keys metodo por aŭtentikigi viaj uzantoj. Ni ankaŭ supozu, ke vi uzas norman Linukso distribuo kiel Ubuntu. Unue, oni kreas git uzanto kaj .ssh dosierujo por ke uzanto.

  $ Ŝvitas adduser git
 $ Su git
 $ cd
$    mkdir .ssh && chmod 700 .ssh
 $ Tuŝi .ssh / authorized_keys && chmod 600 .ssh / authorized_keys 

Sekva, necesas aldoni iun ellaboranto SSH publikajn ŝlosilojn al la authorized_keys dosieron por la git uzanto. Ni supozu vi havas iuj fidindaj publikajn ŝlosilojn kaj savis ilin temporal dosierojn. Denove, la publikaj ŝlosiloj aspektas tiel:

  $ Cat /tmp/id_rsa.john.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypair 

Vi nur postglui al la git uzanto authorized_keys dosieron en lia .ssh dosierujo:

  $ Cat /tmp/id_rsa.john.pub >> ~ / .ssh / authorized_keys
 $ Cat /tmp/id_rsa.josie.pub >> ~ / .ssh / authorized_keys
 $ Cat /tmp/id_rsa.jessica.pub >> ~ / .ssh / authorized_keys 

Nun, vi povas agordi malplena dosieraro por ili kuras git init kun la --bare eblo, kiu inicializa la deponejo sen laboranta dosierujo:

  $ cd / opt / git
 $ Mkdir project.git
 $ cd project.git
 $ Git init --bare
Initialized empty Git repository in /opt/git/project.git/ 

Tiam, Johano, Josie, aŭ Jessica povas puŝi la unua versio de lia projekto en tiu deponejo aldonante ĝin kiel fora kaj puŝante supren branĉo. Notu ke iu devas alkanonadi sur la maŝino kaj krei nudajn enciklopedio ĉiufoje vi volas aldoni projekton. Ni uzu gitserver kiel la gastignomon de la servilo sur kiu vi instalis vian git uzanto kaj deponejo. Se vi uzas gxin interne, kaj vi agordi DNS por gitserver atentigi al tiu servilo, tiam vi povas uzi la komandojn preskaux kiel estas (supozante ke myproject estas ekzistanta projekto kun dosieroj en ĝi):

  # Johanon 's computer
 $  cd myproject
 $  git init
 $  git add .
 $  git commit -m ' komenca commit '
 $ Git fora aldonu origino git @ gitserver: /opt/git/project.git
 $ Git puŝo origino majstro 

Ĉe tiu punkto, la aliaj povas kloni ĝin kaj puŝi ŝanĝojn reen same facile:

  $ Git clone git @ gitserver: /opt/git/project.git
 $ cd projekto
 $ Vim README
 $ Git commit -AM 'fix for the README file'
 $ Git puŝo origino majstro 

Kun tiu metodo, vi povas rapide akiri legita / skribi Git servilon supren kaj kurante por plenmano de programistoj.
Notu ke nuntempe ĉiuj tiuj uzantoj povas ankaŭ eniri ankaŭ la servilan kaj akiri ŝelon kiel la git uzanto. Se vi volas limigi tion, vi devos ŝanĝi la ŝelon por io alia en la passwd dosiero.
Vi povas facile limigi la git uzanto nur faras Git aktivecoj kun limigita ŝelo ilo nomita git-shell kiu venas kun Git. Se vi povas tion kiel viaj git uzanto login shell, tiam la git uzanto povas havi normalan ŝelo aliro al via servilo. Uzi tiun, specifi git-shell anstataŭ bash aŭ csh por via uzanto salutnomo ŝelo. Fari tion, vi devas unue aldoni git-shell al /etc/shells se ĝi ne jam ekzistas:

  $ Cat / etc / shells # see if `git-shell` is already in there. If not... # see if `git-shell` is already in there. If not...
 $ Kio git-ŝelo # make sure git-shell is installed on your system.
 $ Ŝvitas vim / etc / shells # and add the path to git-shell from last command 

Nun vi povas redakti la ŝelon por uzanto uzante chsh <username> :

  $ Ŝvitas chsh git # and enter the path to git-shell, usually: /usr/bin/git-shell 

Nun la git uzanto povas nur uzi la SSH konekto puŝi kaj tiri Git deponejoj kaj ne povas alkanonadi sur la maŝino. Se vi provos, vi vidos salutnomon malakcepto tiel:

  $ Ssh git @ gitserver
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to gitserver closed. 

Nun Git reto komandoj daŭre funkcios ĝuste fajna sed la uzantoj ne povos akiri ŝelo. Kiel la eligo ŝtatoj, vi povas ankaŭ agordi dosierujo en la git uzanto hejmo dosierujo kiu customizes la git-shell ordonas iom. Ekzemple, vi povas limigi la Git ordonas ke la servilo akceptos aŭ vi povas personecigi la mesaĝon ke uzantoj vidi se ili provas SSH en tia. Kuri git help shell por pliaj informoj pri agordigo la ŝelo.

prev | sekva

4.3 Git sur la servilo - Generante Via SSH Publika Ŝlosilo

KE estanta dirita, multaj Git serviloj autenticar uzante SSH publikaj ŝlosiloj. Por havigi publika ŝlosilo, ĉiu uzanto en via sistemo devas generi unu se ili ne jam havas unu. Tiu procezo estas simila trans ĉiuj mastrumaj sistemoj. Unue, vi devus kontroli por certiĝi vi ne jam havas ŝlosilon. Defaŭlte, uzanto SSH klavoj estas stokitaj en tiu uzanto ~/.ssh dosierujo. Vi povas facile kontroli ĉu vi havas ŝlosilon jam irante al tiu dosierujo kaj printi la enhavo:

  $ cd ~ / .ssh
 $ ls
authorized_keys2 id_dsa known_hosts
config id_dsa.pub 

Vi serĉas paron de dosieroj nomis ion kiel id_dsa aŭ id_rsa kaj trafa dosieron kun .pub etendo. La .pub dosiero estas via publika ŝlosilo, kaj la alia dosiero estas via privata ŝlosilo. Se vi ne havas tiujn dosierojn (aŭ vi ne eĉ havas .ssh dosierujo), vi povas krei ilin per kurado programo nomata ssh-keygen , kiu estas provizita kun la SSH pakaĵon sur Linukso / Mac sistemoj kaj venas kun Git por Vindozo:

  $ Ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/schacon/.ssh/id_rsa):
Created directory '/home/schacon/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/schacon/.ssh/id_rsa.
Your public key has been saved in /home/schacon/.ssh/id_rsa.pub.
The key fingerprint is:
d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 schacon@mylaptop.local 

Unua konfirmas kie vi deziras savi la ŝlosilo ( .ssh/id_rsa ), kaj tiam ĝi demandas dufoje dum pasvorton, kiun vi povas lasi malplena se vi ne volas tajpi pasvorton kiam vi uzas la klavon.
Nun, ĉiu uzanto kiu faras ĉi devas sendi sian publikan ŝlosilon al vi aŭ al iu, kiu estas administrating la Git-servilo (supozante vi uzas SSH servilo agordo kiu postulas publikajn ŝlosilojn). Ĉiuj ili devas fari estas kopii la enhavon de la .pub dosieron kaj retpoŝtu ĝin. La publikaj ŝlosiloj aspektas tiel:

  $ Cat ~ / .ssh / id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== schacon@mylaptop.local 

Por pli detala lernilo pri kreanta SSH ŝlosilo sur multoblaj operaciumoj, vidu la GitHub gvidas sur SSH klavoj ĉe https://help.github.com/articles/generating-ssh-keys .

prev | sekva

4.2 Git sur la servilo - Uzante Git sur Servilo

Nun ni kovri starigante Git servo kuranta tiuj protokoloj sur via propra servilo.

noto

Tie ni estos montranta la komandojn kaj paŝoj bezonataj por fari bazan, simpligita instalaĵoj sur Linukso bazita servilo, kvankam ĝi estas ankaŭ ebla por kuri ĉi tiuj servoj en Mac aŭ Windows serviloj. Fakte starigante produktado servilo en via infrastrukturo certe kunportos diferencoj en sekureco mezuroj aŭ mastruma sistemo iloj, sed espereble ĉi donos vin la ĝenerala ideo de kio implikitaj.

Por komence starigita ajna Git servilo, vi devas eksporti ekzistantan deponejon en novan nudajn deponejo - deponejo kiu ne enhavas labordosierujon. Tio estas ĝenerale simpla fari. Por kloni via deponejo krei novan nudajn deponejo, vi kuras la clon komando kun la --bare opcion. Por konvencio, nudajn enciklopedio dosierujojn fini en .git , kiel tia:

  $ Git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done. 

Vi devus nun havas kopion de la Git dosierujo datumojn en via my_project.git dosierujo.
Tio estas proksimume ekvivalenta al iu kiel

  $ Kmp -Rf my_project / .git my_project.git 

Estas paro de malgrandaj diferencoj en la agordo-dosiero; sed por via celo, tio estas proksime al la sama afero. Ĝi prenas la Git-deponejo per sin, sen labori dosierujo, kaj kreas dosierujon specife por tio sole.

Metante la Senŝeligita Repository sur Servilo

Nun ke vi havas nudajn kopion de via deponejo, ĉiuj vi devas fari estas meti ĝin sur servilo kaj agordi vian protokoloj. Imagu ke vi jam instalis servilan nomita git.example.com ke vi havas SSH aliro al, kaj vi volas stoki tutan vian Git deponejoj sub la /srv/git dosierujo. Supozante ke /srv/git ekzistas sur tiu servilo, vi povas agordi vian novan enciklopedio kopiante viajn nudajn deponejo super:

  $ Scp -r my_project.git user@git.example.com: / SRV / git 

Ĉe tiu punkto, aliaj uzantoj, kiuj havas SSH aliro al la sama servilo kiu legas-aliro al la /srv/git dosierujo povas kloni via deponejo per kurado

  $ Git clone user@git.example.com: /srv/git/my_project.git 

Se uzanto SSHs en servilo kaj havas skribi aliro al la /srv/git/my_project.git dosierujo, ili ankaŭ aŭtomate havas puŝo aliro.
Git aŭtomate aldoni grupon skribpermeson al deponejo konvene se vi uzas git init komando kun la --shared opcion.

  $ Ssh user@git.example.com
 $ cd /srv/git/my_project.git
 $ Git init --bare --shared 

Vi vidos kiel facile estas preni Git-deponejo, krei nudajn versio kaj meti ĝin sur servilo al kiu vi kaj via kunlaborantoj havas SSH aliro. Nun vi pretas kunlabori en tiu projekto.
Estas grave noti, ke tiu estas laŭvorte ĉiuj vi bezonas fari por kuri utila Git servilo al kiu pluraj personoj havas aliron - simple aldonu SSH-able kontojn en servanto, kaj algluita nuda enciklopedio ie ke ĉiuj tiuj uzantoj legis kaj skribi aliro al. Vi estas preta iri - nenion alian bezonas.
En la venontaj sekcioj, vi vidos kiel ekspansiiĝi ​​al pli kompleksaj aranĝoj. Tiu diskuto inkludos ne devi krei uzanto kontoj por ĉiu uzanto, aldonante publika legado aliro al deponejoj, starigante retejo UIS kaj pli. Tamen, memoru ke por kunlabori kun paro de personoj en privata projekto, oni nur bezonas SSH servilo kaj nuda enciklopedio.

malgranda Muntaĵoj

Se vi estas malgranda kostumo aŭ jxus elprovanta Git en via organizo kaj havas nur kelkajn programistoj, aĵoj povas esti simpla por vi. Unu el la plej komplikitaj aspektoj de starigado de Git servilo estas uzanto mastrumado. Se vi volas iun deponejoj por legi nur al iuj uzantoj kaj legi / skribi al aliaj, aliro kaj permesoj povas esti iom pli malfacile aranĝi.

SSH Aliro

Se vi havas servilon kiu ĉiuj viaj ellaborantoj jam havas SSH aliro, estas ĝenerale facila starigi vian unuan enciklopedio tie, ĉar vi devos fari preskaŭ sen laboro (kiel ni kovris en la lasta sekcio). Se vi volas pli kompleksaj alirkontrolo tipo permesojn sur via deponejoj, vi povas pritrakti ilin kun la normala dosiersistemo permesojn de la mastruma sistemo de via servilo kuras.
Se vi volas meti vian deponejoj en servanto kiu ne havas kontojn por ĉiuj en via teamo, kiun vi volas havi registran rajton, tiam vi devas agordi SSH aliro por ili. Ni supozas ke se vi havas servilon kun kiu fari tion, vi jam havas SSH-servilo instalita kaj tiel estas kiel vi konsentas la servilo.
Estas kelkaj manieroj vi povas doni aliron al ĉiuj en via teamo. La unua estas starigi kontojn por ĉiuj, kiuj estas simpla sed povas esti maloportuna. Vi eble ne volas kuri adduser kaj starigis provizoran pasvortojn por ĉiu uzanto.
Dua metodo estas krei ununuran git uzanto sur la maŝino, petu cxiu uzanto kiu estas havi registran rajton sendi vin SSH publika ŝlosilo, kaj aldoni ke ŝlosilo al la ~/.ssh/authorized_keys dosiero de via nova git uzanto. En tiu momento, ĉiuj povos aliri tiun maŝinon tra la git uzanto. Tiu ne afekti la commit datumoj iamaniere - la SSH uzanto por konekti kiel ne tuŝas la interna vi registris.
Alia maniero fari tion estas havi vian SSH servilo Aŭtentigu el LDAP-servilo aŭ alian centralizita aŭtentikigado fonto ke vi jam starigis. Tiel longe kiel ĉiu uzanto povas akiri ŝelo aliro sur la maŝino, iu SSH autenticación mekanismo povas pensi devus labori.

prev | sekva

4.1 Git sur la servilo - La Protokoloj

Ĉe tiu punkto, Vi devus esti kapabla fari la plejparto de la tago al tago taskoj por kiuj vi estos uzanta Git. Tamen, por fari ajnan kunlaboron en Git, vi bezonos havi fora Git-deponejo. Kvankam vi povas teknike puŝi ŝanĝojn kaj tiri ŝanĝoj de individuoj 'deponejoj, farante tuj kiam estas malinstigita ĉar vi povas sufiĉe facile konfuzi kion ili laboras sur se vi ne estas zorgema. Plue, vi volas vian kunlaborantoj por povi aliri la deponejo eĉ se via komputilo estas offline - havi pli fidinda komuna deponejo estas ofte utila. Sekve, la preferata metodo por kunlabori kun iu estas starigi intera deponejo ke vi ambaŭ havas aliron al, kaj puŝi por kaj tiri el tio.
Kuranta Git servilo estas sufiĉe simpla. Unue vi elektu kiu protokoloj volas vian servilon por komuniki kun. La unua sekcio de tiu ĉapitro kovras la disponeblaj protokoloj kaj la avantaĝoj kaj malavantaĝoj de ĉiu. La sekva sekcioj klarigos iuj tipaj aranĝoj uzante tiujn protokolojn kaj kiel akiri vian servilon kurante kun ili. Lasta, ni iros super kelkaj gastigita ebloj, se vi ne ĝenas retprovizanton via kodo en aliulaj servilo kaj ne volas iri tra la hassle de alĝustigo kaj subteni vian propran servilon.
Se vi havas neniun intereson en kurado via propra servilo, vi povas salti al la lasta sekcio de la ĉapitro vidi iujn eblojn por starigi gastigita konton kaj tiam movi sur al la sekvanta ĉapitro, kie ni diskutos la diversajn ins kaj outs de laborado en distribuita fonto kontrolo medio.
Al fora enciklopedio estas ĝenerale nuda enciklopedio - la Git-deponejo kiu havas neniun labordosierujon. Ĉar la deponejo estas uzata nur kiel kunlaborado punkto, ne estas kialo por havi instantánea Taksis surdiske; ĝi estas nur la Git datumoj. En la plej simpla terminoj, nuda deponejo estas la enhavo de via projekto .git dosierujo kaj nenio alia.

Protokoloj

Git povas uzi kvar gravaj protokoloj translokigi datumon: Loka, HTTP, Secure Shell (SSH) kaj git. Tie ni diskutos kion ili estas kaj en kion bazaj cirkonstancoj vi volus (aŭ ne volas) uzi ilin.

lokaj Protokolo

La plej baza estas la Loka protokolon, en kiu la fora deponejo estas en alia dosierujo en disko. Ĉi estas ofte uzata se ĉiuj en via teamo havas aliron al komuna dosiersistemo kiel NFS monton nek en la malpli verŝajna kazo ke ĉiuj ensalutas al la sama komputilo. La lasta devus ne esti idealo, ĉar ĉiuj viaj kodo enciklopedio okazojn loĝus sur la sama komputilo, farante katastrofa perdo multe pli verŝajna.
Se vi havas dividita muntita dosiersistemo, tiam vi povas kloni, puŝi por kaj tiri el loka dosiero-bazita deponejo. Kloni deponejo tiel aŭ aldoni kiel fora al ekzistanta projekto, uzu la padon al la deponejo kiel la retadreso. Ekzemple, kloni loka deponejo, vi povas kuri proksimume tia:

  $ Git clone /opt/git/project.git 

Aŭ vi povas fari tion:

  $ Git clone dosiero: ///opt/git/project.git 

Git operacias iomete malsame se vi eksplicite specifi file:// komence de la URL. Se vi nur specifi la vojon, Git provas uzi hardlinks aŭ rekte kopii la dosierojn bezonas. Se vi specifas file:// , Git maldungas la procezoj kiuj ĝi kutime uzas por transferir datumoj super reto kiu estas ĝenerale multe malpli efika metodo de transdonado la datumoj. La ĉefa kialo por specifi la file:// prefikso estas se vi volas puran kopion de la deponejo kun fremda referencojn aŭ objektoj lasitaj ekstere - ĝenerale post importado de alia versio kontrolo sistemo aŭ ion similan (vidu Git internals por bontenado taskoj) . Ni uzos la normalan vojon tien ĉar faranta estas preskaŭ ĉiam pli rapide.
Aldoni lokan deponejon al ekzistantan Git projekto, vi povas kuri proksimume tia:

  $ Git fora aldonu local_proj /opt/git/project.git 

Tiam, vi povas premi por kaj tiri el tiu fora kvazaux vi faranta sur reto.

la Pros

La avantaĝoj de dosiero bazita deponejoj estas ke ili estas simplaj kaj ili uzas ekzistantajn dosiero permesojn kaj reto aliro. Se vi jam havas dividitaj dosiersistemo kiu via tuta teamo havas aliron, starigante deponejo estas tre facila. Vi algluita la nudajn enciklopedio kopion ie ĉiuj dividis aliro al ekbruligis la legado / skribo permesojn kiel vi farus por iu alia komuna dosierujo. Ni diskuti kiel eksporti nuda enciklopedio kopion tiucele en Getting Git sur ​​Servilo .
Tiu estas ankaŭ bela eblo por rapide kaptante laboro de aliulaj laborista enciklopedio. Se vi kaj co-laboristo estas laboranta sur la sama projekto kaj ili volas ke vi kontrolu ion, kuri komandon kiel git pull /home/john/project estas ofte pli facile ol ilin pelas al fora servilo kaj vi detruis.

la trompoj

La contras de ĉi tiu metodo estas kiu dividis aliro estas ĝenerale pli malfacile starigi kaj atingi de multoblaj lokoj ol baza reto aliro. Se vi volas puŝi de via tekkomputilo kiam vi estas hejme, vi devas munti la fora disko, kiu povas esti malfacila kaj malrapida kompare kun reto-bazita aliro.
Estas grave mencii ke ĉi tio ne estas nepre la plej rapida eblo se vi uzas komunan monto ia. Loka deponejo estas rapida nur se vi havas rapidan aliron al la datumoj. A-deponejo sur NFS estas ofte malrapidaj ol la deponejo super SSH sur la sama servilo, permesante Git kuri ekstere lokaj diskoj sur ĉiu sistemo.
Fine, ĉi tiu protokolo ne protektas la deponejo kontraŭ akcidenta damaĝo. Ĉiu uzanto havas plenan ŝelo aliro al la "fora" dosierujo, kaj estas nenio malhelpante ilin de ŝanĝanta aŭ foriganta interna Git dosierojn kaj korupti la deponejo.

La HTTP- Protokoloj

Git povas komuniki super HTTP en du malsamaj manieroj. Antaŭ Git 1.6.6 ekzistis nur unu maniero povus fari tiu kiu estis tre simpla kaj ĝenerale nur legado. En versio 1.6.6 nova, inteligenta protokolo estis enkondukita kiu implikis Git povi inteligente negoci transporto de datumoj en maniero simila al kiel ĝi faras super SSH. En la lastaj jaroj, ĉi tiu nova protokolo HTTP fariĝis tre populara ĉar ĝi estas pli simpla por la uzanto kaj inteligenta pri kiel komunikas. La pli nova versio estas ofte referita al kiel la "Lerta" protokolo HTTP kaj la malnovaj maniero kiel "Muta" HTTP. Ni kovras la pli nova "smart" protokolo HTTP unua.

smart HTTP

La "inteligentaj" protokolo HTTP operacias tre simile al la SSH aŭ Git protokoloj sed alveturas normo HTTP / S havenoj kaj povas uzi diversajn HTTP aŭtentokontrolo mekanismoj, signifa ĝi estas ofte pli simpla al la uzanto ol io kiel SSH, ĉar vi povas uzi aĵojn kiel uzantonomo / pasvorton baza aŭtentokontrolo anstataŭ devi instali SSH klavoj.
Ĝi verŝajne fariĝis la plej populara maniero uzi Git nun, ĉar ĝi povas esti instalita al ambaŭ servi anonime kiel la git:// protokolo, kaj povas ankaŭ esti puŝita super kun autenticación kaj ĉifrado kiel la SSH protokolo. Anstataŭ devi agordi malsamajn URLoj por tiuj aferoj, Vi povas nun uzi solan URL por ambaŭ. Se vi provos puŝi la deponejo postulas aŭtentokontrolo (kiu normale devus), la servilo povas suflori por salutnomon kaj pasvorton. La sama iras por legado aliro.
Fakte, por servoj kiel GitHub, la URL vi uzu por vidi la deponejo rete (ekzemple, " https://github.com/schacon/simplegit ") estas la sama URL vi povas uzi kloni kaj, se vi havas aliron , puŝi super.

muta HTTP

Se la servanto ne respondas kun Git HTTP inteligenta servado, la Git kliento provos replegarse al la simpla "muta" protokolo HTTP. La Muta protokolo atendas la nuda Git-deponejo por utili kiel normala dosierojn el la servilo. La beleco de la Muta HTTP- protokolon estas la simpleco de opcio ĝin. Esence, ĉiuj vi devas fari estas meti nuda Git-deponejo sub via HTTP dokumenton radiko kaj starigis specifa post-update hoko, kaj vi faris (Vidi Git Hokoj ). En tiu punkto, ĉiu kiu povas aliri la TTT-servilo sub kiun pasxos la deponejo povas kloni via deponejo. Permesi legrajtojn por via deponejo super HTTP, fari ion kiel jene:

  $ cd / var / www / htdocs /
 $ Git clone --bare / vojo / al / git_project gitproject.git
 $ cd gitproject.git
 $ Mv hokoj / post-update.sample hokoj / post-ĝisdatigo
 $ Chmod a + x hokoj / post-ĝisdatigo 

Tio estas ĉio. La post-update hoko kiu venas kun Git defaŭlte kuras la taŭga komando ( git update-server-info ) fari HTTP kolektadon kaj klonado laboro konvene. Tiu komando estas kuri kiam vin puŝi al tiu enciklopedio (super SSH eble); do aliaj homoj povas kloni tra ion kiel

  $ Git clone https://example.com/gitproject.git 

En ĉi tiu aparta kazo, ni uzas la /var/www/htdocs pado kiu estas komuna por Apache aranĝoj, sed vi povas uzi iun statika retservilo - simple meti la nudajn deponejo en ĝia pado. La Git datumoj utilas kiel baza statikaj dosieroj (vidu Git internals por detaloj pri precize kiel ĝi estas servita).
Ĝenerale vi ĉu elekti kuri legita / skribi Smart HTTP servilo aŭ simple havi la dosierojn alirebla kiel nur legado en la Muta maniero. Ĝi estas malofte kuras miksaĵo de la du servoj.

la Pros

Ni koncentros sur la avantaĝoj de la Smart versio de la HTTP-protokolo.
La simpleco de havi solan URL por ĉiuj tipoj de aliro kaj havanta la servilo prompto nur kiam autenticación bezonas faras aferojn tre facila por la uzanto fino. Povi autenticar kun uzantnomo kaj pasvorto estas ankaŭ granda avantaĝo super SSH, ekde uzantoj ne devas generi SSH klavoj loke kaj alŝuti siajn publika ŝlosilo al la servilo antaŭ povi interagi kun ĝi. Por malpli kompleksaj uzantoj, aŭ uzantoj en sistemoj kie SSH estas malpli komuna, tio estas granda avantaĝo en usabilidad. Ĝi estas ankaŭ tre rapida kaj efika protokolo, simila al la SSH unu.
Vi povas ankaŭ servi vian deponejoj nur legado super HTTPS, kiu signifas vin povas ĉifri la enhavon transporto; aŭ vi povas iri tiel ege kiel fari la klientoj uzas specifajn subskribis SSL atestilojn.
Alia bela afero estas ke HTTP / S estas tia komune uzataj protokoloj korporacia firewalls ofte starigita permesi trafikon tra tiuj havenoj.

la trompoj

GIT sur HTTP / S povas esti iom pli malfacila starigi kompare al SSH sur iuj serviloj. Krom tiu, estas tre malgranda avantaĝo ke aliaj protokoloj havas super la "Smart" protokolo HTTP por servanta Git.
Se vi uzas HTTP por aŭtentikigita puŝante, disponigante viajn akreditaĵojn estas kelkfoje pli komplika ol uzante klavojn super SSH. Ekzistas tamen pluraj credencial caching iloj vi povas uzi, inkluzive Keychain aliro sur OSX kaj Credencial Direktisto en Windows, fari tiun belan sendolora. Legi Credencial Stokado vidi kiel agordi sekura HTTP pasvorton caching sur via sistemo.

La SSH protokolo

Komuna transporto protokolo por Git kiam mem-gastiganta estas super SSH. Tiu estas ĉar SSH aliro al serviloj jam instalita en plej lokoj - kaj se ne, ĝi estas facile fari. SSH estas ankaŭ aŭtentikigita reto protokolo; kaj ĉar ĝi estas ĉiea, ĝi estas ĝenerale facila starigi kaj uzi.
Por kloni Git-deponejo super SSH, vi povas specifi ssh: // URL tiel:

  $ Git clone ssh: //user@server/project.git 

Aŭ vi povas uzi la pli mallonga scp-simila sintakso al la SSH protokolo:

  $ Git clone uzanto @ servilo: project.git 

Vi povas ankaŭ ne specifi uzanto kaj Git supozas la uzanto vi salutis kiel.

la Pros

La avantaĝoj de uzi SSH estas multaj. Unua, SSH estas relative facila starigi - SSH demonoj estas ordinaraj, multaj reto administrantoj havas sperton kun ili, kaj da VIN distribuoj estas starigita kun ili aŭ havi ilojn por administri ilin. Sekva, aliro super SSH estas sekura - ĉiuj transporto de datumoj estas ĉifrita kaj legalizita. Lasta, kiel la HTTP / S, Git kaj Lokaj protokoloj, SSH estas efika, farante la datumojn kiel kompakta kiel ebla antaŭ kopii ĝin.

la trompoj

La negativa aspekto de SSH estas ke vi ne povas servi anonima aliro de via deponejo super ĝi. Homoj devas havi aliron al via maŝino super SSH aliri ĝin, eĉ en nurlega kapablo, kiu ne faras SSH aliro faciliga malfermi fonto projektoj. Se vi uzas nur ene via kompania reto, SSH povas esti la nura protokolo vi devas trakti. Se vi volas permesi anonimajn nurlega aliro al via projektoj kaj ankaŭ volas uzi SSH, vi devos agordi SSH por vi premi super sed io alia por aliaj por preni super.

La Git Protokolo

Sekva estas la Git-protokolo. Tiu estas speciala demono kiu venas pakita kun Git; aŭskultas sur diligenta haveno (9418) kiu provizas servon similan al la SSH protokolo, sed kun absolute neniu aŭtentokontrolo. En ordo por deponejo esti servita super la Git protokolo, vi devas krei la git-daemon-export-ok dosiero - la demono ne servos deponejo sen tiu dosiero en ĝi - sed krom tio ekzistas neniu sekureco. Ĉu la Git-deponejo estas disponebla por ĉiuj kloni aŭ ne. Tio signifas ke estas ĝenerale ne puŝas super tiu protokolo. Vi povas ebligi puŝo aliro; sed donita la manko de autenticación, se vi ŝaltas puŝo aliro, iu sur la interreto kiu trovas viajn projekto URL povus puŝi al via projekto. Sufiĉas diri ke ĉi tiu estas malofta.

la Pros

La Git protokolo estas ofte la plej rapida reto tradona protokolo disponeblas. Se vi servanta multajn trafiko por publika projekto aŭ servanta tre grandan projekton kiu ne postulas uzulon por legrajtojn, estas probable ke vi volas starigi Git demono servi vian projekton. Ĝi uzas la samajn datumojn-transigo mekanismo kiel la SSH protokolo sed sen la ĉifrado kaj aŭtentokontrolo superkape.

la trompoj

La malavantaĝo de la Git protokolo estas la manko de autenticación. Ĝi estas ĝenerale nedezirinda pro la Git protokolo esti la nura aliro al via projekto. Ĝenerale, vi duo per SSH aux HTTPS aliro por la malmultaj desarrolladores kiu havas puŝo (skribi) aliro kaj havas ĉiuj aliajn uzo git:// por legi nur aliro. Ĝi estas ankaŭ probable la plej malfacila protokolo starigi. Ĝi devas kuri lian propran demono, kiu postulas xinetd agordo aŭ simile, kio ne ĉiam promeni en la parko. Ĝi ankaŭ postulas fajroŝirmilo aliro al haveno 9418, kiu ne estas normo haveno kiu kompania firewalls ĉiam permesas. Malantaŭ granda kompania firewalls, tiu obskura haveno estas kutime blokita.

prev | sekva

3.7 Git branĉantaj - Resumo

Ni kovras bazan disbranĉadon kaj kunfando en Git. Vi devus senti komforta kreado kaj conmutación al novaj branĉoj, ŝaltanta inter branĉoj kaj kunfalado lokaj filioj kune. Vi devus ankaŭ povos dividi viajn brancxojn puŝante ilin al komuna servilo, laborante kun aliaj sur dividitaj filioj kaj rebasing viajn brancxojn antaux ili dividis. Tuj, ni kovros kion vi devas kuri via propra Git-deponejo-retprovizanton servilo.

prev | sekva

3.6 Git branĉantaj - Rebasing

Uzante Git, estas du ĉefaj manieroj integri ŝanĝoj de unu branĉo al alia: la merge kaj la rebase . En ĉi tiu sekcio vi lernos kio rebasing estas, kiel fari ĝin, tial ĝi estas bela mirinda ilo, kaj en kio kazoj vi ne volas uzi ĝin.

La Bazaj Rebase

Se vi reiros al pli frua ekzemplo de Bazaj kunfalado , vi povas vidi ke vi disiĝis vian laboron kaj faris interna du malsamaj branĉoj.

Figuro 3-27. Simpla diferenca historio

La plej facila maniero por integri la branĉoj, kiel ni jam kovrita, estas la merge komando. Ĝi realigas tridirekta kunfandas inter la du lastaj branĉo instantáneas ( C3 kaj C4 ) kaj la plej lastatempa komuna prapatro de la du ( C2 ), kreante nova instantánea (kaj faris).

Figuro 3-28. Miksante integri diverĝis laboro historio

Tamen, ekzistas alia vojo: vi povas preni la diakilo de la ŝanĝo kiu estis enkondukita en C4 kaj rekandidatiĝi ĝin sur C3 . En Git, tio nomiĝas rebasing. Kun la rebase komando, vi povas preni ĉiuj ŝanĝoj kiuj estis faritaj sur unu brancxo kaj revidigi ilin sur alia.
En ĉi tiu ekzemplo, oni kredus kuri la jenaj:

  $ Git kaso eksperimento
 $ Git rebase mastro
First, rewinding head to replay your work on top of it...
Applying: added staged command 

Funkcias irante al la komuna praulo de la du branĉoj (la unu vi estas sur kaj tiu kiun vi rebasing sur), alvenante la malsamoj enkondukita de ĉiu faras de la branĉo vi estas sur, ŝparante tiujn ŝanĝoj al intertempaj dosieroj , recomposición la aktuala branĉo al tion transdonu al la branĉo vi rebasing sur kaj fine aplikanta ĉiu ŝanĝo laŭvice.

Figuro 3-29. Rebasing la ŝanĝo enkondukita en C4 sur C3

Ĉe tiu punkto, vi povas reiri al la master branĉo kaj fari rapida antaŭen merge.

  $ Git kaso mastro
 $ Git merge eksperimento 

Kalkuli 3-30. Fast-plusendanta la mastro branĉo

Nun la instantánea almontras C4' estas ekzakte la sama kiel la unu kiu almontras C5 en la merge ekzemplo. Ne ekzistas diferenco en la produkto fino de la integriĝo, sed rebasing faras por pura historio. Se vi ekzamenos la ŝtipo de rebased branĉo, ĝi aspektas kiel lineara historio: ĝi similas ke ĉiuj laboroj okazis en serio, eĉ kiam ĝi origine okazis en paralela.
Ofte, vi faros tion certigi via interna apliki pure sur fora branĉo - eble en projekto al kiu vi provas kontribui sed vi ne subtenas. En tiu kazo, vi volas fari vian laboron en branĉo kaj tiam rebase via laboro sur origin/master kiam vi pretas sendi vian batitaj al la ĉefa projekto. Tiel, la administranto ne devas fari ajnan integriĝo laboro - simple rapida antaŭen aŭ pura apliki.
Notu ke la instantánea almontras la fina commit vi finos kun, ĉu ĝi estas la lasta de la rebased interna por rebase aŭ la fina merge fari post merge, estas la sama instantánea - estas nur la historio kiu estas malsama. Rebasing ripetoj ŝanĝoj de unu linion de laboro al alia en la ordo estis enkondukita, dum kunfandado prenas la finpunktoj kaj kunfandas ilin.

Pli Interesaj Rebases

Vi povas ankaŭ havi vian rebase ripetmatĉo sur io alia ol la rebase celo branĉo. Preni historion kiel Figuro 3-31 , ekzemple. Vi ramificado temo branĉo ( server ) aldoni iun servilo-flanko funcionalidad al via projekto kaj faris commit. Tiam, vi disbranĉiĝis ke fari la kliento-flanko ŝanĝoj ( client ) kaj faris kelkajn fojojn. Fine, vi reiris al via servilo branĉo kaj faris kelkajn pli interna.

Kalkuli 3-31. Historio kun temo branĉo de alia temo branĉo

Supozi vi decidas ke vi volas kunfandi viajn kliento-flanko ŝanĝojn en via ĉeftendenca por liberigo, sed vi volas teni ekstere sur la servilo-flanko ŝanĝoj ĝis ĝi estas provita plu. Vi povas preni la ŝanĝojn sur kliento kiuj ne estas en servilo ( C8 kaj C9 ) kaj revidigi ilin sur via master branĉo uzante la --onto eblo de git rebase :

  $ Git rebase --onto mastro servilo kliento 

Ĉi esence diras, "Legu la kliento branĉo, diveni la makulojn de la komuna praulo de la client kaj server branĉoj, kaj tiam ripeti ilin sur master ." Estas iom kompleksa, sed la rezulto estas sufiĉe malvarmaj.

Kalkuli 3-32. Rebasing temo branĉo de alia temo branĉo

Nun vi povas rapide plusendu via master branĉo (vidu Figuro 3-33 ):

  $ Git kaso mastro
 $ Git merge kliento 

Kalkuli 3-33. Fast-plusendanta via mastro branĉo inkludi la kliento branĉo ŝanĝoj

Diru vi decidas tiri en via servilo branĉo ankaŭ. Vi povas rebase la servilo branĉo sur la master branĉo sen devi kontroli ĝin unue por kuri git rebase [basebranch] [topicbranch] - kiu kontrolas la temon branĉo (en tiu kazo, server ) por vi kaj ripetoj ĝin sur la bazo branĉo ( master ):

  $ Git rebase mastro servilo 

Tiun Ripetoj via server laboro sur supro de via master laboro, kiel montrita en Figuro 3-34 .

Kalkuli 3-34. Rebasing via servilo branĉo sur supro de via sinjoro branĉo

Tiam, vi povas rapide plusendu la bazo branĉo ( master ):

  $ Git kaso mastro
 $ Git merge servilo 

Vi povas forigi la client kaj server branĉoj ĉar ĉiuj la laboro estas integrita kaj vi ne bezonas ilin plu, lasante via historio por ĉi tiu tuta procezo aspektas kiel Figuro 3-35 :

  $ Git branĉo -d kliento
 $ Git branĉo -d servilo 

Kalkuli 3-35. Fino commit historio

La Danĝeroj de Rebasing

Ahh, sed la feliĉo de rebasing ne estas sen malavantaĝoj, kiuj povas resumi en sola linio:
Ne rebase interna kiuj ekzistas ekster via deponejo.
Se vi sekvas ke gvidlinio, vi estos bone. Se ne, homoj malamos vin, kaj vi estos malestimis de amikoj kaj familio.
Kiam vi rebase stuff, vi forlasante ekzistanta interna kaj kreante novaj kiu estas similaj sed malsamaj. Se vi puŝas faras ie ​​kaj aliaj tiri ilin malsupren kaj bazo laboron sur ilin, kaj tiam vi reverki tiujn interna kun git rebase kaj puŝi ilin supren denove, via kunlaborantoj devos re-kunfandi ilian laboron kaj aĵoj ricevos senorda kiam vi provas tiri sian laboron reen en via.
Ni rigardu ekzemplon de kiel rebasing laboro ke vi faris publikan povas kaŭzi problemojn. Supozi vi kloni de centra servilo kaj tiam fari iun laboron ekstere tiel. Via commit historio aspektas jene:

Kalkuli 3-36. Kloni deponejo, kaj bazo iu laboro sur ĝi

Nun, iu alia faras pli laboro kiu inkludas merge kaj puŝas tiun laboron al la centra servilo. Vi prenu gxin kaj kunfandi la nova fora branĉo en via laboro, farante vian historion aspektas tiel:

Kalkuli 3-37. Venigu plej interna kaj kunfandi ilin en via laboro

Tuj poste, la persono kiu puŝis la kunfandita laboron decidas iri reen kaj rebase ilia laboro anstataŭe; ili faras git push --force anstataŭigi la historio sur la servilon. Vi tiam venigu de tiu servilo, alportanta malsupren la nova interna.

Kalkuli 3-38. Iu pelas rebased interna, forlasante interna vi bazita vian laboron

Nun vi estas ambaŭ en piklaĵo. Se vi faros git pull , vi kreos merge commit kiu inkluzivas ambaŭ linioj de la historio, kaj via deponejo aspektos tiel ĉi:

Figuro 3-39. Vi kunfandi en la sama laboro denove en novan merge commit

Se vi kuras git log kiam via historio similas tiun, vi vidos du interna kiuj havas la saman aŭtoron, daton, kaj mesaĝo, kiu estos konfuza. Plue, se vi puŝas tiun historion reen al la servilo, vi reenkonduki ĉiuj rebased interna al la centra servilo, kiu povas plui konfuzi homojn. Estas bela sekure supozi ke la aliaj desarrollador ne volas C4 kaj C6 esti en la historio; tial ili rebased en la unua loko.

Rebase Kiam Vi Rebase

Se vi ja trovas vin mem en situacio kiel tiu, Git havas iuj pli magion kiu povus helpi vin. Se iu en via teamo forto puŝas ŝanĝojn kiuj anstatauxigas laboro ke vi bazis laboro sur via defio estas elkompreni kio estas via kaj kio ili jam reskribita.
Ĝi rezultas ke krom la commit SHA-1 checksum, Git ankaŭ kalkulas checksum kiu estas bazita nur sur la diakilo enkondukita kun la commit. Tio nomiĝas "diakilo-identigilo".
Se vi tiri malsupren laboro kiu estis reskribita kaj rebase sur supro de la nova interna de via partnero, Git povas ofte sukcese diveni kio estas unike via kaj apliki ilin reen sur la nova branĉo.
Ekzemple, en la antaŭa scenaro, se anstataŭ faranta merge kiam ni estas en Figuro 3-38 ni kuras git rebase teamone/master , Git volo:

• Determini kion laboro estas unika al nia branĉo (C2, C3, C4, C6, C7)
• Determini kiuj ne kunfalas interna (C2, C3, C4)
• Determini kiu ne estis reskribita en la cela branĉo (ĵus C2 kaj C3, kiam C4 estas la sama diakilo kiel C4 ')
• Apliki tiujn interna al la supro de teamone/master

Do anstataŭ la rezulton ni vidas en Figuro 3-39 , ni finus kun io pli da kiel Figuro 3-40 .

Kalkuli 3-40. Rebase aldone forto-puŝis rebase laboro.

Tiu nur funkcias se C4 kaj C4 'ke via partnero faras preskaŭ ekzakte la sama diakilo. Alie la rebase ne povos diri ke ĝi estas duplikato kaj aldonos alian C4-kiel diakilo (kiu verŝajne malsukcesos apliki pure, ekde la ŝanĝoj jam estus almenaŭ iom tie).
Vi povas ankaŭ simpligi tion kurante git pull --rebase anstataŭ normala git pull . Aŭ vi povus fari ĝin manualmente kun git fetch sekvita per git rebase teamone/master en tiu kazo.
Se vi uzas git pull kaj volas fari --rebase la defaŭlta, vi povas agordi la pull.rebase config valoro kun iu kiel git config --global pull.rebase true .
Se vi traktas rebasing kiel maniero purigi kaj labori kun interna antaux vi puŝi ilin, kaj se vi nur rebase interna kiuj neniam estis disponebla publike, tiam vi estos bone. Se vi rebase interna kiuj jam puŝis publike, kaj homoj povas esti bazita laboron sur tiuj interna, tiam vi povas esti en por iu frustrante mizero, Kaj malestimo de via samteamanoj.
Se vi aŭ partnero ne trovas ĝin necesa en iu momento, certigu ĉiuj scias kuri git pull --rebase provi fari la doloro post okazas iomete pli simpla.

Rebase vs. Kunfandi

Nun ke vi vidis rebasing kaj kunfando en ago, vi eble scivolas kiu unu estas bona. Antaŭ ol ni povas respondi tion, ni retropaŝi iom kaj paroli pri kio historio rimedoj.
Unu vidpunkton sur ĉi estas ke via deponejo de fari historio estas rekordo de kio vere okazis. Ĝi estas historia dokumento, valoraj en sia propra rajto, kaj oni ne difektis. De tiu angulo, ŝanĝante la commit historio estas preskaŭ blasfema; Vi mensogas pri kio vere okazis. Do kio se ekzistis senorda serio de merge faras? Tiel estas kiel ĝi okazis, kaj la deponejo devus konservi ke por la posteularo.
La kontraŭa vidpunkto estas ke la commit historio estas la historio de kiel via projekto estis farita. Vi ne publikigas la unuan malneton de libro, kaj la manlibro por kiel subteni vian programaron meritas zorgema redaktado. Tio estas militistaro kiu uzas ilojn kiel rebase kaj filtrilo-branĉo al rakonti la historion en la maniero kiu estas plej bone por estontaj legantoj.
Nun, al la demando de ĉu kunfalado aŭ rebasing estas bona: espereble vi vidos ke ĝi ne estas tiu simpla. Git estas potenca ilo, kaj permesas vin fari multon por kaj per via historio, sed ĉiu teamo kaj ĉiu projekto estas malsama. Nun ke vi scias kiel ambaŭ de tiuj aferoj funkcias, ĝi estas supren al vi por decidi kio estas bona por via aparta situacio.
Ĝenerale la vojo akiri la plej bonan de ambaŭ mondoj estas rebase lokaj ŝanĝoj vi faris sed ne dividis ankoraux antaux vi puŝi ilin por purigi vian historion, sed neniam rebase ion vi puŝis ie.

prev | sekva