Pull Request: шта је, процес креирања и код ревија

Шта је Pull Request?

Pull Request (PR) — је формални захтјев за укључивање измена из једне гране у другу у оквиру дистрибуираног система за контролу верзија. PR је централни елемент заједничког развоја на платформама GitHub, GitLab и Bitbucket, обједињујући дискусију о коду, аутоматско тестирање и процес одобравања измена.

Назив „Pull Request“ одражава суштину операције: програмер тражи (request) од власника репозиторијума да „преузме“ (pull) његове измене. Термин је увео знајка 2008. године од стране GitHub-а — пре тога сличан механизам је постојао у облику патчева и merge request (термин GitLab). Данас је PR де факто стандард за тимски рад са Git-ом.

Према GitHub Octoverse, 2025, 89% отворених пројеката захтева креирање PR за уношење измена. У корпоративном развоју овај показатељ достиже 95%. PR је постао не само технички алат, већ и део културе развоја: кроз PR се одвија пренос знања, откривање грешака и усаглашавање архитектурних одлука.

Компоненте Pull Request-а

Типичан PR се састоји од наслова, описа, листе измењених датотека (diff), коментара рецензената и статуса CI провера. Сваки PR је везан за одређену изворну и циљну грану, а након спајања може бити аутоматски обрисан.

Како направити Pull Request

Креирање PR почиње објављивањем feature гране у удаљеном репозиторијуму. Након push-а, програмер отвара PR путем интерфејса платформе или CLI (гх, глаб). Размотрићемо процес на примеру GitHub-а.

Push гране и отварање PR

Први корак — потиснити feature грану у удаљени репозиторијум и креирати Pull Request путем веб интерфејса или командне линије.

# Креирајте и потисните feature грану
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# Креирајте PR путем GitHub CLI
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

Након креирања PR-а, GitHub аутоматски покреће CI пајплајнове (GitHub Actions), проверава постојање конфликата са циљном граном и позива рецензенте. Шаблон описа PR може бити подешен путем .github/PULL_REQUEST_TEMPLATE.md тако да сви PR-ови садрже обавезне секције: циљ, измене, тестирање, повезани задаци.

Опис и означавање

Квалитетан опис PR-а укључује: линк ка задатку (issue/ticket), кратак опис измена, упутство за тестирање и листу повезаних измена. Ознаке (bug, feature, refactoring) помажу да се PR-ови категоришу, а assignees и reviewers се додељују аутоматски путем CODEOWNERS-а.

# Поставите рецензенте путем CODEOWNERS (датотека у корену репозиторијума)
# Примјер .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Креирајте PR са постављањем рецензената путем gh cli
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS — стандардни механизам GitHub/GitLab за аутоматско додељивање рецензената у зависности од измењених датотека. На примјер, свака измена у директоријуму src/auth/ аутоматски додељује team-auth и senior-dev као рецензенте. Ово убрзава процес и гарантује да ће праве особе видети PR.

Ажурирање PR након ревије

Након пријема коментара рецензента, програмер уноси исправке у истој feature грани и потискује нове комите — PR се ажурира аутоматски. Важно је не преписивати историју (rebase) у објављеној feature грани ако је PR већ отворен, јер то ломи линкове ка одређене комите у коментарима.

# Унесите измене према коментарима рецензента
git checkout feature/biometric-auth
# поправите код
git commit -m "fix: handle biometric timeout per review"
git push

# PR ће се ажурирати аутоматски
# Након одобрења — спојите PR путем GitHub интерфејса

Процес код ревије

Код ревија — централни елемент Pull Request-а. Рецензент проверава измене због исправности, стила кода, безбедности и архитектурне усклађености. Квалитетна ревија не само спречава грешке, већ и шири знање о бази кода унутар тима.

Google Engineering Practices (2025) препоручује сљедеће принципе код ревије: рецензент треба да разуме контекст измена, даје конкретне препоруке уместо општих примедби, одваја техничке од стилских коментара. Време ревије не треба да прелази 24 сата од тренутка креирања PR.

За развој мобилних апликација, код ревија укључује специфичне провере: компатибилност са targetSdk, исправност обраде lifecycle (Android) / view lifecycle (iOS), одсуство цурења меморије (LeakCanary, Instruments), подршка тамне теме и локализације. Ове провере се могу аутоматизовати путем линтера и Detekt/ktlint.

Врсте коментара

Платформе PR подржавају три врсте коментара: опште (на цео PR), у реду (на одређену линију кода) и предлозе (suggestions са кодом за замену). Предлози омогућавају примену измене једним кликом, што убрзава процес и смањује број итерација.

Након што су сви коментари решени и CI провере прођу, рецензент шаље одобрење (Approved). PR може бити спојен. GitHub и GitLab подржавају правила заштите грана (branch protection rules): обавезан број одобрења, обавезне CI провере, забрана push-а на main без PR. За мобилне пројекте, branch protection такође укључује проверу build-а: PR не може бити спојен ако се апликација не изграђи (gradle build failed / xcodebuild failed).

Решавање конфликата у PR-у

Конфликти merge-а у Pull Request-у су нормална ситуација при активном тимском раду. Платформе нуде решавање конфликата путем веб интерфејса (за једноставне конфликте) или препоручују локално решавање. GitHub Actions аутоматски проверава могућност спајања при сваком push-у у feature грану и означава PR као conflict ако спајање није могуће.

Најбоље праксе Pull Request

Ефикасни Pull Request-ови убрзавају код ревију и смањују број грешака. Истраживање SmartBear (2025) је показало да PR-ови величине до 200 линија кода добијају 2 пута више садржајних коментара него PR-ови са више од 1000 линија, а време ревије се скраћује 3 пута.

• Мали PR-ови — оптимална величина 100-300 линија. Велике PR-ове подијелите на логичке целине: сваки PR решава један задатак. Ово поједностављује ревију и смањује вероватноћу конфликата
• Јасан опис — наслов према Conventional Commits (feat:, fix:, refactor:), садржај PR-а укључује „шта и зашто“, не „како“ (код говори сам за себе). Шаблон: циљ → измене → тестирање → повезани проблеми
• Брза повратна информација — ревија у року 24 сата. Ако PR чека дуже од једног дана — тим губи контекст, расте број конфликата при merge-у
• Аутоматизација — линтери, форматери и тестови треба аутоматски да се покрећу при креирању PR. Не дозвољавајте спајање PR-а са црвеним CI проверама
• Draft PR — користите за рану дискусију о архитектури. Draft PR не захтева ревију и не може бити спојен, али омогућава приказивање кода колегама у раној фази

Додатне праксе: не креирајте PR петком увече (нико неће ревидирати до понедељка), тражите ревију од 1-2 особе (више успоравава процес без побољшања квалитета), користите squash merge за компресију историје пре спајања. За мобилне пројекте такође се препоручује додавање у опис PR линка ка тестном build-у (Firebase App Distribution / TestFlight) да би рецензент могао проверити измене у радној апликацији.

Pull Request на различитим платформама

Главне платформе за рад са Pull Request-ом су GitHub, GitLab и Bitbucket. Упркос заједничком концепту, свака има карактеристике које треба узети у обзир при одабиру алата за тим.

GitHub — најпопуларнија платформа са највећом заједницом, Actions за CI/CD и обимним екосистемом апликација (GitHub Marketplace). GitLab се истиче по уграђеном CI/CD-у и могућношћу потпуног self-hosted постављања. Bitbucket је чврсто интегрисан са Jira-ом и Atlassian екосистемом, популаран у корпоративном окружењу.

За развој мобилних апликација, избор платформе често зависи од CI/CD могућности: GitHub Actions подржава macOS runners за изградњу iOS, GitLab има уграђене runners за iOS/Android, Bitbucket се добро интегрише са Firebase Test Lab. Без обзира на платформу, PR процес остаје исти: грана → review → CI → merge.