Soluții

Cum să restabiliți fișierele și folderele individuale la versiuni vechi în Git

Data 12/08/2022
Autor Bogdan Cliveti
0
96

Git este un instrument puternic pentru urmărirea fiecărei versiuni a bazei de cod și este adesea necesar să priviți înapoi în timp și să recuperați versiunile vechi ale fișierelor. Git poate anula comiterile întregi sau reseta întregul depozit, dar poate, de asemenea, să anuleze modificările aduse unui singur fișier sau folder.

Revenire vs. Resetare
De obicei, când „reveniți” un commit, Git aplică un nou commit, aplicând modificările opuse, anulând-o efectiv. Acest lucru este util dacă faceți o greșeală și trebuie să „ștergeți” acea comitere, deși este încă înregistrată în istoric.

Resetarea depozitului este puțin diferită. Puteți anula doar o comitere la un moment dat, dar dacă faceți o resetare git, Git va schimba complet starea repo-ului înapoi la momentul în care a fost făcută această comitare. Acest lucru se face din multe motive, de obicei pentru a șterge commit-urile sau a remedia istoricul ramurilor.

Ambele operațiuni funcționează pe întregul depozit, dar puteți folosi și comenzi similare pentru a efectua aceleași acțiuni pe fișiere sau foldere individuale. De exemplu, utilizarea git reset pe un singur fișier va restabili fișierul la modul în care a fost când a fost efectuată commit-ul. Acest lucru este util dacă doriți doar să alegeți o versiune veche a fișierului din istoricul Git.

Privind versiunile vechi în Git
Soluția low-tech pentru a seta un fișier înapoi la modul în care era înainte este destul de simplă — Github și majoritatea celorlalte servere Git țin evidența istoricului fișierelor dvs. și puteți face simplu clic pe un commit și faceți clic pe „Răsfoiește fișiere” pentru a vedea un un instantaneu al depozitului dvs. din trecut. Apoi puteți descărca fișierul sau puteți copia textul.

Acest lucru este util în special dacă lucrați cu fișiere de cod mari și doriți să vă uitați la versiunile vechi ale funcțiilor pe care le-ați scris. Probabil că nu doriți să anulați întregul lucru în acest caz, doar o singură funcție. Puteți copia codul din acea funcție fără a atinge CLI-ul Git.

Resetarea unui fișier la o versiune veche în Git
În acest depozit de testare, am făcut un commit care a editat README și a adăugat un fișier nou. Dorim să revenim la modificările făcute în README, dar nu vrem să resetam întregul repo înapoi la comiterea inițială.

Soluția este să resetați doar README, verificând o versiune veche a acelui fișier. Comanda de checkout a lui Git face o mulțime de lucruri, cum ar fi schimbarea ramurilor, dar este folosită practic pentru descărcarea fișierelor cu un ID de commit sau de ramură.

Pentru a reseta un fișier înapoi la o versiune veche, va trebui să găsiți ID-ul de comitere din momentul în care doriți să îl resetați. Puteți utiliza git log pentru aceasta, încadrat într-un singur fișier pentru a vedea numai modificările făcute în acel fișier:

git log README.md

Copiați ID-ul pentru comitere, apoi rulați git checkout cu ID-ul și calea fișierului:

git checkout 22710694b25d7ce5297559851beb7d3e4de811bb README.md

Acest lucru va schimba fișierul înapoi, dar nu va confirma încă modificările. Ești liber să-l editezi și să te angajezi când ești gata. În acest exemplu, git checkout a organizat modificările pentru următoarea comitere. Dacă nu doriți să le efectuați, sunteți liber să renunțați la modificări. Acest lucru poate fi util pentru a descărca temporar versiuni vechi de fișiere fără a utiliza Github.

Revenirea modificărilor la fișiere individuale
În mod similar, dacă doriți să anulați modificările într-un singur commit, puteți face acest lucru cu git revert. Cu toate acestea, nu există nicio modalitate de a-l aplica unui singur fișier, dar puteți pur și simplu să renunțați la modificări dacă commit-ul afectează alte fișiere.

Utilizați marcajul –no-commit pentru a permite editarea „comitarii inverse” pe care Git o creează automat.

git revert de8564b131ca6a15a7e7c73f5ef156b119cc0b93

Acest lucru vă va permite să schimbați fișierele înainte de a finaliza refacerea. Dacă există modificări nedorite în etape, le puteți elimina prin intermediul clientului dvs. sau cu un git checkout gol.

git checkout -- file

[mai mult...]

Cum să depanați erorile „Nu se poate conecta la Daemon Docker”.

Data 12/08/2022
Autor Bogdan Cliveti
0
167

Docker este una dintre platformele de top pentru construirea și rularea containerelor software. Vine cu tot ce aveți nevoie pentru a utiliza containere fie pe o singură gazdă, fie pe mai multe noduri distribuite în modul Swarm.

Simptomele problemei
Docker CLI se bazează pe o conexiune demon disponibilă. Interacționează cu demonul folosind apeluri API. Când demonul configurat este inaccesibil, comenzile docker precum docker ps, docker run și docker build vor afișa un mesaj de eroare similar cu acesta:

$ docker run hello-world:latest
Cannot connect to the Docker daemon at unix:///var/run/docker.sock
Is the docker daemon running?

Acest lucru dezvăluie că CLI a încercat să comunice cu demonul Docker folosind socket-ul Unix /var/run/docker.sock. Priza nu este deschisă, așa că conexiunea a eșuat.

1. Verificați că serviciul Docker Daemon rulează
Daemonul Docker este de obicei gestionat de un serviciu systemd care pornește automat Docker după repornirea gazdei. Puteți începe depanarea verificând dacă acest serviciu rulează:

$ sudo systemctl status docker
docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: inactive (dead)

Serviciul ar trebui să raporteze Active: activ (în rulare) dacă demonul rulează. Exemplul de mai sus arată inactiv (mort), ceea ce înseamnă că demonul s-a oprit.

Porniți Docker folosind următoarea comandă:

$ sudo systemctl start docker

Acum ar trebui să puteți rula cu succes comenzile docker CLI.

Este posibil să descoperiți că Docker rămâne în starea oprită după ce reporniți aparatul. Puteți rezolva acest lucru activând serviciul, permițând systemd să-l pornească automat:

$ sudo systemctl enable docker
$ sudo systemctl daemon-reload

Comanda daemon-reload instruiește systemd să-și reîncarce configurația pentru a aplica modificarea.

2. Porniți manual Daemonul
Este posibil să utilizați uneori un sistem care nu are instalat serviciul Docker. Puteți porni manual demonul Docker folosind comanda dockerd. Acesta trebuie de obicei rulat ca root.

$ sudo dockerd
INFO[2022-06-29T15:12:49.303428726+01:00] Starting up

Docker va rămâne accesibil atâta timp cât se execută comanda. Folosiți Ctrl+C pentru a opri demonul.

3. Verificarea CLI-ului vizează demonul corect
Pot apărea probleme atunci când CLI încearcă să se conecteze la o instanță demon Docker la distanță. Aceasta este de obicei cauza când mesajul de eroare arată o adresă TCP:

$ docker run hello-world:latest
Cannot connect to the Docker daemon at tcp:///0.0.0.0:2375

În acest exemplu, CLI-ul docker încearcă să contacteze demonul Docker la 0.0.0.0:2375 folosind TCP, în loc de socket-ul local Unix Docker. Acest lucru va eșua dacă suportul TCP al demonului Docker este dezactivat sau gazda specificată este inaccesibilă în rețea.

De obicei, puteți rezolva acest lucru trecând la contextul Docker CLI corect pentru conexiunea demon pe care doriți să o utilizați:

$ docker context use default

Puteți enumera toate contextele disponibile și punctele finale demon la care se conectează cu comanda context ls:

$ docker context ls
NAME        DESCRIPTION                               DOCKER ENDPOINT             
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock

Contextul selectat în prezent este evidențiat cu un asterisc.

Valorile neașteptate din coloana DOCKER ENDPOINT sunt de obicei cauzate de setarea variabilei de mediu DOCKER_HOST. Veți vedea un avertisment când acesta este cazul:

$ export DOCKER_HOST=1.2.3.4
$ docker context ls
NAME        DESCRIPTION                               DOCKER ENDPOINT
default *   Current DOCKER_HOST based configuration   tcp://1.2.3.4:2375
Warning: DOCKER_HOST environment variable overrides the active context. To use a context, either set the global --context flag, or unset DOCKER_HOST environment variable.

Prezența variabilei de mediu DOCKER_HOST în shell-ul dvs. suprascrie punctul final definit de contextul selectat. În acest exemplu, comenzile docker vor viza întotdeauna instanța demonului la tcp://1.2.3.4:2375.

Această problemă poate fi rezolvată prin ștergerea variabilei DOCKER_HOST:

$ export DOCKER_HOST=

Docker va folosi acum punctul final configurat de contextul dvs. activ. Acesta va fi socket-ul Unix local implicit la /var/run/docker.sock, cu excepția cazului în care ați configurat manual un context personalizat.

$ docker context ls
NAME        DESCRIPTION                               DOCKER ENDPOINT             
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock

4. Probleme cu permisiunile
Permisiunile incorecte ale utilizatorului pe socket-ul lui Docker sunt o altă cauză comună a problemelor de conexiune demon. Acest tip de problemă arată de obicei un mesaj de eroare ușor diferit:

$ docker run hello-world:latest
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

Acest lucru se întâmplă atunci când contul dvs. de utilizator Unix nu are permisiunea de a interacționa cu socket-ul care expune API-ul Docker. Adăugarea la grupul docker este cea mai bună metodă de a rezolva această problemă:

$ sudo usermod -aG docker $USER

Va trebui să deschideți o nouă fereastră shell sau să vă deconectați și să reveniți din nou pentru ca această modificare să intre în vigoare. Acum ar trebui să puteți rula comenzi Docker fără a avea probleme de permisiuni.

[mai mult...]