En aquest punt, hauríeu de tenir un repositori Git de bona fe a la vostra màquina local, i una còpia de treball o working copy de tots els seus fitxers davant vostre. Normalment, voldreu començar a fer canvis i confirmar instantànies d’aquests canvis al vostre repositori cada vegada que el projecte arribi a un estat que vulgueu registrar.
Recordeu que cada fitxer al vostre directori de treball pot estar en un de dos estats: tracked o untracked. Els fitxers tracked són els que estaven a l’última instantània, així com qualsevol fitxer nou afegit a l’àrea d’staging; poden estar sense modificar, modificats o preparats. En resum, els fitxers tracked són fitxers que Git coneix.
Els fitxers untracked són tots els altres: qualsevol fitxer al vostre directori de treball que no estava a l’última instantània i no està a la vostra àrea d’staging. Quan cloneu un repositori per primera vegada, tots els vostres fitxers estaran tracked i sense modificar perquè Git acaba de fer-los checkout i no heu editat res.
A mesura que editeu fitxers, Git els veu com a modificats, perquè els heu canviat des del vostre últim commit. A mesura que treballeu, seleccioneu aquests fitxers modificats i després confirmeu tots aquests canvis preparats, i el cicle es repeteix.
L’eina principal que utilitzeu per determinar quins fitxers estan en quin estat és la comanda git status.
Si executeu aquesta comanda immediatament després d’un clonatge, hauríeu de veure alguna cosa com això:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree cleanAixò significa que teniu un directori de treball net; en altres paraules, cap dels vostres fitxers tracked està modificat.
Git tampoc veu cap fitxer untracked, o es llistarien aquí.
Finalment, la comanda us diu en quina branca esteu i us informa que no ha divergit de la mateixa branca al servidor.
Per ara, aquesta branca sempre és master, que és la predeterminada; no us preocupareu per això aquí.
ch03-git-branching.asc explicarà les branques i les referències en detall.
|
Note
|
GitHub va canviar el nom de la branca predeterminada de No obstant això, Git en si encara utilitza |
Suposem que afegiu un nou fitxer al vostre projecte, un fitxer README senzill.
Si el fitxer no existia abans, i executeu git status, veureu el vostre fitxer untracked així:
$ echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
README
nothing added to commit but untracked files present (use "git add" to track)Podeu veure que el vostre nou fitxer README està untracked, perquè està sota l’encapçalament “Untracked files” a la sortida del vostre estat.
Untracked bàsicament significa que Git veu un fitxer que no teníeu a l’instantània anterior (commit), i que encara no s’ha preparat; Git no començarà a incloure’l a les vostres instantànies de commit fins que li digueu explícitament que ho faci.
Ho fa perquè no comenceu accidentalment a incloure fitxers binaris generats o altres fitxers que no volíeu incloure.
Voleu començar a incloure README, així que comencem a fer un seguiment del fitxer.
Per començar a fer un seguiment d’un fitxer nou, utilitzeu la comanda git add.
Per començar a fer un seguiment del fitxer README, podeu executar això:
$ git add READMESi executeu la vostra comanda d’estat una altra vegada, podeu veure que el vostre fitxer README ara està tracked i preparat per ser confirmat:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: READMEPodeu dir que està preparat perquè està sota l’encapçalament “Changes to be committed”.
Si confirmeu en aquest punt, la versió del fitxer en el moment que vau executar git add és el que estarà a l’instantània històrica posterior.
Podeu recordar que quan vau executar git init abans, vau executar git add <files> — això era per començar a fer un seguiment dels fitxers al vostre directori.
La comanda git add pren un nom de ruta per a un fitxer o un directori; si és un directori, la comanda afegeix tots els fitxers d’aquest directori de manera recursiva.
Modifiquem un fitxer que ja estava tracked.
Si modifiqueu un fitxer tracked anterior anomenat CONTRIBUTING.md i després executeu la vostra comanda git status una altra vegada, obteniu alguna cosa que sembla això:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.mdEl fitxer CONTRIBUTING.md apareix sota una secció anomenada “Changes not staged for commit” — el que significa que un fitxer que està tracked ha estat modificat al directori de treball però encara no s’ha preparat.
Per preparar-lo, executeu la comanda git add.
git add és una comanda multiusos: l’utilitzeu per començar a fer un seguiment de fitxers nous, per preparar fitxers, i per fer altres coses com marcar fitxers amb conflictes de fusió com a resolts.
Pot ser útil pensar-hi més com a “afegeix precisament aquest contingut al proper commit” en lloc de “afegeix aquest fitxer al projecte”.
Executeu git add ara per preparar el fitxer CONTRIBUTING.md, i després executeu git status una altra vegada:
$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.mdEls dos fitxers estan preparats i aniran al vostre proper commit.
En aquest punt, suposem que recordeu un petit canvi que voleu fer a CONTRIBUTING.md abans de confirmar-lo.
L’obriu una altra vegada i feu aquest canvi, i esteu llest per confirmar.
No obstant això, executem git status una vegada més:
$ vim CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.mdQuè passa aquí?
Ara CONTRIBUTING.md es llista com a preparat i no preparat.
Com és possible?
Resulta que Git prepara un fitxer exactament com és quan executeu la comanda git add.
Si confirmeu ara, la versió del fitxer CONTRIBUTING.md tal com era quan vau executar la comanda git add per última vegada és com anirà al commit, no la versió del fitxer tal com es veu al vostre directori de treball quan executeu git commit.
Si modifiqueu un fitxer després d’executar git add, heu d’executar git add una altra vegada per preparar l’última versió del fitxer:
$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.mdTot i que la sortida de git status és bastant completa, també és força verborràgica.
Git també té una bandera d’estat curt perquè pugueu veure els vostres canvis de manera més compacta.
Si executeu git status -s o git status --short obteniu una sortida molt més simplificada de la comanda:
$ git status -s
M README
MM Rakefile
A lib/git.rb
M lib/simplegit.rb
?? LICENSE.txtEls fitxers nous que no estan tracked tenen un ?? al costat, els fitxers nous que s’han afegit a l’àrea d’staging tenen una A, els fitxers modificats tenen una M i així successivament.
Hi ha dues columnes a la sortida: la columna de l’esquerra indica l’estat de l’àrea d’staging i la columna de la dreta indica l’estat de l’arbre de treball.
Per exemple, a aquesta sortida, el fitxer README està modificat al directori de treball però encara no està preparat, mentre que el fitxer lib/simplegit.rb està modificat i preparat.
El fitxer Rakefile va ser modificat, preparat i després modificat una altra vegada, així que hi ha canvis que estan tant preparats com no preparats.
Sovint, tindreu una classe de fitxers que no voleu que Git afegeixi automàticament o fins i tot us mostri com a untracked.
Aquests solen ser fitxers generats automàticament com ara fitxers de registre o fitxers produïts pel vostre sistema de compilació.
En aquests casos, podeu crear un fitxer que llisti patrons per coincidir amb ells anomenat .gitignore.
Aquí teniu un exemple de fitxer .gitignore:
$ cat .gitignore
*.[oa]
*~La primera línia diu a Git que ignori qualsevol fitxer que acabi en “.o” o “.a” — fitxers objecte i arxiu que poden ser el producte de la compilació del vostre codi.
La segona línia diu a Git que ignori tots els fitxers els noms dels quals acaben amb una tilde (~), que és utilitzada per molts editors de text com Emacs per marcar fitxers temporals.
També podeu incloure un directori de registre, tmp o pid; documentació generada automàticament; i així successivament.
Configurar un fitxer .gitignore per al vostre nou repositori abans de començar és generalment una bona idea perquè no confirmeu accidentalment fitxers que realment no voleu al vostre repositori Git.
Les regles per als patrons que podeu posar al fitxer .gitignore són les següents:
-
Les línies en blanc o les línies que comencen amb
#s’ignoren. -
Els patrons glob estàndard funcionen i s’aplicaran de manera recursiva a tot l’arbre de treball.
-
Podeu començar patrons amb una barra inclinada (
/) per evitar la recursivitat. -
Podeu acabar patrons amb una barra inclinada (
/) per especificar un directori. -
Podeu negar un patró començant-lo amb un signe d’exclamació (
!).
Els patrons glob són com expressions regulars simplificades que utilitzen les shells.
Un asterisc () coincideix amb zero o més caràcters; [abc] coincideix amb qualsevol caràcter dins dels claudàtors (en aquest cas a, b o c); un signe d’interrogació (?) coincideix amb un sol caràcter; i els claudàtors que contenen caràcters separats per un guió ([0-9]) coincideixen amb qualsevol caràcter entre ells (en aquest cas de 0 a 9).
També podeu utilitzar dos asteriscs per coincidir amb directoris aniuats; a/*/z coincidiria amb a/z, a/b/z, a/b/c/z, i així successivament.
Aquí teniu un altre exemple de fitxer .gitignore:
# ignora tots els fitxers .a
*.a
# però segueix el fitxer lib.a, encara que estigueu ignorant els fitxers .a més amunt
!lib.a
# ignora només el fitxer TODO al directori actual, no subdir/TODO
/TODO
# ignora tots els fitxers a qualsevol directori anomenat build
build/
# ignora doc/notes.txt, però no doc/server/arch.txt
doc/*.txt
# ignora tots els fitxers .pdf al directori doc/ i qualsevol dels seus subdirectoris
doc/**/*.pdf|
Tip
|
GitHub manté una llista bastant completa de bons exemples de fitxers |
|
Note
|
En el cas simple, un repositori pot tenir un únic fitxer Està fora de l’abast d’aquest llibre entrar en els detalls de múltiples fitxers |
Si la comanda git status és massa vaga per a vostè: voleu saber exactament què heu canviat, no només quins fitxers han canviat, podeu utilitzar la comanda git diff.
Cobrirem git diff amb més detall més endavant, però probablement l’utilitzareu més sovint per respondre aquestes dues preguntes: Què heu canviat però encara no heu preparat?
I què heu preparat que esteu a punt de confirmar?
Tot i que git status respon aquestes preguntes de manera molt general llistant els noms dels fitxers, git diff us mostra les línies exactes afegides i eliminades: el parche, per dir-ho així.
Suposem que editeu i prepareu el fitxer README una altra vegada i després editeu el fitxer CONTRIBUTING.md sense preparar-lo.
Si executeu la vostra comanda git status, veureu alguna cosa com això una altra vegada:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.mdPer veure què heu canviat però encara no heu preparat, escriviu git diff sense altres arguments:
$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
Please include a nice description of your changes when you submit your PR;
if we have to read the whole diff to figure out why you're contributing
in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.
If you are starting to work on a particular area, feel free to submit a PR
that highlights your work in progress (and note in the PR title that it'sAquesta comanda compara el que hi ha al vostre directori de treball amb el que hi ha a la vostra àrea d’staging. El resultat us diu els canvis que heu fet i que encara no heu preparat.
Si voleu veure què heu preparat que anirà al vostre proper commit, podeu utilitzar git diff --staged.
Aquesta comanda compara els vostres canvis preparats amb el vostre últim commit:
$ git diff --staged
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+My ProjectÉs important tenir en compte que git diff per si sol no mostra tots els canvis fets des del vostre últim commit: només els canvis que encara no estan preparats.
Si heu preparat tots els vostres canvis, git diff no us donarà cap sortida.
Per a un altre exemple, si prepareu el fitxer CONTRIBUTING.md i després l’editeu, podeu utilitzar git diff per veure els canvis al fitxer que estan preparats i els canvis que no ho estan.
Si el nostre entorn sembla això:
$ git add CONTRIBUTING.md
$ echo '# test line' >> CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: CONTRIBUTING.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.mdAra podeu utilitzar git diff per veure què encara no està preparat:
$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 643e24f..87f08c8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -119,3 +119,4 @@ at the
## Starter Projects
See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md).
+# test linei git diff --cached per veure què heu preparat fins ara (--staged i --cached són sinònims):
$ git diff --cached
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
Please include a nice description of your changes when you submit your PR;
if we have to read the whole diff to figure out why you're contributing
in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.
If you are starting to work on a particular area, feel free to submit a PR
that highlights your work in progress (and note in the PR title that it's|
Note
|
Git Diff en una Eina Externa
Continuarem utilitzant la comanda |
Ara que la vostra àrea d’staging està configurada de la manera que voleu, podeu confirmar els vostres canvis.
Recordeu que qualsevol cosa que encara no estigui preparada: qualsevol fitxer que hàgiu creat o modificat i que no hàgiu executat git add des que l’heu editat, no anirà a aquest commit.
Es mantindran com a fitxers modificats al vostre disc.
En aquest cas, suposem que l’última vegada que vau executar git status, vau veure que tot estava preparat, així que esteu llest per confirmar els vostres canvis.
La manera més senzilla de confirmar és escriure git commit:
$ git commitFer això llança el vostre editor de preferència.
|
Note
|
Això es configura per la variable d’entorn |
L’editor mostra el següent text (aquest exemple és una pantalla de Vim):
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
# new file: README
# modified: CONTRIBUTING.md
#
~
~
~
".git/COMMIT_EDITMSG" 9L, 283CPodeu veure que el missatge de commit predeterminat conté l’última sortida de la comanda git status comentada i una línia buida a dalt.
Podeu eliminar aquests comentaris i escriure el vostre missatge de commit, o podeu deixar-los allí per ajudar-vos a recordar què esteu confirmant.
|
Note
|
Per a un recordatori encara més explícit del que heu modificat, podeu passar l’opció |
Quan sortiu de l’editor, Git crea el vostre commit amb aquest missatge de commit (amb els comentaris i el diff eliminats).
Alternativament, podeu escriure el vostre missatge de commit en línia amb la comanda commit especificant-lo després d’una bandera -m, així:
$ git commit -m "Story 182: fix benchmarks for speed"
[master 463dc4f] Story 182: fix benchmarks for speed
2 files changed, 2 insertions(+)
create mode 100644 READMEAra heu creat el vostre primer commit!
Podeu veure que el commit us ha donat alguna sortida sobre si mateix: en quina branca heu confirmat (master), quin checksum SHA-1 té el commit (463dc4f), quants fitxers han canviat, i estadístiques sobre línies afegides i eliminades al commit.
Recordeu que el commit registra l’instantània que heu configurat a la vostra àrea d’staging. Qualsevol cosa que no hàgiu preparat encara està al vostre disc com a fitxers modificats; podeu fer un altre commit per afegir-lo al vostre historial. Cada vegada que realitzeu un commit, esteu registrant una instantània del vostre projecte a la qual podeu revertir o comparar més endavant.
Tot i que pot ser increïblement útil per crear commits exactament com els voleu, l’àrea d’staging és de vegades una mica més complexa del que necessiteu al vostre flux de treball.
Si voleu ometre l’àrea d’staging, Git proporciona un drecera senzilla.
Afegir l’opció -a a la comanda git commit fa que Git prepari automàticament cada fitxer que ja està tracked abans de fer el commit, permetent-vos ometre la part git add:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -a -m 'Add new benchmarks'
[master 83e38c7] Add new benchmarks
1 file changed, 5 insertions(+), 0 deletions(-)Noteu com no heu d’executar git add al fitxer CONTRIBUTING.md en aquest cas abans de confirmar.
Això és perquè la bandera -a inclou tots els fitxers canviats.
Això és convenient, però tingueu cura; de vegades aquesta bandera us farà incloure canvis no desitjats.
Per eliminar un fitxer de Git, heu d’eliminar-lo dels vostres fitxers tracked (més precisament, eliminar-lo de la vostra àrea d’staging) i després confirmar.
La comanda git rm fa això, i també elimina el fitxer del vostre directori de treball perquè no el vegeu com a fitxer untracked la propera vegada.
Si simplement elimineu el fitxer del vostre directori de treball, apareix sota l’àrea “Changes not staged for commit” (és a dir, unstaged) de la sortida del vostre git status:
$ rm PROJECTS.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: PROJECTS.md
no changes added to commit (use "git add" and/or "git commit -a")Llavors, si executeu git rm, prepara l’eliminació del fitxer:
$ git rm PROJECTS.md
rm 'PROJECTS.md'
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
deleted: PROJECTS.mdLa propera vegada que confirmeu, el fitxer hauran desaparegut i ja no estarà tracked.
Si heu modificat el fitxer o l’havíeu afegit ja a l’àrea d’staging, heu de forçar l’eliminació amb l’opció -f.
Això és una característica de seguretat per prevenir l’eliminació accidental de dades que encara no s’han registrat en una instantània i que no es poden recuperar de Git.
Una altra cosa útil que potser voleu fer és mantenir el fitxer al vostre arbre de treball però eliminar-lo de la vostra àrea d’staging.
En altres paraules, podeu voler mantenir el fitxer al vostre disc dur però que Git ja no el faci un seguiment.
Això és especialment útil si us heu oblidat d’afegir alguna cosa al vostre fitxer .gitignore i l’heu preparat accidentalment, com un fitxer de registre gran o un munt de fitxers .a compilats.
Per fer això, utilitzeu l’opció --cached:
$ git rm --cached READMEPodeu passar fitxers, directoris i patrons de fitxers glob a la comanda git rm.
Això significa que podeu fer coses com:
$ git rm log/\*.logNoteu la barra invertida (\) davant de l'`*.
Això és necessari perquè Git fa la seva pròpia expansió de noms de fitxers a més de l’expansió de noms de fitxers de la vostra shell.
Aquesta comanda elimina tots els fitxers que tenen l’extensió `.log al directori log/.
O, podeu fer alguna cosa com això:
$ git rm \*~Aquesta comanda elimina tots els fitxers els noms dels quals acaben amb una ~.
A diferència de molts altres VCS, Git no fa un seguiment explícit del moviment de fitxers. Si canvieu el nom d’un fitxer a Git, no s’emmagatzema cap metadada a Git que li digui que heu canviat el nom del fitxer. No obstant això, Git és prou intel·ligent per esbrinar-ho després dels fets: tractarem la detecció del moviment de fitxers una mica més endavant.
Així que és una mica confús que Git tingui una comanda mv.
Si voleu canviar el nom d’un fitxer a Git, podeu executar alguna cosa com:
$ git mv file_from file_toi funciona bé. De fet, si executeu alguna cosa com això i mireu l’estat, veureu que Git el considera un fitxer canviat de nom:
$ git mv README.md README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> READMENo obstant això, això és equivalent a executar alguna cosa com això:
$ mv README.md README
$ git rm README.md
$ git add READMEGit esbrina que és un canvi de nom implícitament, així que no importa si canvieu el nom d’un fitxer d’aquesta manera o amb la comanda mv.
L’única diferència real és que git mv és una comanda en lloc de tres: és una funció de conveniència.
Encara més important, podeu utilitzar qualsevol eina que us agradi per canviar el nom d’un fitxer i tractar l'`add`/rm més tard, abans de confirmar.