Rêxistinkirina gihîştina pir-bikarhêner a servera GIT

Dema sazkirin û mîhengkirina serverek Git-ê, pirs di derbarê organîzekirina gihîştina çend bikarhêneran ji bo çend projeyan derdikeve holê. Min li ser pirsgirêkê lêkolîn kir û çareseriyek dît ku hemî daxwazên min bicîh tîne: hêsan, ewledar, pêbawer.

Daxwazên min ev in:

• her bikarhêner bi hesabê xwe ve girêdayî ye
• Gelek bikarhêner dikarin li ser yek projeyê bixebitin
• heman bikarhêner dikare li ser gelek projeyan bixebite
• her bikarhêner bi tenê ji wan projeyên ku ew li ser dixebitin heye
• Pêdivî ye ku meriv bi riya rêzika fermanê ve were girêdan, û ne tenê bi cûreyek navbeynkariya malperê

Ew ê jî pir baş be:

• destûrên tenê xwendinê bidin kesên kontrolê
• Mafên gihîştina bikarhênerê di Git-ê de bi hêsanî birêve bibin

Pêşniyara vebijarkên gengaz ên ji bo gihîştina servera GIT

Berî her tiştî, hûn hewce ne ku zanibin ka ji çi hilbijêrin, ji ber vê yekê li vir nihêrînek bilez a protokolên Git heye.

• ssh - hesabek bikarhênerek taybetî hatî afirandin ji bo gihîştina serverê tê bikar anîn.
  • Ecêb e ku Git ji pêşnîyarên xwe karanîna yek hesabek ji bo gihîştina hemî depoyan dernaxe. Ev qet daxwazên min nagire.
  • Hûn dikarin gelek hesaban bikar bînin, lê hûn çawa dikarin gihîştina bikarhêner tenê ji hin peldankan re sînordar bikin?
    • Girtina pelrêça malê ne guncaw e, ji ber ku dijwar e ku meriv gihandina nivîsandinê li wir ji bo bikarhênerên din organîze bike
    • Bikaranîna symlinkên ji pelrêça xweya malê jî dijwar e ji ber ku Git wan wekî girêdan şîrove nake
    • Dikare gihandina wergêr sînordar bike, lê garantiyek tam tune ku ew ê her dem bixebite
      • Hûn dikarin bi gelemperî wergêrê fermana xwe ji bo bikarhênerên weha ve girêdin, lê
        • yekem, ev jixwe biryarek dijwar e,
        • û ya duyemîn jî, ev dikare were dorpêç kirin.

  Lê belkî ne pirsgirêk e ku bikarhêner bikaribe her fermanan bi cih bîne?.. Bi gelemperî, heke hûn tam fêr bibin ka meriv wê çawa bikar bîne, ev rêbaz nayê red kirin. Em ê paşê vegerin vê rêbazê, lê ji bo naha em ê bi kurtî alternatîfên din binirxînin, dibe ku tiştek hêsantir hebe.

• Protokola herêmî ya git dikare bi sshfs re bi hev re were bikar anîn, pir bikarhêner dikarin werin bikar anîn, lê bi bingehîn heman doza berê ye
• http - tenê xwendin
• git tenê-xwendin e
• https - sazkirina dijwar e, ji we re nermalava pêvek pêdivî ye, celebek panelek kontrolê heye ku hûn gihîştina bikarhêner birêxistin bikin ... ew pêkan xuya dike, lê bi rengekî her tişt tevlihev e.

Bikaranîna protokola ssh-ê ji bo organîzekirina gihîştina pir-bikarhêner a servera Git

Ka em vegerin ser protokola ssh.

Ji ber ku hûn gihîştina ssh-ê ji bo git bikar tînin, hûn hewce ne ku ewlehiya daneyên serverê bicîh bikin. Bikarhênerê ku bi ssh ve girêdide têketina xwe ya li ser servera Linux bikar tîne, ji ber vê yekê ew dikarin bi xerîdar ssh ve girêbidin û bigihîjin rêzika fermanê ya serverê.
Li dijî gihîştina bi vî rengî parastinek bêkêmasî tune.

Lê divê bikarhêner bi pelên Linux re eleqedar nebe. Agahiyên girîng tenê di depoya git de têne hilanîn. Ji ber vê yekê, ne gengaz e ku meriv gihîştina bi rêzika fermanê sînordar neke, lê bi karanîna amûrên Linux-ê bikar bîne da ku bikarhêner ji dîtina projeyan qedexe bike, ji bilî yên ku ew tê de beşdar dibe.
Hilbijartina eşkere ev e ku meriv pergala destûrên Linux-ê bikar bîne.

Wekî ku berê jî behs kir, ji bo gihîştina ssh tenê yek hesabek bikar tîne. Ev veavakirin ji bo çend bikarhêneran ne ewle ye, her çend ew di navnîşa vebijarkên git-ê yên pêşniyarkirî de cih digire.

Ji bo bicihanîna daxwazên ku di destpêka gotarê de hatine dayîn, strukturên pelrêça jêrîn bi tayînkirina maf û xwedan têne afirandin:

1) derhênerên projeyê

dir1(proj1:proj1,0770)
dir2(proj2:proj2,0770)
dir3(proj3:proj3,0770)
...
ko
dir1, dir2, dir3 - pelrêça projeyê: proje 1, proje 2, proje 3.

proj1:proj1, proj2:proj2, proj3:proj3 bi taybetî bikarhênerên Linux-ê hatine afirandin ku wekî xwedan pelrêçikên projeyê yên têkildar têne destnîşan kirin.

destûrên ji bo hemî peldankan li 0770 hatine danîn - gihîştina tam ji bo xwedan û koma wî û qedexeyek bêkêmasî ji bo her kesê din.

2) hesabên pêşdebiran

Разработчик 1: dev1:dev1,proj1,proj2
Разработчик 2: dev2:dev2,proj2,proj3

Xala sereke ev e ku ji pêşdebiran re komeke din a xwediyê bikarhênerê pergalê ya projeya têkildar tê destnîşankirin. Ev ji hêla rêveberê servera Linux ve bi yek fermanê ve tête kirin.

Di vê nimûneyê de, "Developer 1" li ser projeyên proj1 û proj2 dixebite, û "Developer 2" li ser projeyên proj2 û proj3 dixebite.

Ger yek ji Pêşdebiran bi ssh-ê bi rêzika fermanê ve girêbide, wê hingê mafên wan ji bo dîtina naveroka peldankên projeyê yên ku ew tê de ne beşdar in jî têrê nakin. Ew bi xwe nikare vê yekê biguherîne.

Ji ber ku bingeha vê prensîbê ewlehiya bingehîn a mafên Linux-ê ye, ev plan pêbawer e. Digel vê yekê, birêvebirina plansaziyê pir hêsan e.

Werin em derbasî pratîkê bibin.

Afirandina depoyên Git li ser serverek Linux

Kontrolkirin.

[root@server ~]# cd /var/
[root@server var]# useradd gitowner
[root@server var]# mkdir gitservertest
[root@server var]# chown gitowner:gitowner gitservertest
[root@server var]# adduser proj1
[root@server var]# adduser proj2
[root@server var]# adduser proj3
[root@server var]# adduser dev1
[root@server var]# adduser dev2
[root@server var]# passwd dev1
[root@server var]# passwd dev2

Ez ji nivîsandina bi destî westiyame...

[root@server gitservertest]# sed "s/ /n/g" <<< "proj1 proj2 proj3" | while read u; do mkdir $u; chown $u:$u $u; chmod 0770 $u; done

[root@server gitservertest]# usermod -aG proj1 dev1
[root@server gitservertest]# usermod -aG proj2 dev1
[root@server gitservertest]# usermod -aG proj2 dev2
[root@server gitservertest]# usermod -aG proj3 dev2

Em pê bawer in ku ne mimkûn e ku meriv ji rêza fermanê bigihîje depoyên kesên din û tewra naveroka wan jî bibîne.

[dev1@server ~]$ cd /var/gitservertest/proj3
-bash: cd: /var/gitservertest/proj3: Permission denied
[dev1@server ~]$ ls /var/gitservertest/proj3
ls: cannot open directory /var/gitservertest/proj3: Permission denied

Li ser heman projeyê li Git bi gelek pêşdebiran re hevkariyê bikin

Pirsek dimîne, heke pêşdebirek pelek nû destnîşan bike, wê hingê pêşdebirên din nikanin wê biguhezînin, ji ber ku ew bixwe xwediyê wê ye (mînak, dev1), û ne xwediyê bikarhênerê projeyê (mînak, proj1). Ji ber ku me depoyek server-side heye, berî her tiştî, divê em zanibin ka pelrêça ".git" çawa hatî çêkirin û ka pelên nû têne çêkirin an na.

Afirandina depoyek Git ya herêmî û xistina servera Git

Ka em biçin ser makîneya xerîdar.

Microsoft Windows [Version 6.1.7601]
(c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены.

C:gittest>git init .
Initialized empty Git repository in C:/gittest/.git/

C:gittest>echo "test dev1 to proj2" > test1.txt

C:gittest>git add .

C:gittest>git status
On branch master
No commits yet
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   test1.txt

C:gittest>git commit -am "new test file added"
[master (root-commit) a7ac614] new test file added
 1 file changed, 1 insertion(+)
 create mode 100644 test1.txt
 
C:gittest>git remote add origin "ssh://[email protected]/var/gitservertest/proj2"

C:gittest>git push origin master
dev1:[email protected]'s password:
Counting objects: 3, done.
Writing objects: 100% (3/3), 243 bytes | 243.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://10.1.1.11/var/gitservertest/proj2
 * [new branch]      master -> master

C:gittest>

Di heman demê de, pelên nû li ser serverê têne afirandin, û ew aîdî bikarhênerê ne ku pêvek pêk aniye

[dev1@server proj2]$ tree
.
├── 1.txt
├── branches
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── prepare-commit-msg.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   └── update.sample
├── info
│   └── exclude
├── objects
│   ├── 75
│   │   └── dcd269e04852ce2f683b9eb41ecd6030c8c841
│   ├── a7
│   │   └── ac6148611e69b9a074f59a80f356e1e0c8be67
│   ├── f0
│   │   └── 82ea1186a491cd063925d0c2c4f1c056e32ac3
│   ├── info
│   └── pack
└── refs
    ├── heads
    │   └── master
    └── tags

12 directories, 18 files
[dev1@server proj2]$ ls -l objects/75/dcd269e04852ce2f683b9eb41ecd6030c8c841
-r--r--r--. 1 dev1 dev1 54 Jun 20 14:34 objects/75/dcd269e04852ce2f683b9eb41ecd6030c8c841
[dev1@server proj2]$

Dema ku hûn guheztinan li servera Git bar dikin, pel û peldankên zêde têne afirandin, û xwediyê wan bi rastî bikarhênerê ku barkirinê dike ye. Lê dûv re koma van pel û peldankan jî bi koma sereke ya vê bikarhênerê re têkildar e, ango koma dev1 ji bo bikarhênerê dev1 û koma dev2 ji bo bikarhênerê dev2 (guhertina koma sereke ya bikarhênerê pêşdebir dê ne alîkar be, ji ber ku wê hingê hûn çawa dikarin li ser pir projeyan bixebitin?). Di vê rewşê de, bikarhêner dev2 dê nikaribe pelên ku ji hêla bikarhêner dev1 ve hatî afirandin biguhezîne, ku dikare bibe sedema têkçûna fonksiyonê.

Linux chown - guhertina xwediyê pelê ji hêla bikarhênerek birêkûpêk

Xwediyê dosyayê nikare xwedîtiya wê biguhere. Lê ew dikare koma pelek ku aîdê wî ye biguhezîne, û paşê ev pel dikare ji hêla bikarhênerên din ên ku di heman komê de ne were guheztin. Ya ku em hewce ne ev e.

Bikaranîna Git hook

Peldanka xebatê ya hook pelrêça root ya projeyê ye. hook darvekirinek e ku di binê bikarhênerê ku pêlê dike de dimeşe. Bi zanîna vê, em dikarin planên xwe pêk bînin.

[dev1@server proj2]$ mv hooks/post-update{.sample,}
[dev1@server proj2]$ sed -i '2,$ s/^/#/' hooks/post-update
[dev1@server proj2]$ cat <<< 'find . -group $(whoami) -exec chgrp proj2 '"'"'{}'"'"' ;' >> hooks/post-update

yan tenê

vi hooks/post-update

Ka em vegerin ser makîneya xerîdar.

C:gittest>echo "dev1 3rd line" >> test1.txt

C:gittest>git commit -am "3rd from dev1, testing server hook"
[master b045e22] 3rd from dev1, testing server hook
 1 file changed, 1 insertion(+)

C:gittest>git push origin master
dev1:[email protected]'s password:
   d22c66e..b045e22  master -> master

Li ser servera Git-ê, em xebata skrîpta paşîn-nûvekirinê ya hook-ê piştî peywirê kontrol dikin

[dev1@server proj2]$ find . ! -group proj2

- vala, her tişt baş e.

Girêdana pêşdebirek duyemîn li Git

Werin em xebata pêşdebirê duyemîn simul bikin.

Li ser muwekîlê

C:gittest>git remote remove origin

C:gittest>git remote add origin "ssh://[email protected]/var/gitservertest/proj2"

C:gittest>echo "!!! dev2 added this" >> test1.txt

C:gittest>echo "!!! dev2 wrote" > test2.txt

C:gittest>git add test2.txt

C:gittest>git commit -am "dev2 added to test1 and created test2"
[master 55d49a6] dev2 added to test1 and created test2
 2 files changed, 2 insertions(+)
 create mode 100644 test2.txt

C:gittest>git push origin master
[email protected]'s password:
   b045e22..55d49a6  master -> master

Û di heman demê de, li ser serverê ...

[dev1@server proj2]$ find . ! -group proj2

- dîsa vala, her tişt dixebite.

Projeyek Git jêbirin û projeyê ji servera Git dakêşin

Welê, hûn dikarin careke din piştrast bikin ku hemî guhertin hatine tomar kirin.

C:gittest>rd /S /Q .
Процесс не может получить доступ к файлу, так как этот файл занят другим процессом.

- ji bo jêbirina projeyek Git, bi tenê pelrêça bi tevahî paqij bikin. Werin em bi xeletiya ku hatî çêkirin rabigirin, ji ber ku ne gengaz e ku pelrêça heyî bi karanîna vê fermanê jêbirin, lê ev tam tevgera ku em hewce ne.

C:gittest>dir
 Содержимое папки C:gittest

21.06.2019  08:43    <DIR>          .
21.06.2019  08:43    <DIR>          ..

C:gittest>git clone ssh://[email protected]/var/gitservertest/proj2
Cloning into 'proj2'...
[email protected]'s password:

C:gittest>cd proj2

C:gittestproj2>dir
 Содержимое папки C:gittestproj2

21.06.2019  08:46    <DIR>          .
21.06.2019  08:46    <DIR>          ..
21.06.2019  08:46               114 test1.txt
21.06.2019  08:46                19 test2.txt
C:gittestproj2>type test1.txt
"test dev1 to proj2"
"dev1 added some omre"
"dev1 3rd line"
"!!! dev2 added this"

C:gittestproj2>type test2.txt
"!!! dev2 wrote"

Parvekirina gihîştina li Git

Naha em pê ewle bin ku tewra bi navgîniya Git pêşdebirê duyemîn nikane xwe bigihîne projeya Proj1, ya ku ew li ser naxebite.

C:gittestproj2>git remote remove origin

C:gittestproj2>git remote add origin "ssh://[email protected]/var/gitservertest/proj1"

C:gittestproj2>git push origin master
[email protected]'s password:
fatal: '/var/gitservertest/proj1' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Niha em destûrê didin gihîştinê

[root@server ~]# usermod -aG proj1 dev2

û piştî ku her tişt dixebite.

C:gittestproj2>git push origin master
[email protected]'s password:
To ssh://10.1.1.11/var/gitservertest/proj1
 * [new branch]      master -> master

Ji bo agahiyên zêdetir,

Wekî din, heke di çêkirina pel û peldankan de di destûrên xwerû de pirsgirêkek hebe, di CentOS de hûn dikarin fermanê bikar bînin

setfacl -Rd -m o::5 -m g::7 /var/gitservertest

Di heman demê de di gotarê de hûn dikarin li tiştên piçûk ên bikêr bikevin:

• Meriv çawa di Linux de darek pelrêça ava dike
• meriv çawa rêzek navnîşanan di sed-ê de ji rêzek diyar heya dawiya pelê derbas dike, ango di hemî rêzan de ji xeynî rêza yekem di hemî rêzan de veguheztinek çêbike
• Meriv çawa şertek lêgerînê di Find Linux de vedigere
• Meriv çawa bi karanîna yek-xêzikek di şêlê Linux-ê de çend rêzan di nav lûkê de derbas dike
• Meriv çawa di bash de ji bêjeyên yekane direve
• meriv çawa pelrêçekek bi hemî naverokên wê di rêzika fermanê ya windows de jêbirin
• Meriv çawa bash mv bikar tîne da ku navek pelê biguhezîne bêyî ku wê ji nû ve binivîsîne

Spas ji bo baldariya te.

Source: www.habr.com