rudisoft scrie:Felicitări pentru proiect, este o idee grozavă.
Din păcate, lipsa timpului mă impiedică să pot face promisiuni în legătură cu implicarea activă, dar aș dori să urmăresc totuși proiectul, nu se știe niciodată...
De problema timpului ma lovesc si eu.
rudisoft scrie:Încerc să realizez primul pas, dar am probleme cu înțelegerea workflow-ului.
Probabil din cauză că sunt obișnuit cu SVN?
Am reușit să setez repository pe local, și să îl clonez pe cel de la
http://github.com/igstan/forum, dar atât.
După cum am spus deja, timpul nu îmi permite să mă ocup cum ar trebui, dar din câte am înțeles depozitul de la
http://github.com/igstan/forum este de fapt master sau echivalentul lui trunk din SVN, iar clona pe care o am eu pe local ca developer (echivalentul working-copy din SVN) este de fapt un branch local al depozitului master. Am înțeles bine până acum?
Am încercat să urmez exemplul lui alexcpp și am creat un depozit la adresa:
http://github.com/rudisoft/forum.
Dar aici m-am împotmolit. Ce relație are acest depozit cu master-ul de la igstan și cu copia mea locală de pe hdd (și cu copia lui alexcpp)?
Care sunt pașii de urmat în continuare?
In Git nu exista un repository master decat prin conventie. De obicei este
repository-ul celui care a inceput proiectul, insa poate fi apoi migrat catre
altul. Toate sunt insa egale pentru ca sunt clone reciproce. Spre examplu,
repo-ul meu local este clona repo-ului de pe GitHub, iar daca cel local se
corupe cumva, pot oricand sa il reclonez pe cel de pe GitHub si totul e ok.
Mai putin daca am avut cumva branch-uri locale nesincronizate cu GitHub.
Pentru mine, repo-ul de pe GitHub este originea, insa pot sa imi aduc si alte
repo-uri cu care sa ma sincronizez, cum ar fi cel al lui alexcpp. Atunci in loc
sa fac:
git pull origin master
pot face
git pull alexcpp master
unde repo-ul alexcpp a fost definit asa:
git remote add alexcpp
git://github.com/alexcpp/forum.git
In felul asta pot sa imi sincronizez repo-ul local direct cu repo-ul lui de pe
GitHub, fara sa mai treaca prin repo-ul meu de pe GitHub.
Cel mai usor pentru tine ar fi sa faci fork la repo-ul meu de pe GitHub. Exista
un buton de fork pe:
http://github.com/igstan/forum
Dupa fork, iti clonezi repo-ul local:
git clone
git@github.com:rudisoft/forum.git
operatiunea asta iti va defini repo-ul origin ca fiind:
git@github.com:rudisoft/forum.git
Acum poti sa modifici cod, iar cand simti ca e ok, sau cand vrei tu, il pui pe
GitHub:
git push origin master // trimiti doar codul de pe branch-ul master
In momentul asta, eu vreau modificarile tale, iar pentru asta imi definesc
un alt repo remote:
git remote add rudisoft
git://github.com/rudisoft/forum.git
Dupa care pot prelua cod de la tine:
git pull rudisoft master // sincronizez master-ul meu cu al tau
Ultima operatiune e foarte posibil sa dea conflicte, dar na, de-asta exista
sisteme de versionare.
Acum, mie imi place ca pe master sa am doar cod production ready, iar
codul care se afla inca in dezvoltare doar in branch-uri derivate din master.
Astea se numesc branch-uri topic, pentru ca abordeaza un singur topic in
principiu. Am de reparat un bug, imi creez un branch doar pentru repararea
acelui bug:
git checkout -b bug-001 master
-b inseamna "creaza branch", checkout inseamna schimba branch.
bug-001 este numele noului branch, care este derivat din master.
git branch iti va lista branch-urile, cel curent este prefixat de un asterisc (*)
Ok, acum pot modifica cod si repara bug-ul. Eventual, daca e ceva mai
complicat, pot trimite noul branch pe GitHub, pentru sharing eventual.
git push origin bug-001
La final, dupa ce sunt gata cu reparatul, pot sa fac merge intre branch-ul
bug-001 si master:
git checkout master
git merge bug-001
In momentul asta pot sa imi updatez si branch-ul master remote:
git push origin master.
Cam asta ar fi workflow-ul in mare. Oricum, sa stii ca spre deosebire de SVN,
care nu are decat conceptul de commit, Git (ca si alte sisteme distribuite) are
doua concepte: commit si push.
Commit-ul il faci din working tree in repo-ul tau local, apoi push faci dinspre
repo-ul local inspre altul remote.
Un alt lucru fain la Git este ca inainte sa faci commit, trebuie sa faci staging
la ceea ce vrei sa faci commit. Lucrul asta iti permite sa faci commit la nivel
de linie de cod, sau doar la cateva fisiere, chiar daca tu ai modificat mai multe.
Daca descarci o interfata grafica o sa intelegi mai bine lucrul asta. La nivel
de linie de comanda, lucrurile ar sta cam asa:
1. modific cod in 2 fisiere: foo.php si bar.php
2. verific ce fisiere am modificat:
git status
3. fac stage doar la foo.php
git add foo.php
4. commit (doar la ceea ce am facut stage)
git commit -m 'Am modificat foo.php'
5. fac stage si la al doilea fisier
git add bar.php
6. commit
git commit -m 'Am modificat bar.php'
7. acum pot eventual sa fac push
git push origin master // sau orice alt branch
Ok... acum ma intorc la treburile de la birou. Sper sa imi fac timp saptamana
asta si pentru proiectul asta.