Tervete kataloogipuude haldus ja jagamine

See peatükk koondab üheks töövooks käsud cp, rsync, scp, tar, zip ja Git-i loogika. Mõte ei ole korrata kõiki üksikkäske, vaid anda tervikpilt: mida teha siis, kui sul on vaja hallata või jagada tervet projektipuud.

Loogika

Kui liigud üksikfailidest edasi tervete kaustapuudeni, siis küsimus ei ole enam ainult “kuidas kopeerida üks fail”, vaid:

kas tahan teha kohaliku koopia
kas tahan saata puu teise masinasse
kas tahan teha ühest hetkest arhiivi
kas tahan jagada seda nii, et hiljem saaks muudatusi jälgida
kuidas kontrollida, et tulemus sai õige

Just siin lähevad tööriistad oma tugevuste järgi lahku.

Millal millist tööriista kasutada

cp -R sobib, kui tahad samas masinas teha lihtsa koopia
rsync -av sobib, kui tahad korduvat sünkroonimist või varundust
scp -r sobib, kui tahad kiiresti terve puu SSH kaudu teise masinasse saata
tar -czf või tar -cJf sobib, kui tahad ühest hetkest ühte arhiivifaili
zip -r sobib, kui jagad sisu inimestega, kes töötavad eri süsteemides
Git sobib, kui tahad mitte ainult jagada tulemust, vaid ka jälgida muudatusi ajas

Kohalik koopia: `cp`

Kui vajad ühekordset koopiat samas masinas, siis alusta lihtsast käsust:


cp -R projekt projekt-koopia

See on hea valik siis, kui:

tahad kiiresti proovida midagi teises koopias
tahad teha enne suuremat muutust kohaliku varu
allikas ja sihtkoht on samal masinal

Kui metaandmed loevad, siis GNU/Linuxis kasutatakse sageli:


cp -a projekt projekt-koopia

Seda tasub võtta kui “säilita nii palju kui võimalik”. Eri süsteemid ei käitu siin alati täpselt ühtemoodi.

Korduv sünkroonimine: `rsync`

Kui sama puud liigutatakse korduvalt, siis rsync on tavaliselt parem kui cp või scp.


rsync -av projekt/ projekt-varu/

Selle käsu tugevused:

saadab uuesti peamiselt muutunud sisu
säilitab struktuuri ja metaandmeid paremini
sobib nii lokaalseks kui kaugsünkroonimiseks

Oluline kaldkriipsu loogika:

projekt/ tähendab enamasti “selle kausta sisu”
projekt tähendab sagedamini “see kaust tervikuna”

Enne suuremat kopeerimist on väga mõistlik teha dry-run:


rsync -avn projekt/ projekt-varu/

Kui siht on serveris:


rsync -av projekt/ kasutaja@server:/srv/projekt/

Kiire ülekanne teise masinasse: `scp`

scp on hea siis, kui tahad lihtsalt midagi kiiresti teise masinasse saata:


scp -r projekt kasutaja@server:/tmp/

See on praktiline, kui:

vajad ühekordset üleslaadimist
sul ei ole vaja keerukamat sünkroonimisloogikat
SSH on juba seadistatud

Kui tahad võimalikult palju säilitada ajatemplite ja õiguste kohta, kasuta sageli:


scp -rp projekt kasutaja@server:/tmp/

Üks fail kogu puust: `tar`, `tgz`, `zip`

Kui tahad tervest puust teha ühe jagatava faili, siis sobib arhiiv:


tar -czf projekt-2026-04-13.tgz projekt/
tar -tf projekt-2026-04-13.tgz

See on hea valik siis, kui:

tahad saata ühe faili
tahad võtta kindla hetke snapshot'i
tahad arhiivi enne lahti pakkimata kontrollida

Kui adressaadil on tõenäoliselt Linux või macOS, on tar.gz või .tgz sageli loomulik valik.

Kui adressaadid on väga eri keskkondades, on zip mugav:


zip -r projekt.zip projekt/
unzip -l projekt.zip

Mis saab õigustest ja omanikest

Suure puu halduses on oluline eristada nelja asja:

faili sisu
failipuu struktuur
õigused
omanikud ja grupid

Rusikareeglid:

cp -R ja scp -r lahendavad eelkõige sisu ja struktuuri
rsync -a ja tar hoiavad Unix-laadset metaandmete pilti paremini koos
zip sobib rohkem jagamiseks kui täpseks Unix-i säilitamiseks
Git ei talleta tavaliselt omanikku, gruppi ega ajatemplite ajalugu

Git talletab hästi:

faili sisu
kataloogistruktuuri
tekstimuudatuste ajaloo
täidetavusbitte olulisemates juhtudes

Git ei ole varukoopia-arhiiv igas mõttes. See ei asenda tar-i ega rsync-i, kui tähtis on kogu failisüsteemi metaandmete võimalikult täpne ülekandmine.

Jagamine: arhiiv või GitHub

Kui eesmärk on lihtsalt “saada see tervik teisele inimesele”, siis mõtle nii:

üks ühekordne hetkeseis: tar.gz või zip
korduv uuendamine serverisse: rsync
ühine arendus ja muudatuste ajalugu: Git + GitHub

Seega:

andmepuu või snapshot: arhiiv
deploy või varu: rsync
koostöö ja versioonihaldus: Git

Kuidas kontrollida, et said õige asja

Suure puu juures on kontroll sama tähtis kui kopeerimine ise.

Kõige praktilisemad kontrollid:

vaata failide arvu ja suurust
loe arhiivi sisu ilma lahti pakkimata
tee rsync-iga dry-run
võrdle vähemalt mõne võtmefaili räsi

Näited:


du -sh projekt projekt-koopia
find projekt | wc -l
find projekt-koopia | wc -l


tar -tf projekt-2026-04-13.tgz | head
unzip -l projekt.zip


shasum -a 256 projekt/README.md projekt-koopia/README.md

Linuxis on sama loogika sageli kujul:


sha256sum projekt/README.md projekt-koopia/README.md

Soovitatud töövood

1. Enne riskantset muutust


rsync -av projekt/ projekt-varu/

2. Saada tervik serverisse


rsync -avn projekt/ kasutaja@server:/srv/projekt/
rsync -av projekt/ kasutaja@server:/srv/projekt/

3. Tee jagatav snapshot


tar -czf projekt-$(date +%F).tgz projekt/
tar -tf projekt-$(date +%F).tgz | head

4. Jaga koostööks


git status
git add .
git commit -m 'Valmista projekt jagamiseks'
git push

Viimase töövoo detailid tulevad eraldi Git-i peatükis.

Minitest

Tee ühest testkaustast kohalik koopia käsuga cp -R.
Tee samast kaustast rsync -avn dry-run teise kausta.
Paki sama kaust .tgz faili ja kuva selle sisu käsuga tar -tf.
Mõtle ühe näite põhjal, kas sinu eesmärk on snapshot, sünkroonimine või koostöö ajalooga.