Què és Git? Prendre el control del control de la font

Suposem que esteu treballant en un gran projecte: el vostre darrer document per a una classe escolar o un informe sobre el vostre cap. El projecte és llarg i complicat, el gestioneu durant un període de mesos i feu moltes modificacions.

A continuació, deseu la vostra última còpia, Versió final del gran projecte i transmeteu-lo al vostre amic de confiança perquè el revisi. Detecten altres 100 errors ortogràfics menors, així que corregiu-los i deseu-los com a: Versió final del gran projecte 2.

Per estar segur, llegiu-lo una vegada més i decidiu que realment voleu tornar al que teníeu abans en diversos llocs. Hmm … com es va formular de nou exactament?

Guardar com: Versió final del gran projecte Final.

Guardar com: Gran projecte per a una última real.

Guardar com: Gran projecte FINAL.

Aleshores, els vostres amics de confiança topen amb el vostre gos i vessen cafè a l’ordinador i ho perdeu tot.

Us sembla familiar alguna part d’això?

Què és el control de fonts?

El control de la font és una solució a aquest problema. El control de la font és essencialment un sistema “d’estalvi”. Aquest és un programa que podeu utilitzar per organitzar les còpies desades, mirar fàcilment les versions anteriors, desar diverses versions en paral·lel i fer una còpia de seguretat de tot el projecte en diversos ordinadors.

Alguns programes personalitzats també inclouen sistemes que fan algunes parts d’aquest treball: Microsoft Office i Documents de Google teniu la possibilitat de veure, per exemple, el vostre historial de versions.

En el món de la programació, el sistema de gestió de fonts més utilitzat és Git. Altres importants són: Activitat subversiva i Mercurial. Centraré la meva descripció en Git, ja que aquest és l’únic sistema al qual he estat exposat.

Git Commits

Quan vulgueu desar un projecte a Git, creeu un repositori de git. Un repo és només una carpeta amb alguns fitxers ocults per fer un seguiment de les coses.

Podeu afegir el que vulgueu a aquesta carpeta (codi, imatges, còpies d’altres programes sencers). I git en pot fer un seguiment.

Tot el que heu de fer és “involucrar” periòdicament el vostre treball. Això posa una “marca de verificació” o “punt de desa” a l’historial i us permet tornar a aquesta versió més endavant si ho desitgeu.

Cada vegada que feu la vostra feina, voleu fer una instantània del vostre “compromís”. Probablement això sigui diverses vegades al dia, en funció del que estigueu treballant.

Branques Git

L’ús més bàsic de Git és el descrit anteriorment. Només heu de tenir un historial lineal del vostre treball i podeu anar endavant i enrere a través d’aquestes revisions. Aquesta és la història de Git amb només una clonar. Normalment aquesta branca rep el seu nom master, tot i que només és una convenció, no hi ha res d’especial.

Però molts projectes són més complexos que això i requereixen mantenir diverses versions lleugerament diferents alhora. Algunes d’aquestes versions poden fins i tot ser mútuament excloents. Agafeu el currículum d’un lampista, per exemple (poden mantenir-ne dues còpies actualitzades), una per trobar una feina que realment fa de fontaneria i una altra versió per obtenir una feina com a professor de lampista.

Aquests projectes tenen molts clons. Potser pel seu nom plumbingi una altra branca anomenada teaching.

A Git, escollim un punt de la història per on volem començar (que sovint és només l’últim compromís) i ens separem d’aquí.

Un altre ús comú de les sucursals és utilitzar-les per treballar en una nova característica o aspecte del vostre projecte, sense deixar la branca principal sense canvis. Això manté el mestre “net” i també us permet realitzar diverses tasques sense haver de completar-ne una abans de passar a la següent.

És possible que estigueu desant el codi de l’aplicació per prendre notes al repositori de Git. La següent tasca és afegir un botó “Comparteix” a l’aplicació. De manera que creeu una branca anomenada addShareButton. Ara que t’has compromès, master la versió no canvia. En canvi, només això addShareButton sucursal té aquests nous compromisos.

Un cop hàgiu acabat de treballar en la nova tasca en aquesta branca de tasques, podeu fer-ho fusió a la branca principal, la vostra versió principal també té aquests canvis. Ja no necessiteu aquesta branca de la tasca i la podeu suprimir. De nou, ara només teniu una versió bàsica a seguir.

Reposicions locals vs remotes

Fins ara, hem assumit principalment que esteu treballant sols en aquest projecte, però en un entorn laboral poques vegades és així. Probablement tindreu companys que treballen a la mateixa base de codi i volen fer canvis als mateixos fitxers, sovint al mateix temps que vosaltres. Llavors, com fer-ho sense ensopegar-nos?

Bé, primer fem una còpia de seguretat per un segon per parlar de com és git distribuït sistema de control de versions. Això significa que qualsevol persona pot tenir una còpia de l’historial complet del projecte. Si vosaltres i un company de feina treballeu junts en un projecte, tots dos podeu tenir una còpia del repositori de Git i Git us permetrà mantenir aquestes còpies sincronitzades entre si. Però cap d’aquestes còpies no és tècnicament la “còpia bàsica”: són iguals. El projecte acaba de passar distribuït entre diverses màquines.

Tenint en compte això, encara és útil pretendre que una còpia d’un repo sigui la còpia principal, especialment quan es treballa amb equips, i la majoria dels equips ho fan.

A més de tenir una còpia del repo als seus ordinadors de desenvolupament, també hi ha una còpia d’un servidor accessible per a tothom. Això centralitza i organitza el vostre treball; tothom pot acceptar tractar-ho com una “còpia bàsica”. Quan un desenvolupador individual completa una tasca, es compromet amb el seu treball i empenyent el ramifiquen amb això remotament servidor (normalment anomenat “remot” o “origin”. Aleshores, aquesta branca es pot combinar en master clonar.

Hi ha diversos avantatges clau en treballar amb un comandament a distància compartit i aconseguir que tothom premi el mateix repositori centralitzat:

  • És fàcil per a tothom mantenir-se al dia amb els temps tothom el treball d’una altra persona simplement descarregant els darrers canvis d’aquest repositori central a la seva còpia a la màquina. Sense ella, hauríeu de separar el vostre treball per cadascuna de les seves màquines per separat.
  • És menys probable que es perdin treballs si la vostra màquina mor inesperadament
  • Està clar quan s’acaba el treball: es fa quan s’ha combinat a la branca principal del comandament a distància.

Hi ha un altre avantatge clau que és extremadament poderós i que facilita la vida:

  • La reposició centralitzada es pot gestionar mitjançant GitHub o Bitbucket o qualsevol altre programari similar.

Sol·licituds de descàrrega, revisió de codi, sessions de comentaris

Github té moltes funcions. Proporciona una bona interfície per veure tots els compromisos i sucursals de la reposició, us permet veure l’historial de com estan interconnectats aquests canvis i també és un directori de milions de projectes.

Però potser la característica més útil que proporciona és la capacitat de crear Baixar consultes.

Una sol·licitud de baixada és una manera de sol·licitar que la vostra sucursal es fusioni amb la sucursal principal (o qualsevol sucursal). Mostra un resum dels canvis (que anomeneu diferència (o “diferència “) entre sucursals i permet als vostres col·legues revisar el vostre treball i deixar-hi comentaris abans de combinar-lo.

El revisor pot deixar comentaris / preguntes, marcar la seva aprovació, rebutjar la sol·licitud de baixada (que la rebutja temporalment mentre envieu els seus comentaris) o fusionar la sol·licitud de baixada.

Aquesta eina millorarà dràsticament la qualitat mitjana del codi al dipòsit, en part perquè els comentaris de la gent donaran suggeriments útils, i en part perquè s’esforça més quan se sap que algú revisarà el seu codi amb una dent fina. Si creueu cantonades o feu coses que sabeu que són mandroses o simplement s’equivoquen, probablement algú trobarà aquests errors.

Per tant, us fa responsable del vostre treball, però també és una protecció al vostre voltant. La vostra feina ja no és la vostra única responsabilitat: podeu comptar amb el vostre equip per ajudar-vos a notar els errors que heu perdut.

Per descomptat, això també significa que encara teniu feina a fer; heu de revisar el codi d’altres persones. I permeteu-me que us ho digui, sovint és més difícil que escriure el codi vosaltres mateixos. Heu d’intentar entendre què fa aquest codi des del petit context que podeu veure a la sol·licitud de baixada. Sovint això és impossible o és només una pèrdua de temps, i un millor enfocament podria ser mantenir una conversa de la vida real amb l’autor del codi o seure junts per revisar els canvis.

Això també pot ajudar a alleujar la tensió si creieu que el codi de la sol·licitud de descàrrega presenta alguns defectes importants o si heu notat tants errors que escriure’ls tots aclapararà, desanimarà o avergonyirà públicament l’autor. Totes aquestes coses són dolentes per fer a una persona, i cal recordar ser educat en revisar el treball d’algú. No l’enviarien a un examen si creien que era horrible.

Anem a fer-ho

Git és una potent eina per gestionar el treball compartit en equip. Permet mirar enrere en el temps, veure què fan entre ells i fer un camí clar sobre com es pot dir que es fa una cosa.

Afegiu Git al vostre repertori; això us convertirà en un candidat atractiu i millor desenvolupador. Sense haver de desar les versions de fitxers en carpetes separades, això us farà més organitzat.

I un dia potser us estalvieu d’un món de ferides quan vesseu cafè a l’ordinador.

Si us plau, seguiu i agrada:

Add a Comment

Your email address will not be published. Required fields are marked *