GitLab — ano ito at paano gamitin kasama ng Git: clone, push, merge request, CI/CD

Ano ang GitLab

Ang GitLab ay platform kung saan iniimbak ang mga Git repository at binubuo sa paligid nito ang gawain ng team: pagtingin sa code, merge request, mga gawain, wiki, container registry, at built-in na CI/CD. Sa madaling sabi, ang GitLab ay «GitHub na may sariling build pipeline at posibilidad na i-deploy sa sarili mong server». Maraming kumpanya, lalo na ang malalaking enterprise, ang nag-iimbak ng kanilang code sa GitLab na naka-deploy sa internal network.

Nagsimula ang proyekto noong 2011 bilang open-source na app para sa code hosting, at mula roon lumaki ang kumpanyang GitLab Inc. May dalawang bersyon ang platform: ang Community Edition, isang open-source na bersyon na maaari mong i-install nang libre sa sarili mong server, at ang Enterprise Edition na may bayad na mga feature. Sa gitlab.com, tinatawag na Free, Premium, at Ultimate ang mga plano.

Mahalagang huwag pagsamahin ang mga konseptong ito. Ang Git ay sistema ng version control, isang programang nasa iyong computer. Ang GitLab ay serbisyo na nag-iimbak ng remote na kopya ng repository at nagdaragdag ng interface at mga kasangkapan para sa team. Hindi ka makakapagtrabaho sa GitLab nang walang Git, pero mabubuhay ang Git nang maayos nang walang GitLab.

Git at GitLab: ano ang pagkakaiba

Madalas itanong ang «git at gitlab ano ang pagkakaiba» kapag nakikita ng isang tao ang dalawang salita sa job posting o sa unang araw sa trabaho. Ang pagkakaiba ay katulad ng sa pagitan ng dokumento at cloud storage: sinusubaybayan ng Git ang mga pagbabago sa file, iniimbak ang kasaysayan ng commit at mga branch sa iyong computer. Tinatanggap ng GitLab ang kasaysayang iyon sa pamamagitan ng network at ipinapakita ito sa browser.

Ginagawa mo pa rin sa Git ang lahat ng aksyon sa code — commit, branch, merge. Tinatanggap lamang ng GitLab ang resulta sa pamamagitan ng git push at hinahayaan kang talakayin ito sa mga kasamahan.

GitLab at GitHub: ano ang pagkakaiba

Parehong nag-iimbak ng Git repository at sumusuporta sa code review ang dalawang serbisyo, kaya direktang nagagamit sa isa ang pangunahing kasanayan sa isa pa. Nasa diin at sa paraan ng deployment ang pagkakaiba.

Sa praktika, madalas ginagamit ng developer ang pareho: mga personal na proyekto at portfolio sa GitHub, at ang code ng trabaho sa corporate GitLab. Pareho ang mga command ng Git; ang nagbabago lamang ay ang address ng remote repository.

gitlab.com o sariling server (self-hosted)

Angkop ang cloud na gitlab.com para sa mga personal na proyekto at maliliit na team: magparehistro ka at gumawa agad ng mga repository. Ang mga update, backup, at availability ay responsibilidad ng GitLab. Nagbabago paminsan-minsan ang mga limitasyon ng libreng plano (bilang ng miyembro, minuto ng CI, laki ng storage), kaya tingnan ang kasalukuyang kondisyon sa pahina ng mga plano.

Ang self-hosted na GitLab ay ini-install ng kumpanya sa sarili nitong server — mula sa Linux package, sa Docker, o sa Kubernetes. Hindi lumalabas sa internal network ang code, maaaring ikonekta ang corporate login sa pamamagitan ng LDAP, at maaaring mag-setup ng sariling runner para sa build. Kapalit nito, ang mga administrator ang responsable sa mga update at backup. Para sa developer, halos hindi nararamdaman ang pagkakaiba: ang address ay hindi magiging gitlab.com, kundi halimbawa gitlab.company.com.

Pag-setup ng Git para sa GitLab

Bago ang unang commit, ilagay ang pangalan at e-mail — mapupunta ang mga ito sa kasaysayan, at iuugnay ng GitLab ang mga commit sa iyong profile batay sa e-mail:

git config --global user.name "Ivan Petrov"
git config --global user.email "ivan@example.com"

Sa Windows, maginhawang magtrabaho sa Git Bash: kasama itong naka-install sa Git for Windows at may dalang ssh-keygen, kaya gumagana rito ang lahat ng command sa artikulong ito nang walang pagbabago. Pagkatapos, piliin ang paraan ng pag-sign in — HTTPS na may token o SSH key.

Pag-sign in sa HTTPS: personal access token

Hindi dapat gamitin ang password ng account para sa mga operasyon ng Git sa HTTPS, at kapag naka-on ang two-factor authentication, hindi rin ito gagana. Sa halip, gumawa ng personal access token sa mga setting ng profile ng GitLab (seksyong Access tokens). Para sa trabaho sa code, sapat na ang permiso na read_repository at write_repository; magtakda ng expiration at agad i-save ang token — hindi na ito ipapakitang muli.

Sa unang push o clone, magtatanong ang Git ng username at password: ilagay ang iyong username sa GitLab, at sa halip na password, ang token. Aalalahanin ito ng credential manager (kasama sa Git for Windows), kaya hindi mo na kailangang ilagay ulit.

Pag-sign in gamit ang SSH key

Mas maginhawa ang SSH para sa araw-araw na trabaho: isang beses mong idagdag ang key, at wala nang ita-type pa.

ssh-keygen -t ed25519 -C "ivan@example.com"
cat ~/.ssh/id_ed25519.pub

I-paste ang nilalaman ng file na .pub (ang public key) sa mga setting ng profile ng GitLab, sa seksyong SSH Keys. Pagsubok ng koneksyon:

ssh -T git@gitlab.com
Welcome to GitLab, @ivan.petrov!

Git clone GitLab: paano mag-clone ng repository

Sa pahina ng proyekto, may button na Code na may dalawang address — para sa SSH at para sa HTTPS. Kopyahin ang gusto mo at patakbuhin ang git clone:

# sa HTTPS
git clone https://gitlab.com/my-group/my-project.git

# sa SSH
git clone git@gitlab.com:my-group/my-project.git

Sa GitLab, maaaring may kasamang subgroup ang path ng proyekto, halimbawa gitlab.com/company/backend/api.git — normal iyon, kopyahin ang buong address.

Git clone GitLab gamit ang token

Sa mga script at server na walang taong makapag-type ng password, inilalagay ang token mismo sa address. Maaaring username mo o ang serbisyong oauth2 ang gamitin bilang login:

git clone https://oauth2:TOKEN_MO@gitlab.com/my-group/my-project.git

Tandaan: maiimbak ang ganitong address sa .git/config at maaaring mapunta sa kasaysayan ng command ng shell. Para sa automation, mas mainam ang deploy token o project access token na may kaunting permiso at maikling expiration, at sa CI, ang built-in na variable na CI_JOB_TOKEN.

Git push papuntang GitLab: pagpapadala ng code

Kung nasa lokal na ang proyekto, gumawa ng walang lamang proyekto sa GitLab (walang README, para walang dagdag na commit) at ikonekta ang remote:

git remote add origin git@gitlab.com:my-group/my-project.git
git branch -M main
git push -u origin main

Ikinakabit ng flag na -u ang lokal na branch sa remote na branch, at pagkatapos nito sapat na ang git push at git pull. Hindi nagbabago ang karaniwang ikot ng trabaho sa alinmang serbisyo:

git switch -c feature/login
git add .
git commit -m "Idagdag ang login form"
git push -u origin feature/login
git pull

Hiwalay na ipinapadala ang mga tag: git push origin v1.2.0, o lahat nang sabay sa git push --tags. Makikita ang mga tag sa seksyong Tags ng GitLab, at kadalasang sila ang nagsisimula ng release pipeline.

Mga karaniwang error sa git push sa GitLab

• HTTP Basic: Access denied — mali ang username o password ang nailagay sa halip na token. Gumawa ng token na may permiso sa write_repository at burahin ang lumang entry sa credential manager.
• Permission denied (publickey) — hindi nakilala ng GitLab ang iyong SSH key. Suriin na nakadagdag ang public key sa profile, at patakbuhin ang ssh -T git@gitlab.com.
• You are not allowed to push code to protected branches — protektado ang branch (karaniwang main). Ipadala ang mga pagbabago sa sarili mong branch at magbukas ng merge request.
• rejected ... (fetch first) — may mga commit sa server na wala sa iyo. Patakbuhin ang git pull --rebase at ulitin ang push.
• remote: Project not found — mali ang address o wala kang access sa proyekto; itanong sa may-ari ang iyong role.

Merge request sa GitLab

Ang merge request ay katumbas ng pull request sa GitHub: kahilingang isama ang iyong branch sa pangunahing branch. Sa loob ng MR, nag-iiwan ng komento ang mga kasamahan sa mga linya ng code, tumatakbo ang mga check ng CI, at dito pinagpapasyahan kung ima-merge ito. Pagkatapos ng push ng bagong branch, naglalabas ang GitLab ng link sa terminal para gumawa ng MR, at sa web interface ay lumalabas ang mungkahing gumawa nito.

Maaari ring gumawa ng MR direkta mula sa command line gamit ang push options:

git push -o merge_request.create -o merge_request.target=main origin feature/login

Karaniwang proseso: branch para sa gawain → commit → push → MR → review at berdeng pipeline → merge. Sa pag-merge, maaaring pagsamahin ng GitLab ang mga commit sa isa (squash) at burahin ang source branch. Kung may conflict ang MR, pinakamadaling i-update ang branch sa lokal — git pull --rebase origin main o git merge main — lutasin ang mga conflict, at i-push ulit.

Lagyan ng marka ng Draft ang trabahong hindi pa tapos: hindi aksidenteng ma-merge ang ganoong MR, pero nakikita na ng mga kasamahan ang mga pagbabago at maaari nilang talakayin ang mga ito.

CI/CD sa GitLab: .gitlab-ci.yml

Ang pangunahing katangian ng GitLab ay ang built-in na CI/CD. Maglagay lamang ng file na .gitlab-ci.yml sa root ng repository, at sa bawat push ay magsisimula ang GitLab ng pipeline na binubuo ng mga stage at job. Pinapatakbo ng mga runner ang mga job: sa gitlab.com may mga shared runner, at sa sarili mong server, hiwalay itong ini-install.

stages:
  - test
  - deploy

test:
  stage: test
  image: python:3.12
  script:
    - pip install -r requirements.txt
    - pytest

deploy:
  stage: deploy
  script:
    - ./deploy.sh
  rules:
    - if: $CI_COMMIT_TAG

Dito, tumatakbo ang mga test sa bawat push, at ang job na deploy ay tumatakbo lamang kapag may naipadalang tag: git tag v1.0.0 at git push origin v1.0.0. Lalabas ang mga resulta ng pipeline mismo sa merge request, at maaari mong pigilan ang merge hangga't hindi pumapasa ang mga check.

Paano burahin ang repository sa GitLab

Hindi kayang burahin ng mga command ng Git ang proyekto sa server — binabago lamang ng git push ang mga branch at tag. Binubura ang proyekto sa web interface: mga setting ng proyekto, seksyong General, bloke ng Advanced, at ang button na pagbura na may kumpirmasyon sa pangalan. Kailangan ang role na Owner. Nananatili ang lokal na kopya sa iyong computer — folder lang ito na may .git.

Kung gusto mong idiskonekta ang lokal na repository sa GitLab nang hindi binubura ang anuman sa server, sapat na ang git remote remove origin.

Kailan pipiliin ang GitLab

• Hindi maaaring ilabas ang code sa panlabas na cloud — kailangan ang sarili mong server.
• Kailangan ang CI/CD na handa na nang hindi gumagamit ng third-party na serbisyo.
• Malaking organisasyon na may maraming team sa iba't ibang antas — makakatulong ang mga nested group at flexible na role.
• Papasok ka sa kumpanyang gumagamit na ng GitLab: wala nang pagpipilian doon, pero ganap namang maililipat ang iyong kasanayan sa Git.

Para sa portfolio at open source, kadalasang pinipili ang GitHub: mas malaki ang komunidad doon at mas nakikita ang mga proyekto. Walang pumipigil na ilagay ang proyekto sa parehong serbisyo — maaaring may ilang remote ang isang repository.

Buod

Ang GitLab ay platform para sa mga Git repository na may review sa pamamagitan ng merge request, mga gawain, at built-in na CI/CD, na available sa cloud at sa sarili mong server. Ang pagtatrabaho dito ay nauuwi sa pamilyar na mga command: i-setup ang pag-sign in gamit ang token o SSH key, pagkatapos ay clone, commit, push, at merge request. Ang mga remote repository at ang team workflow ay detalyadong tinalakay nang praktikal sa kurso sa Git.