வழிகாட்டி

Git-இல் pull request: அது என்ன, GitHub-இல் PR எப்படி உருவாக்குவது

புதுப்பிக்கப்பட்டது: · Skillaria.Top

Pull request (PR) என்பது உங்கள் கிளையை GitHub களஞ்சியத்தின் முதன்மைக் கிளையுடன் இணைக்கக் கோரும் கோரிக்கை: மாற்றங்களைக் காட்டுகிறீர்கள், குழுவினர் அவற்றை விவாதித்து மதிப்பாய்வு செய்கின்றனர், ஒப்புதலுக்குப் பின் கிளை இணைக்கப்படுகிறது. GitLab-இல் இதே விஷயம் merge request (MR) எனப்படுகிறது. இது Git கட்டளை அல்ல, தளத்தின் அம்சம்; git pull கட்டளையுடன் இதற்குத் தொடர்பில்லை.

Pull request (PR) என்பது GitHub போன்ற தளத்தில் எழுதப்படும், ஒரு கிளையின் மாற்றங்களை மற்றொரு கிளையில் இணைக்கும் முன்மொழிவு. நீங்கள் கிளையை சேவையகத்துக்கு அனுப்பி PR திறக்கிறீர்கள்; குழு diff-ஐப் பார்த்து வரிகளில் கருத்து தெரிவித்து, தானியங்கி சோதனைகளை இயக்கி, அதன் பின்னரே இணைப்பு பொத்தானை அழுத்துகிறது. GitLab-இல் இதே பொறிமுறை merge request (MR) என அழைக்கப்படுகிறது. «git pull request என்றால் என்ன» என்ற கேள்விக்குச் சுருக்கமான பதில்: «நான் குறியீடு எழுதினேன்» என்பதற்கும் «குறியீடு main-இல் சேர்ந்தது» என்பதற்கும் இடையிலான கட்டுப்பாட்டுப் புள்ளி இது.

Git pull request என்றால் என்ன, பெயர் எங்கிருந்து வந்தது

இந்தப் பெயர் வரலாற்று ரீதியாக வந்தது. மாற்றங்களை எழுதியவர், தன்னுடைய கிளையைத் தம் களஞ்சியத்துக்குள் «இழுத்துக்கொள்ளும்படி» (pull) களஞ்சிய உரிமையாளரிடம் கேட்கிறார்; அதிலிருந்துதான் pull request. GitLab அதை அதன் விளைவின் பெயரால் அழைத்தது: merge request, அதாவது இணைப்புக் கோரிக்கை. Bitbucket மற்றும் Azure DevOps «pull request» என்றே சொல்கின்றன. பொருள் ஒன்றுதான்: மூல கிளை, இலக்கு கிளை, விளக்கம், விவாதம், சோதனைகள், இணைப்பு பொத்தான்.

Pull request Git-இன் பகுதி அல்ல என்பதை புரிந்துகொள்வது முக்கியம். Git-இல் «PR» என்ற பொருள் இல்லை; அதை commit மூலம் உருவாக்கவோ .git கோப்புறையில் கண்டறியவோ முடியாது. அது தளத்தின் ஒரு கூறு: GitHub விளக்கத்தையும் கருத்துகளையும் சோதனை நிலைகளையும் தன்னிடம் வைத்திருக்கிறது; Git கிளைகளுக்கும் PR-இல் உள்ள commit-களுக்கும் மட்டுமே பொறுப்பு.

உரையாடலில் PR என்றால் கிட்டத்தட்ட எப்போதும் pull request என்றே பொருள்: «ஒரு PR அனுப்பு», «PR மதிப்பாய்வுக்கு», «PR-ஐ இணைத்துவிட்டேன்». GitLab-இல் MR என்கிறார்கள்.

Pull request மற்றும் git pull: வேறுபாடு

ஒத்த சொற்களால் இவை அடிக்கடி குழப்பப்படுகின்றன. git pull கட்டளை தொலைதூர களஞ்சியத்திலிருந்து புதிய commit-களைப் பதிவிறக்கி உங்கள் தற்போதைய கிளையில் உடனே இணைக்கிறது; அது முனையத்தில் நடக்கும் உள்ளூர் செயல். Pull request என்பது GitHub, GitLab அல்லது Bitbucket-இல் ஒரு கிளையை மற்றொன்றில் இணைக்கும் முன்மொழிவைக் காட்டும் இணையப் பக்கம்.

git pullPull request
எங்கே இயங்கும்முனையத்தில் Git கட்டளைGitHub, GitLab, Bitbucket-இல் ஒரு பக்கம்
என்ன செய்கிறதுசேவையகத்திலிருந்து மாற்றங்களை உங்களிடம் கொண்டுவருகிறதுஉங்கள் கிளையை வேறொருவரின் அல்லது பகிரப்பட்ட கிளையில் இணைக்க முன்மொழிகிறது
யார் பங்கேற்கின்றனர்நீங்கள் மட்டும்எழுதுபவர், மதிப்பாய்வாளர்கள், CI
தளம் தேவையாஇல்லை, remote மட்டும் போதும்ஆம்

Git-இல் «git pull request» என்ற தனிக் கட்டளை இல்லை. git request-pull என்ற பழைய கருவி உள்ளது, ஆனால் அது மாற்றங்களின் சுருக்கத்தை அஞ்சலுக்கான உரையாக உருவாக்கும்; GitHub-இல் உள்ள PR-உடன் அதற்குத் தொடர்பில்லை.

Pull request ஏன் தேவை

திட்டத்தில் ஒருவர் மட்டும் வேலை செய்யும்போது, மாற்றங்களை நேரடியாக main-இல் commit செய்யலாம். ஆனால் களஞ்சியத்தில் இருவர் அல்லது அதற்கு மேல் இருந்தால், முதன்மைக் கிளைக்கு நேரடி push என்பது உடைந்த கட்டமைப்புகளுக்கும் இழந்த வேலைக்கும் காரணமாகிவிடும். Pull request பல பிரச்சினைகளை ஒரே நேரத்தில் தீர்க்கிறது:

  • குறியீட்டு மதிப்பாய்வு — மாற்றங்கள் main-ஐ அடைவதற்கு முன் இரண்டாவது நபர் அவற்றைப் பார்க்கிறார், எழுதியவர் தவறவிட்ட பிழைகளைப் பிடிக்கிறார்;
  • தானியங்கி சோதனைகள் — GitHub Actions அல்லது வேறு CI ஒவ்வொரு PR-க்கும் சோதனைகளையும் lint கருவிகளையும் இயக்குகிறது; சிவப்பு நிலை உடைந்த குறியீட்டை இணைக்க விடாது;
  • முடிவுகளின் வரலாறு — ஓராண்டுக்குப் பிறகும் PR மூலம் என்ன மாறியது மட்டுமல்ல, ஏன் மாறியது என்பதையும், அதைப்பற்றிய விவாதத்துடன் புரிந்துகொள்ளலாம்;
  • வேறு திட்டங்களுக்கு பங்களிப்பு — திறந்த மூல திட்டங்களில் உங்களுக்கு எழுதும் உரிமை இருக்காது; திருத்தத்தை முன்மொழிய fork-இலிருந்து வரும் PR மட்டுமே வழி;
  • கிளைப் பாதுகாப்பு — GitHub-இல் கிளை பாதுகாப்பு விதிகள் main-இல் நேரடி push-ஐத் தடுத்து, ஒப்புக்கொள்ளப்பட்ட PR-ஐக் கட்டாயமாக்கலாம்.

GitHub-இல் கிளையிலிருந்து pull request உருவாக்குவது எப்படி

அனைத்து உறுப்பினர்களுக்கும் களஞ்சியத்தில் எழுதும் உரிமை உள்ள குழுவுக்கான முதன்மை வழி இது. வேலை feature கிளையில் நடக்கிறது; main-இல் மாற்றங்கள் PR வழியாக மட்டுமே வருகின்றன.

படி 1. புதிய main-இலிருந்து கிளை உருவாக்குங்கள்

git switch main
git pull
git switch -c feature/login-form

கிளையின் பெயர் உள்ளடக்கத்தைக் காட்டும்படி வையுங்கள்: feature/…, fix/…, அல்லது பணி எண். மதிப்பாய்வாளருக்கு உடனே என்ன விஷயம் என்று தெரியும்.

படி 2. commit-களைச் செய்யுங்கள்

git add src/login.js
git commit -m "உள்நுழைவு படிவத்தைச் சேர்"

ஒரு PR என்பது ஒரு பணி. 100–300 வரிகள் கொண்ட சிறிய PR விரைவாகவும் கவனமாகவும் மதிப்பாய்வு செய்யப்படும்; 3000 வரிகள் கொண்ட PR-ஐ மதிப்பாய்வாளர் பார்க்காமலேயே ஒப்புதல் அளித்துவிடுவார்.

படி 3. கிளையை சேவையகத்துக்கு அனுப்புங்கள் (pull request-க்காக git push)

git push -u origin feature/login-form

-u குறி உள்ளூர் கிளையை தொலைதூரக் கிளையுடன் இணைக்கிறது; அதன் பின் சாதாரண git push போதும். GitHub பதிலில் PR உருவாக்குவதற்கான இணைப்பைத் தானே காட்டும்:

remote: Create a pull request for 'feature/login-form' on GitHub by visiting:
remote:      https://github.com/team/app/pull/new/feature/login-form

படி 4. இணைய இடைமுகத்தில் PR-ஐ திறவுங்கள்

முனையத்தில் உள்ள இணைப்பைப் பின்தொடருங்கள், அல்லது GitHub-இல் களஞ்சியத்தைத் திறவுங்கள்: புதிய push-க்குப் பிறகு «Compare & pull request» பொத்தான் தோன்றும். இன்னொரு வழி «Pull requests» தாவல் மற்றும் «New pull request» பொத்தான்.

  1. கிளை ஜோடியைச் சரிபாருங்கள்: base — எங்கே இணைக்கிறீர்கள் (வழக்கமாக main), compare — உங்கள் கிளை.
  2. தலைப்பை எழுதுங்கள்: என்ன செய்யப்பட்டது என்பதை கட்டளை வடிவிலோ சுருக்கமான விளக்கமாகவோ.
  3. விளக்கத்தில் ஏன், எப்படி சோதிப்பது, எது வரம்புக்கு வெளியே விடப்பட்டது என்பதை எழுதுங்கள். களஞ்சியத்தில் PR வார்ப்புரு இருந்தால், புலங்கள் தானாக நிரப்பப்படும்.
  4. வலப்பக்கம் மதிப்பாய்வாளர்கள் (Reviewers), பொறுப்பாளர் மற்றும் குழு பயன்படுத்தினால் லேபிள்களைக் குறியுங்கள்.
  5. «Create pull request» பொத்தானை அழுத்துங்கள், அல்லது வரைவு (draft) தேர்ந்தெடுங்கள் (கீழே காண்க).

முனையத்திலிருந்து PR உருவாக்குதல்: GitHub CLI

உலாவிக்குச் செல்ல விரும்பவில்லை என்றால், அதிகாரப்பூர்வ கருவி gh உள்ளது. இது Git கட்டளை அல்ல, GitHub-இன் தனி நிரல்; ஆனால் PR-க்கு மிகவும் பயனுள்ளது:

gh pr create --base main --title "உள்நுழைவு படிவத்தைச் சேர்" --body "Closes #42"
gh pr list
gh pr checkout 57
gh pr merge 57 --squash

«git pull request கட்டளைகள்» பற்றிய நேர்மையான பதில் இது: Git கிளைகள், commit-கள் மற்றும் push-ஐ அறியும்; PR தளத்தில் உருவாகிறது — உலாவியில், gh மூலம் அல்லது API மூலம்.

பிற களஞ்சியத்துக்கு fork வழியாக pull request அனுப்புவது

திறந்த திட்டங்களில் உங்களுக்கு எழுதும் உரிமை இருக்காது. எனவே முதலில் fork செய்யுங்கள் — அதாவது GitHub-இல் களஞ்சியத்தின் உங்கள் சொந்த நகல்; அதில் வேலை செய்து, அசல் களஞ்சியத்துக்கு மாற்றங்களை முன்மொழியுங்கள்.

  1. திட்டப் பக்கத்தில் «Fork» அழுத்துங்கள்; github.com/you/project உங்களுக்குக் கிடைக்கும்.
  2. உங்கள் fork-ஐ clone செய்து, அசல் களஞ்சியத்தை இரண்டாவது remote ஆகச் சேர்க்கவும்; அதற்கு வழக்கமாக upstream என்று பெயர்.
  3. கிளையை உருவாக்கி, commit-களைச் செய்து, உங்கள் fork-க்கு அனுப்புங்கள்.
  4. GitHub-இல் PR-ஐ திறவுங்கள்: base repository என்பது அசல் திட்டம், head repository என்பது உங்கள் fork மற்றும் கிளை.
git clone git@github.com:you/project.git
cd project
git remote add upstream https://github.com/owner/project.git
git switch -c fix/typo-readme
git commit -am "README-இல் எழுத்துப் பிழையைத் திருத்து"
git push -u origin fix/typo-readme

தொடங்குவதற்கு முன் CONTRIBUTING.md கோப்பைப் பாருங்கள்: அதில் பொதுவாக commit எழுதும் விதிகள், சோதனைகள், முதலில் issue உருவாக்க வேண்டுமா என்பதெல்லாம் விவரிக்கப்பட்டிருக்கும். உங்கள் fork-ஐப் புதுப்பித்து வையுங்கள்: git fetch upstream மற்றும் உங்கள் கிளையில் git rebase upstream/main, அதனால் PR அசல் திட்டத்துக்குப் பின்தங்காது.

GitLab-இல் merge request: அது என்ன, எப்படி உருவாக்குவது

GitLab-இன் merge request, GitHub-இன் pull request-க்கு முழுமையான இணை. பெயர்களும் இடைமுக விவரங்களும் வேறுபடுகின்றன, ஆனால் செயல்முறை ஒன்றே: கிளை, push, இணைப்புக் கோரிக்கை, மதிப்பாய்வு, இணைப்பு.

MR உருவாக்க பல வழிகள் உள்ளன:

  • புதிய கிளையை git push செய்த பின் GitLab முனையத்தில் அச்சிடும் இணைப்பின் மூலம்;
  • திட்டத்தின் Merge requests பிரிவில் «New merge request» பொத்தான் மூலம், மூல மற்றும் இலக்கு கிளைகளைத் தேர்ந்து;
  • push செய்யும்போதே GitLab push options மூலம் — உலாவியைத் திறக்காமல்.
git push -o merge_request.create -o merge_request.target=main origin feature/login-form

GitLab-இன் சொற்கள் சற்று வேறுபடுகின்றன: ஒப்புதல் approve எனப்படுகிறது, இணைப்புக்குப் பொறுப்பானவர் assignee, GitHub Actions-க்குப் பதிலாக .gitlab-ci.yml கோப்புடன் GitLab CI/CD இயங்குகிறது. GitLab-இல் வரைவுகளும் உண்டு; அவை Draft எனப்படுகின்றன.

Pull request மதிப்பாய்வு

மதிப்பாய்வாளர் «Files changed» தாவலைத் திறந்து diff-ஐப் பார்க்கிறார். எந்த வரியிலும் கருத்து தெரிவிக்கலாம், அல்லது தயாரான திருத்தத்தை (suggestion) பரிந்துரைக்கலாம்; எழுதியவர் அதை ஒரே பொத்தானில் ஏற்கலாம். கருத்துகள் ஒரு மதிப்பாய்வாகத் தொகுக்கப்பட்டு, பின்வரும் முடிவுகளில் ஒன்றுடன் அனுப்பப்படும்:

  • Comment — முடிவு இல்லாத குறிப்புகள் மட்டும்;
  • Approve — மாற்றங்கள் ஒப்புக்கொள்ளப்பட்டன;
  • Request changes — இன்னும் வேலை தேவை, இணைப்பது விரும்பத்தக்கதல்ல.

நல்ல மதிப்பாய்வு தர்க்கம், வாசிப்புத் திறன், சோதனைகள், எல்லை நிலைகள் ஆகியவற்றைப் பார்க்கும்; ரசனை பற்றி வாதிடாது — வடிவமைப்பை CI-இல் உள்ள lint கருவிக்கு விட்டுவிடுவது நல்லது. எழுதியவர் ஒவ்வொரு கருத்துக்கும் பதில் அளிக்க வேண்டும்: சரிசெய்தேன், விவாதித்தோம், அல்லது விளக்கத்துடன் அப்படியே விட்டுவிட்டோம்.

மற்றவரின் PR-ஐ உள்ளூரில் சரிபார்ப்பது எப்படி (git checkout pull request)

சில நேரங்களில் குறியீட்டை உங்கள் கணினியில் இயக்க வேண்டியிருக்கும். கிளை அதே களஞ்சியத்தில் இருந்தால் git fetch மற்றும் git switch போதும். Fork-இலிருந்து வரும் PR-க்கு GitHub சிறப்பு இணைப்புகளை வழங்குகிறது: pull/<எண்>/head:

git fetch origin pull/57/head:pr-57
git switch pr-57

GitLab-இல் ஒத்த இணைப்புகள் merge-requests/<எண்>/head என அழைக்கப்படுகின்றன. அல்லது GitHub CLI நிறுவியிருந்தால் gh pr checkout 57.

மதிப்பாய்வுக் கருத்துகளுக்குப் பின் pull request-ஐ புதுப்பிப்பது

PR கிளையுடன் இணைக்கப்பட்டுள்ளது, குறிப்பிட்ட commit-களுடன் அல்ல. அதே கிளையில் புதிய commit-களைச் செய்து அனுப்பினால் போதும் — PR தானாகப் புதுப்பிக்கப்படும்; புதிய கோரிக்கை உருவாக்க வேண்டியதில்லை.

git commit -am "மதிப்பாய்வுக் கருத்துகளின்படி திருத்து"
git push

Git rebase pull request: புதிய main-ஐ இணைத்தல்

PR மதிப்பாய்வில் இருக்கும்போது main முன்னேறிக்கொண்டே இருக்கும். GitHub கிளை பழையது அல்லது மோதல்கள் உள்ளன என்று எழுதினால், அதைப் புதுப்பியுங்கள். Rebase முறை நேர்கோட்டு வரலாற்றைத் தரும்:

git fetch origin
git rebase origin/main
# மோதல்களைத் தீர்க்கவும், git add, git rebase --continue
git push --force-with-lease

Rebase-க்குப் பிறகு commit-களின் ஹாஷ்கள் மாறும்; அதனால் சாதாரண push நிராகரிக்கப்படும், கட்டாய push தேவைப்படும். --force-with-lease பயன்படுத்துங்கள்: கிளையில் வேறு யாருடைய commit-களாவது வந்திருந்தால் அது மேலெழுத மறுக்கும். கிளையில் உங்களைத் தவிர பலரும் வேலை செய்தால், வரலாற்றை மீண்டும் எழுதாமல் git merge origin/main மூலம் main-ஐ இணைப்பது பாதுகாப்பானது.

Pull request-ஐ இணைப்பது எப்படி: merge, squash, rebase

மதிப்பாய்வு ஒப்புக்கொள்ளப்பட்டு சோதனைகள் பச்சையாக இருந்தால், PR-ஐ இணைக்கலாம். GitHub மூன்று வழிகளை வழங்குகிறது; களஞ்சிய நிர்வாகி அவற்றில் சிலவற்றை மட்டும் வைத்திருக்கலாம்.

வழிmain-இல் என்ன சேரும்எப்போது பொருந்தும்
Create a merge commitகிளையின் அனைத்து commit-களும் ஒரு merge commit-உடன்முழு வரலாறு தேவைப்படும்போது, எந்த commit-கள் சேர்ந்து வந்தன என்பது தெரிய வேண்டும்போது
Squash and mergePR-இன் அனைத்து மாற்றங்களையும் கொண்ட ஒரே commitகிளையில் «fix typo» போன்ற பல சிறிய commit-கள் இருக்கும்போது, main-இன் பதிவு சுத்தமாக இருக்க வேண்டுமென்றால்
Rebase and mergeகிளையின் commit-கள் ஒவ்வொன்றாக, merge commit இல்லாமல்commit-கள் நேர்த்தியாக இருந்து ஒவ்வொன்றும் தனியாகவே பொருள் தரும்போது

இடைமுகத்தில் pull request-ஐ இணைப்பது, சாராம்சத்தில் git merge தான்; ஆனால் அது சேவையகத்தில் நடக்கிறது. இணைத்த பின் GitHub கிளையை நீக்கலாமா என்று கேட்கும்; அதை ஏற்கலாம், அது இனி தேவையில்லை. உள்ளூரில் சுத்தம் செய்யுங்கள்:

git switch main
git pull
git branch -d feature/login-form

கைமுறையாக முனையத்திலிருந்தும் PR-ஐ இணைக்கலாம்: கிளையை உள்ளூரில் main-இல் இணைத்து அனுப்புங்கள். கிளையின் commit-கள் இலக்கில் சேர்ந்துவிட்டதை GitHub கண்டறிந்து PR-ஐ தானாக merged எனக் குறிக்கும். ஆனால் இந்த முறையில் சோதனைகளும் கிளைப் பாதுகாப்பு விதிகளும் தவிர்க்கப்படுகின்றன; அதனால் குழுக்களில் பொத்தான் மூலம் இணைப்பதே வழக்கம்.

Auto-merge மற்றும் merge queue

சோதனைகள் நீண்ட நேரம் எடுத்தால், தானியங்கி இணைப்பை இயக்கலாம்: எல்லா நிபந்தனைகளும் நிறைவேறியதும் PR தானாக இணைக்கப்படும். பெரிய களஞ்சியங்களில் merge queue பயன்படுகிறது; அது ஏற்கனவே வரிசையில் உள்ளவற்றின் மேல் PR-ஐ சோதிக்கும், பொருந்தாத மாற்றங்களால் main உடையாமல் இருக்க.

Pull request வரைவுகள் (Draft)

வரைவு என்பது இன்னும் மதிப்பாய்வுக்குத் தயாராகாத PR. அதை இணைக்க முடியாது; மதிப்பாய்வாளர்களுக்கு சரிபார்ப்புக் கோரிக்கை செல்லாது. திசையை முன்கூட்டியே காட்டவும், CI-ஐ இயக்கவும், கட்டமைப்பு பற்றிய கருத்துகளைப் பெறவும் வரைவுகள் பயனுள்ளவை. GitHub-இல் PR உருவாக்கும் பொத்தானின் கீழிறங்கு மெனுவில் வரைவு விருப்பத்தைத் தேர்ந்தெடுங்கள், அல்லது gh pr create --draft இயக்குங்கள். வேலை முடிந்ததும் «Ready for review» அழுத்துங்கள். GitLab-இல் MR தலைப்பின் முன்னால் Draft: என்ற முன்னொட்டுடன் குறிக்கப்படுகிறது.

Pull request-ஐ issues-உடன் இணைப்பது

PR விளக்கத்தில் ஒரு முக்கிய சொல்லையும் பணி எண்ணையும் எழுதினால், இயல்புநிலைக் கிளையில் இணைத்த பின் GitHub அந்த issue-ஐத் தானாக மூடும்:

Closes #42
Fixes #17
Resolves #8

close, fix, resolve ஆகிய சொற்கள் பல வடிவங்களில் வேலை செய்யும் (closes, fixed, resolves). முக்கிய சொல் இல்லாமல் #42 என்று குறிப்பிட்டால் இணைப்பு உருவாகும், ஆனால் பணி மூடப்படாது. GitLab-இலும் Closes #42 போன்ற சொற்றொடர்கள் இதேபோல் வேலை செய்யும்.

Pull request அல்லது merge request-ஐ நீக்க முடியுமா

சாதாரண பங்கேற்பாளரால் GitHub-இல் PR-ஐ நீக்க முடியாது; «Close pull request» பொத்தானால் மூட மட்டுமே முடியும். மூடப்பட்ட PR வரலாற்றில் இருக்கும், மீண்டும் திறக்கலாம். மூடிய பின் கிளையை தனியாக நீக்குங்கள். PR-ஐ முழுமையாக நீக்குவது GitHub ஆதரவு மூலம் மட்டுமே சாத்தியம், எடுத்துக்காட்டாக ரகசியங்கள் உள்ளே சென்றிருந்தால்.

GitLab-இல் MR-ஐ எழுதியவரோ அனுமதி பெற்ற பங்கேற்பாளரோ மூடலாம்; நீக்குவது திட்ட உரிமையாளர் அல்லது நிர்வாகியின் வேலை. PR-க்குள் கடவுச்சொல் அல்லது token போய்விட்டால், மூடுவது போதாது: அதை உடனே ரத்து செய்யுங்கள், ஏனெனில் commit-கள் ஏற்கனவே சேவையகத்துக்குச் சென்றுவிட்டன.

Pull request-இல் பொதுவான தவறுகள்

  • main-இலிருந்து PR. உள்ளூர் main-இல் commit செய்து அதிலிருந்து PR திறந்தீர்கள். அடுத்த PR-இல் பழைய மாற்றங்களும் வரும். எப்போதும் தனிக் கிளையில் வேலை செய்யுங்கள்.
  • தவறான base கிளை. PR main-க்குப் பதிலாக develop-க்குத் திறக்கப்பட்டது, அல்லது நேர்மாறாக. PR தலைப்பின் அருகில் உள்ள Edit பொத்தானால் base-ஐ மாற்றலாம்.
  • தேவையற்ற கோப்புகள் diff-இல். Build கோப்புகள், node_modules, .env. அவற்றை .gitignore-இல் சேர்த்து, git rm --cached மூலம் index-இலிருந்து நீக்குங்கள்.
  • மிகப் பெரிய PR. பணியை பல தொடர் PR-களாகப் பிரியுங்கள்.
  • rebase-க்குப் பிறகு சாதாரண push. rejected (non-fast-forward) பிழை. --force அல்ல, git push --force-with-lease தேவை.
  • மோதல்கள். இணைய எடிட்டரில் கண்மூடித்தனமாகத் தீர்க்காதீர்கள் — main-ஐ உள்ளூரில் இழுத்து, தீர்த்து, சோதனைகளை இயக்குங்கள்.

Git flow மற்றும் பிற செயல்முறைகளில் pull request

Pull request எந்தக் குழு செயல்முறைக்கும் பொருந்தும். GitHub Flow-இல் எளிமை: main-இலிருந்து கிளை, PR, மதிப்பாய்வு, இணைப்பு, வெளியீடு. Git flow-இல் feature கிளைகளிலிருந்து develop-க்கு PR திறக்கப்படுகிறது; release மற்றும் hotfix கிளைகளும் main-க்கு PR வழியாகவே செல்கின்றன. Trunk-based வளர்ச்சியில் PR குறுகியவை, அவை நாட்களாக அல்ல, மணிநேரங்களாக வாழ்கின்றன. எந்த முறையானாலும் விதி ஒன்றே: பகிரப்பட்ட கிளைகளில் மாற்றங்கள் pull request வழியாக மட்டுமே வரும்.

சுருக்கம்

Pull request என்பது Git கட்டளை அல்ல, தளத்தின் வசதி: சேவையகத்துக்கு அனுப்பப்பட்ட ஒரு கிளை, அதனுடன் விவாதம், மதிப்பாய்வு, சோதனைகளுக்கான ஒரு பக்கம். GitLab-இல் அது merge request; உரையாடலில் PR, MR என்கிறோம். PR-ஐ தனிக் கிளையிலிருந்து உருவாக்குங்கள், சிறியதாக வையுங்கள், அதே கிளைக்குப் push செய்து புதுப்பியுங்கள், திட்டத்தின் வரலாற்றுக்கு ஏற்ற இணைப்பு முறையைத் தேர்ந்தெடுங்கள். Fork-கள், feature கிளைகள், pull request ஆகியவை Git பாடநெறியில் நடைமுறையில் விளக்கப்பட்டுள்ளன.

அடிக்கடி கேட்கப்படும் கேள்விகள்

ஒரு pull request-க்கு எத்தனை மதிப்பாய்வாளர்கள் தேவை?

பொதுவாக ஒருவர் அல்லது இருவர் போதும். குறைந்தபட்ச ஒப்புதல்களின் எண்ணிக்கை கிளைப் பாதுகாப்பு விதிகளில் அமைக்கப்படுகிறது; அவை இல்லாமல் இணைப்பு பொத்தான் கிடைக்காது.

fork இல்லாமல் pull request உருவாக்க முடியுமா?

ஆம், எழுதும் உரிமை இருந்தால், களஞ்சியத்திலேயே கிளையை உருவாக்கி அதிலிருந்து PR திறக்கலாம். எழுதும் உரிமை இல்லாதபோது மட்டுமே fork தேவை.

யாரும் PR-ஐ நீண்ட நாட்களாகப் பார்க்கவில்லை என்றால் என்ன செய்வது?

மதிப்பாய்வாளருக்கு ஒரு கருத்திலோ குழு அரட்டையிலோ பணிவாக நினைவூட்டுங்கள். திறந்த திட்டங்களில் காத்திருப்பு வாரங்கள் ஆகலாம்; PR, CONTRIBUTING.md விதிகளுக்கு ஏற்ப உள்ளதா என்று பாருங்கள்.

என் fork-இல் இரண்டு கிளைகளுக்கு இடையே pull request திறக்க முடியுமா?

ஆம், ஒப்பீட்டுப் பக்கத்தில் உங்கள் fork-ஐ base மற்றும் head இரண்டுமாகத் தேர்ந்தெடுங்கள். அசல் திட்டத்துக்கு அனுப்புவதற்கு முன் உங்கள் மாற்றங்களை மதிப்பாய்வு செய்ய இது பயனுள்ளது.

PR-இல் நான் எழுதாத commit-கள் ஏன் தெரிகின்றன?

பெரும்பாலும் கிளை புதுப்பிக்கப்படாத main-இலிருந்து உருவாக்கப்பட்டிருக்கும் அல்லது தவறான base கிளை தேர்ந்தெடுக்கப்பட்டிருக்கும். புதிய main-இல் rebase செய்யுங்கள் அல்லது PR அமைப்புகளில் base-ஐ மாற்றுங்கள்.

இந்தத் தலைப்பை வீடியோவில் கற்றுக்கொள்ளுங்கள்

“கிட்: ஆரம்பம் முதல் நம்பிக்கையான டெவலப்பர் வரை” பாடநெறியில் இந்தத் தலைப்பு பயிற்சியுடன் விரிவாக விளக்கப்பட்டுள்ளது.

பாடநெறிக்குச் செல்