நீங்கள் Git கட்டளைகளைக் கற்றிருக்கிறீர்களா, ஆனால் தொடர்ச்சியான ஒருங்கிணைப்பு (CI) உண்மையில் எவ்வாறு செயல்படுகிறது என்பதை கற்பனை செய்ய விரும்புகிறீர்களா? அல்லது உங்கள் அன்றாட நடவடிக்கைகளை மேம்படுத்த விரும்புகிறீர்களா? GitHub களஞ்சியத்தைப் பயன்படுத்தி தொடர்ச்சியான ஒருங்கிணைப்பில் இந்த பாடநெறி உங்களுக்கு நடைமுறை திறன்களை வழங்கும். இந்த பாடநெறி நீங்கள் வெறுமனே கிளிக் செய்யக்கூடிய ஒரு வழிகாட்டியாக இருக்க விரும்பவில்லை; மாறாக, மக்கள் உண்மையில் வேலையில் செய்யும் அதே செயல்களை அவர்கள் செய்யும் அதே வழியில் நீங்கள் செய்வீர்கள். நீங்கள் சம்பந்தப்பட்ட படிகள் வழியாக செல்லும்போது நான் கோட்பாட்டை விளக்குகிறேன்.

நாம் என்ன செய்ய வேண்டும்?

நாங்கள் முன்னேறும்போது, ​​வழக்கமான CI படிகளின் பட்டியலை படிப்படியாக உருவாக்குவோம், இது இந்தப் பட்டியலை நினைவில் வைக்க சிறந்த வழியாகும். வேறு வார்த்தைகளில் கூறுவதானால், டெவலப்பர்கள் தொடர்ச்சியான ஒருங்கிணைப்பு மற்றும் தொடர்ச்சியான ஒருங்கிணைப்பு செய்யும் போது எடுக்கும் செயல்களின் பட்டியலை நாங்கள் உருவாக்குவோம். எங்கள் CI செயல்முறையை உண்மையான நிலைக்கு நெருக்கமாக கொண்டு வர எளிய சோதனைகளின் தொகுப்பையும் பயன்படுத்துவோம்.

இந்த GIF, நீங்கள் பாடத்திட்டத்தில் முன்னேறும்போது, ​​உங்கள் களஞ்சியத்தில் உள்ள கமிட்களை திட்டவட்டமாக காட்டுகிறது. நீங்கள் பார்க்க முடியும் என, இங்கே சிக்கலான எதுவும் இல்லை மற்றும் மிகவும் அவசியம் மட்டுமே.

பின்வரும் நிலையான CI காட்சிகளை நீங்கள் கடந்து செல்வீர்கள்:

• ஒரு அம்சத்தில் வேலை செய்யுங்கள்;
• தரத்தை உறுதிப்படுத்த தானியங்கி சோதனைகளின் பயன்பாடு;
• முன்னுரிமை பணியை செயல்படுத்துதல்;
• கிளைகளை ஒன்றிணைக்கும் போது மோதல் தீர்வு (முரண்பாடுகளை ஒன்றிணைத்தல்);
• உற்பத்தி சூழலில் பிழை ஏற்படுகிறது.

நீங்கள் என்ன கற்றுக் கொள்வீர்கள்?

பின்வரும் கேள்விகளுக்கு நீங்கள் பதிலளிக்க முடியும்:

• தொடர்ச்சியான ஒருங்கிணைப்பு (CI) என்றால் என்ன?
• CI இல் என்ன வகையான தானியங்கு சோதனைகள் பயன்படுத்தப்படுகின்றன, மேலும் அவை என்ன செயல்களுக்கு பதிலளிக்கின்றன?
• இழுக்கும் கோரிக்கைகள் என்றால் என்ன, அவை எப்போது தேவைப்படுகின்றன?
• டெஸ்ட் டிரைவன் டெவலப்மென்ட் (TDD) என்றால் என்ன, அது CI உடன் எவ்வாறு தொடர்புடையது?
• நான் மாற்றங்களை ஒன்றிணைக்க வேண்டுமா அல்லது மறுசீரமைக்க வேண்டுமா?
• பின்வாங்கவா அல்லது அடுத்த பதிப்பில் சரிசெய்யவா?

முதலில் நான் எல்லா இடங்களிலும் "கோரிக்கைகளை இழுத்தல்" போன்றவற்றை மொழிபெயர்த்தேன், ஆனால் இதன் விளைவாக உரையில் உள்ள பைத்தியக்காரத்தனத்தின் அளவைக் குறைக்க சில இடங்களில் ஆங்கிலத்தில் சொற்றொடர்களை வழங்க முடிவு செய்தேன். நான் சில நேரங்களில் "புரோகிராமர் surzhik" என்ற அற்புதமான வினைச்சொல் "கமிட்" போன்றவற்றைப் பயன்படுத்துவேன், அங்கு மக்கள் உண்மையில் அதை வேலையில் பயன்படுத்துவார்கள்.

தொடர்ச்சியான ஒருங்கிணைப்பு என்றால் என்ன?

தொடர்ச்சியான ஒருங்கிணைப்பு, அல்லது CI என்பது ஒரு தொழில்நுட்ப நடைமுறையாகும், இதில் ஒவ்வொரு குழு உறுப்பினரும் ஒரு நாளைக்கு ஒரு முறையாவது தங்கள் குறியீட்டை ஒரு பொதுவான களஞ்சியத்தில் ஒருங்கிணைத்து, அதன் விளைவாக வரும் குறியீடு குறைந்தபட்சம் பிழைகள் இல்லாமல் உருவாக்கப்பட வேண்டும்.

இந்த சொல் பற்றி கருத்து வேறுபாடுகள் உள்ளன

ஒருங்கிணைப்பின் அதிர்வெண்தான் சர்ச்சைக்குரிய புள்ளி. ஒரு நாளைக்கு ஒரு முறை மட்டுமே குறியீட்டை இணைப்பது உண்மையில் தொடர்ச்சியாக ஒருங்கிணைக்க போதுமானதாக இல்லை என்று சிலர் வாதிடுகின்றனர். ஒவ்வொருவரும் காலையில் புதிய குறியீட்டை எடுத்து மாலையில் ஒருமுறை ஒருங்கிணைக்கும் ஒரு குழுவின் உதாரணம் கொடுக்கப்பட்டுள்ளது. இது ஒரு நியாயமான ஆட்சேபனை என்றாலும், ஒரு நாளுக்கு ஒரு முறை வரையறை நியாயமான நடைமுறை, குறிப்பிட்ட மற்றும் வெவ்வேறு அளவுகளில் அணிகளுக்கு ஏற்றது என்று பொதுவாக நம்பப்படுகிறது.

மற்றொரு ஆட்சேபனை என்னவென்றால், C++ மட்டுமே வளர்ச்சியில் பயன்படுத்தப்படும் ஒரே மொழி அல்ல, மேலும் சரிபார்ப்பு முறையாக பிழை இல்லாத அசெம்பிளி தேவைப்படுவது பலவீனமானது. சில சோதனைகள் (உதாரணமாக, உள்நாட்டில் செயல்படுத்தப்படும் அலகு சோதனைகள்) வெற்றிகரமாக முடிக்கப்பட வேண்டும். இந்த நேரத்தில், சமூகம் இதை ஒரு தேவையாக மாற்றுவதை நோக்கி நகர்கிறது, மேலும் எதிர்காலத்தில் "உருவாக்கம் + அலகு சோதனைகள்" ஏற்கனவே இல்லை என்றால், அது பொதுவான நடைமுறையாக மாறும்.

தொடர்ச்சியான ஒருங்கிணைப்பு வேறுபடுகிறது தொடர்ச்சியான விநியோகம் (தொடர்ச்சியான விநியோகம், குறுவட்டு) ஒவ்வொரு ஒருங்கிணைப்பு சுழற்சிக்குப் பிறகும் ஒரு வெளியீட்டு வேட்பாளர் தேவையில்லை.

பாடநெறி முழுவதும் நாங்கள் பயன்படுத்தும் படிகளின் பட்டியல்

1. சமீபத்திய குறியீட்டை இழுக்கவும். ஒரு கிளையை உருவாக்கவும் master. வேலையைத் தொடங்கு.
2. உங்கள் புதிய கிளையில் கமிட்களை உருவாக்கவும். உள்நாட்டில் உருவாக்கி சோதிக்கவும். பாஸ்? அடுத்த படிக்குச் செல்லவும். தோல்வியா? பிழைகள் அல்லது சோதனைகளைச் சரிசெய்து மீண்டும் முயற்சிக்கவும்.
3. உங்கள் ரிமோட் ரிபோசிட்டரி அல்லது ரிமோட் கிளைக்கு தள்ளுங்கள்.
4. இழுக்கும் கோரிக்கையை உருவாக்கவும். மாற்றங்களைப் பற்றி விவாதிக்கவும், விவாதம் தொடரும் போது மேலும் உறுதிகளை சேர்க்கவும். அம்சக் கிளையில் சோதனைகளை அனுப்பவும்.
5. மாஸ்டரிடமிருந்து ஒன்றிணைத்தல்/மறுபேஸ் செய்தல். ஒன்றிணைப்பு முடிவில் சோதனைகளை அனுப்பவும்.
6. அம்சக் கிளையிலிருந்து உற்பத்திக்கு வரிசைப்படுத்தவும்.
7. சில காலத்திற்கு உற்பத்தியில் எல்லாம் நன்றாக இருந்தால், மாற்றங்களை மாஸ்டருடன் இணைக்கவும்.

️ தயாரிப்பு

உங்களிடம் சரியான மென்பொருள் உள்ளதா என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்

இந்த பாடத்தை எடுக்க உங்களுக்கு தேவைப்படும் node.js и Git வாடிக்கையாளர்.

நீங்கள் எந்த Git கிளையனையும் பயன்படுத்தலாம், ஆனால் நான் கட்டளை வரிக்கான கட்டளைகளை மட்டுமே வழங்குவேன்.

கட்டளை வரியை ஆதரிக்கும் Git கிளையன்ட் நிறுவப்பட்டுள்ளதா என்பதை உறுதிப்படுத்தவும்

கட்டளை வரியை ஆதரிக்கும் Git கிளையன்ட் உங்களிடம் இன்னும் இல்லை என்றால், நீங்கள் நிறுவல் வழிமுறைகளைக் காணலாம் இங்கே.

களஞ்சியத்தை தயார் செய்யவும்

நீங்கள் ஒரு தனிப்பட்ட நகலை (முட்கரண்டி) உருவாக்க வேண்டும் பாடநெறிக்கான குறியீட்டுடன் கூடிய டெம்ப்ளேட் களஞ்சியம் GitHub இல். இந்த தனிப்பட்ட பிரதியை அழைக்க ஒப்புக்கொள்வோம் பாட களஞ்சியம்.

முடிந்ததா? நீங்கள் இயல்புநிலை அமைப்புகளை மாற்றவில்லை என்றால், உங்கள் பாட களஞ்சியம் பெரும்பாலும் அழைக்கப்படும் continuous-integration-team-scenarios-students, இது உங்கள் GitHub கணக்கில் உள்ளது மற்றும் URL இப்படி இருக்கும்

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

நான் இந்த முகவரியை வெறுமனே அழைக்கிறேன் <URL репозитория>.

போன்ற கோண அடைப்புக்குறிகள் <тут> நீங்கள் அத்தகைய வெளிப்பாட்டை பொருத்தமான மதிப்புடன் மாற்ற வேண்டும் என்று அர்த்தம்.

என்பதை உறுதி செய்து கொள்ளுங்கள் GitHub செயல்கள் இந்த பாட களஞ்சியத்தில் சேர்க்கப்பட்டுள்ளது. அவை இயக்கப்படவில்லை என்றால், பக்கத்தின் நடுவில் உள்ள பெரிய பொத்தானைக் கிளிக் செய்வதன் மூலம் அவற்றை இயக்கவும், அதை நீங்கள் கிட்ஹப் இடைமுகத்தில் உள்ள செயல்களைக் கிளிக் செய்வதன் மூலம் பெறலாம்.

GitHub செயல்கள் இயக்கப்படாவிட்டால், எனது வழிமுறைகளைப் பின்பற்றி நீங்கள் படிப்பை முடிக்க முடியாது.

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

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

பதில்கள் பற்றி

இந்தப் படிப்பை முடிப்பதற்கான சிறந்த வழி, அதை நீங்களே செய்வதுதான் என்றாலும், உங்களுக்கு சில சிரமங்கள் இருக்கலாம்.

என்ன செய்வது என்று உங்களுக்குப் புரியவில்லை, தொடர முடியாது என்று நீங்கள் நினைத்தால், நீங்கள் நூலைப் பார்க்கலாம் solution, இது உங்கள் தொடக்கக் களஞ்சியத்தில் உள்ளது.
தயவுசெய்து ஒன்றிணைக்க வேண்டாம் solution в master பாடத்தின் போது. இந்த கிளையைப் பயன்படுத்தி என்ன செய்ய வேண்டும் என்பதைக் கண்டறியலாம் அல்லது உங்கள் குறியீட்டை ஆசிரியருடன் ஒப்பிடலாம், Git வழங்கும் அனைத்து திறன்களையும் பயன்படுத்தலாம். நீங்கள் முற்றிலும் தொலைந்துவிட்டால், உங்கள் கிளையை முழுமையாக மாற்றலாம் master ஒரு கிளையில் solution பின்னர் உங்களின் பணி கோப்பகத்தை உங்களுக்கு தேவையான பாடத்திற்கு மீட்டமைக்கவும்.

உங்களுக்கு உண்மையிலேயே தேவைப்பட்டால் மட்டுமே இதைப் பயன்படுத்தவும்

உங்கள் குறியீட்டை சமர்ப்பிக்கவும்

git add .
git commit -m "Backing up my work"

இந்த கட்டளைகள்

• மறுபெயரிடுங்கள் master в master-backup;
• மறுபெயரிடுங்கள் solution в master;
• புதிய கிளைக்கு செக்அவுட் master மற்றும் வேலை செய்யும் கோப்பகத்தின் உள்ளடக்கங்களை மீண்டும் எழுதவும்;
• எதிர்காலத்தில் உங்களுக்கு "தீர்வு" கிளை தேவைப்பட்டால், "மாஸ்டர்" (இது "தீர்வு" என்று பயன்படுத்தப்பட்டது) இலிருந்து "தீர்வு" கிளையை உருவாக்கவும்.

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

இந்த படிகளுக்குப் பிறகு நீங்கள் பயன்படுத்தலாம் git log master உங்களுக்கு எந்த அர்ப்பணிப்பு தேவை என்பதைக் கண்டுபிடிக்க.
உங்கள் பணிக் கோப்பகத்தை இந்த உறுதிக்கு மீட்டமைக்கலாம்:

git reset --hard <the SHA you need>

முடிவில் நீங்கள் மகிழ்ச்சியாக இருந்தால், ஒரு கட்டத்தில் உங்கள் களஞ்சியத்தின் பதிப்பை தொலை களஞ்சியத்தில் வெளியிட வேண்டும். இதைச் செய்யும்போது தொலைநிலைக் கிளையை வெளிப்படையாகக் குறிப்பிட மறக்காதீர்கள்.

git push --force origin master

நாங்கள் பயன்படுத்துகிறோம் என்பதை நினைவில் கொள்க git push --force. நீங்கள் இதை அடிக்கடி செய்ய விரும்புவது சாத்தியமில்லை, ஆனால் ஒரு களஞ்சியப் பயனரைக் கொண்டு, அவர் என்ன செய்கிறார் என்பதைப் புரிந்து கொள்ளும் ஒரு குறிப்பிட்ட சூழ்நிலையை நாங்கள் இங்கே வைத்திருக்கிறோம்.

வேலை ஆரம்பிக்கிறது

CI படிகளின் பட்டியலைத் தொகுக்க ஆரம்பிக்கலாம். பொதுவாக, தொலைநிலைக் களஞ்சியத்திலிருந்து குறியீட்டின் சமீபத்திய பதிப்பைப் பார்ப்பதன் மூலம் இந்தப் படியைத் தொடங்குவீர்கள், ஆனால் எங்களிடம் இன்னும் உள்ளூர் களஞ்சியம் இல்லை, எனவே தொலைநிலையிலிருந்து அதை குளோன் செய்கிறோம்.

️ பணி: உள்ளூர் களஞ்சியத்தைப் புதுப்பிக்கவும், ஒரு கிளையை உருவாக்கவும் master, வேலை செய்ய ஆரம்பியுங்கள்

1. இதிலிருந்து பாட களஞ்சியத்தை குளோன் செய்யவும் <URL репозитория>.
2. ஓடு npm install பாட களஞ்சிய கோப்பகத்தில்; சோதனைகளை இயக்க நாம் பயன்படுத்தும் ஜெஸ்டை நிறுவ இது தேவை.
3. ஒரு கிளையை உருவாக்கி அதற்கு பெயரிடவும் feature. இந்த திரிக்கு மாறவும்.

4. சோதனைக் குறியீட்டைச் சேர்க்கவும் ci.test.js கருத்துகளுக்கு இடையே இதைச் செய்யும்படி கேட்கிறேன்.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. கோப்பில் முதல் 4 படிகளுடன் உரையைச் சேர்க்கவும் ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   கட்டளைகளை

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

புதிய கிளையில் கமிட்களை உருவாக்கவும், உள்நாட்டில் உருவாக்கவும் மற்றும் சோதிக்கவும்

நாங்கள் சோதனைகளை மேற்கொள்வதற்கு முன் இயக்குவதற்கு அமைக்கப் போகிறோம், பின்னர் குறியீட்டை உருவாக்குவோம்.

சோதனைகள் தானாக இயங்கும்போது வழக்கமான காட்சிகள்

• உள்ளூரில்:
  • தொடர்ந்து அல்லது பொருத்தமான குறியீடு மாற்றங்களுக்கு பதிலளிக்கும் வகையில்;
  • சேமிப்பதில் (விளக்கம் செய்யப்பட்ட அல்லது JIT- தொகுக்கப்பட்ட மொழிகளுக்கு);
  • சட்டசபையின் போது (தொகுப்பு தேவைப்படும் போது);
  • உறுதி மீது;
  • பகிரப்பட்ட களஞ்சியத்தில் வெளியிடும் போது.

• உருவாக்க சர்வரில் அல்லது சூழலை உருவாக்க:
  • தனிப்பட்ட கிளை/தொகுதியில் குறியீடு வெளியிடப்படும் போது.
  • இந்த தொடரிழையில் உள்ள குறியீடு சோதிக்கப்படுகிறது.
  • இணைப்பின் சாத்தியமான முடிவு சோதிக்கப்படுகிறது (பொதுவாக உடன் master).
  • தொடர்ச்சியான ஒருங்கிணைப்பு நிலை/தொடர்ச்சியான விநியோக குழாய்

பொதுவாக, ஒரு சோதனைத் தொகுப்பு எவ்வளவு வேகமாக இயங்குகிறதோ, அவ்வளவு அடிக்கடி நீங்கள் அதை இயக்க முடியும். ஒரு பொதுவான நிலை விநியோகம் இப்படி இருக்கலாம்.

• வேகமான அலகு சோதனைகள் - கட்டும் போது, ​​CI பைப்லைனில்
• ஸ்லோ யூனிட் சோதனைகள், வேகமான கூறு மற்றும் ஒருங்கிணைப்பு சோதனைகள் - CI பைப்லைனில் உறுதி
• மெதுவான கூறு மற்றும் ஒருங்கிணைப்பு சோதனைகள் - CI பைப்லைனில்
• பாதுகாப்பு சோதனை, சுமை சோதனை மற்றும் பிற நேரத்தை எடுத்துக்கொள்ளும் அல்லது விலையுயர்ந்த சோதனைகள் - CI/CD பைப்லைன்களில், ஆனால் கட்டமைப்பின் சில முறைகள்/நிலைகள்/பைப்லைன்களில் மட்டுமே, எடுத்துக்காட்டாக, வெளியீட்டு வேட்பாளரைத் தயாரிக்கும் போது அல்லது கைமுறையாக இயங்கும் போது.

️ பணி

கட்டளையைப் பயன்படுத்தி முதலில் சோதனைகளை கைமுறையாக இயக்க பரிந்துரைக்கிறேன் npm test. அதன் பிறகு, உறுதியுடன் எங்கள் சோதனைகளை இயக்க ஜிட் ஹூக்கைச் சேர்ப்போம். ஒரு கேட்ச் உள்ளது: Git ஹூக்குகள் களஞ்சியத்தின் ஒரு பகுதியாக கருதப்படுவதில்லை, எனவே மீதமுள்ள பாடப் பொருட்களுடன் GitHub இலிருந்து குளோன் செய்ய முடியாது. ஹூக்கை நிறுவ நீங்கள் இயக்க வேண்டும் install_hook.sh அல்லது கோப்பை நகலெடுக்கவும் repo/hooks/pre-commit உள்ளூர் கோப்பகத்திற்கு .git/hooks/.
நீங்கள் உறுதியளிக்கும்போது, ​​​​சோதனைகள் இயக்கப்படுவதைக் காண்பீர்கள், மேலும் அவை பட்டியலில் சில முக்கிய வார்த்தைகள் உள்ளதா என்று பார்க்கவும்.

1. கட்டளையை இயக்குவதன் மூலம் சோதனைகளை கைமுறையாக இயக்கவும் npm test உங்கள் பாட களஞ்சிய கோப்புறையில். சோதனைகள் முடிந்ததா என்பதை உறுதிப்படுத்தவும்.
2. ஓடுவதன் மூலம் கமிட் ஹூக்கை (முன்-கமிட் ஹூக்) அமைக்கவும் install_hook.sh.
3. உங்கள் மாற்றங்களை உங்கள் உள்ளூர் களஞ்சியத்தில் சமர்ப்பிக்கவும்.
4. சோதனைகளை மேற்கொள்வதற்கு முன் நடத்தப்படுவதை உறுதிசெய்யவும்.

இந்தப் படிகளைப் பின்பற்றிய பிறகு உங்கள் களஞ்சியம் இப்படி இருக்க வேண்டும்.

கட்டளைகளை

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

தொலைநிலைக் களஞ்சியம் அல்லது தொலைநிலைக் கிளையில் குறியீட்டை வெளியிடவும்

அவர்கள் உள்நாட்டில் வேலை செய்து முடித்தவுடன், டெவலப்பர்கள் பொதுவாக தங்கள் குறியீட்டை பொதுவில் கிடைக்கச் செய்கிறார்கள், இதனால் இறுதியில் அது பொதுமக்களுடன் ஒருங்கிணைக்கப்படும். கிட்ஹப் மூலம், படைப்பை களஞ்சியத்தின் தனிப்பட்ட நகலுக்கு (தனிப்பட்ட ஃபோர்க்) அல்லது தனிப்பட்ட கிளைக்கு வெளியிடுவதன் மூலம் இது பொதுவாக அடையப்படுகிறது.

• ஃபோர்க்ஸ் மூலம், டெவலப்பர் ரிமோட் ஷேர்ட் ரெபோசிட்டரியை குளோன் செய்து, அதன் தனிப்பட்ட ரிமோட் நகலை உருவாக்குகிறார், இது ஃபோர்க் என்றும் அழைக்கப்படுகிறது. இது உள்நாட்டில் வேலை செய்ய இந்த தனிப்பட்ட களஞ்சியத்தை குளோன் செய்கிறது. வேலை முடிந்ததும், உறுதிமொழிகள் செய்யப்படும்போது, ​​அவர் அவற்றை தனது முட்கரண்டிக்குள் தள்ளுகிறார், அங்கு அவை மற்றவர்களுக்குக் கிடைக்கும் மற்றும் பொதுவான களஞ்சியத்தில் ஒருங்கிணைக்கப்படலாம். இந்த அணுகுமுறை பொதுவாக கிட்ஹப்பில் திறந்த மூல திட்டங்களில் பயன்படுத்தப்படுகிறது. இது எனது மேம்பட்ட பாடத்திலும் [டீம் ஒர்க் மற்றும் CI உடன் Git] பயன்படுத்தப்படுகிறது (http://devops.redpill.solutions/).
• மற்றொரு அணுகுமுறை ஒரே ஒரு ரிமோட் களஞ்சியத்தைப் பயன்படுத்துவதாகும் மற்றும் கிளையை மட்டுமே எண்ணுவது master பகிரப்பட்ட களஞ்சியம் "பாதுகாக்கப்பட்டது". இந்த சூழ்நிலையில், தனிப்பட்ட டெவலப்பர்கள் தங்கள் குறியீட்டை தொலை களஞ்சியத்தின் கிளைகளில் வெளியிடுகிறார்கள், இதனால் மற்றவர்கள் இந்த குறியீட்டைப் பார்க்க முடியும், எல்லாம் ஒழுங்காக இருந்தால், அதை இணைக்கவும் master பகிர்ந்த களஞ்சியம்.

இந்தக் குறிப்பிட்ட பாடத்திட்டத்தில், கிளைகளைப் பயன்படுத்தும் பணிப்பாய்வுகளைப் பயன்படுத்துவோம்.

எங்கள் குறியீட்டை வெளியிடுவோம்.

️ பணி

• நீங்கள் பணிபுரியும் கிளையின் அதே பெயரில் ரிமோட் கிளையில் மாற்றங்களை வெளியிடவும்

கட்டளைகளை

git push --set-upstream origin feature

இழுக்கும் கோரிக்கையை உருவாக்கவும்

தலைப்புடன் இழுக்க கோரிக்கையை உருவாக்கவும் படிகள் மதிப்பாய்வு. நிறுவு feature "தலை கிளை" மற்றும் master "அடிப்படை கிளை" போன்றது.

நீங்கள் நிறுவியுள்ளீர்கள் என்பதை உறுதிப்படுத்தவும் master அவரது களஞ்சியத்தை பலப்படுத்து "அடிப்படை கிளையாக", பாடப் பொருட்கள் களஞ்சியத்தில் மாற்றங்களுக்கான கோரிக்கைகளுக்கு நான் பதிலளிக்க மாட்டேன்.

GitHub லிங்கோவில், "அடிப்படை கிளை" என்பது உங்கள் வேலையை அடிப்படையாகக் கொண்ட கிளையாகும், மேலும் "தலை கிளை" என்பது முன்மொழியப்பட்ட மாற்றங்களைக் கொண்ட கிளை ஆகும்.

மாற்றங்களைப் பற்றி விவாதிக்கவும், விவாதம் தொடரும் போது புதிய கமிட்களைச் சேர்க்கவும்

கோரிக்கையை இழுக்கவும்(PR)

கோரிக்கையை இழுக்கவும்(PR) குறியீட்டை விவாதிப்பதற்கும் ஆவணப்படுத்துவதற்கும் ஒரு வழி, அத்துடன் குறியீடு மதிப்பாய்வு நடத்துவது. ஒட்டுமொத்த குறியீட்டில் தனிப்பட்ட மாற்றங்களை ஒருங்கிணைக்கும் பொதுவான வழியின் அடிப்படையில் இழுக்கும் கோரிக்கைகள் பெயரிடப்படுகின்றன. பொதுவாக, ஒரு நபர் திட்டத்தின் ரிமோட் அதிகாரப்பூர்வ களஞ்சியத்தை குளோன் செய்து உள்நாட்டில் குறியீட்டில் வேலை செய்கிறார். இதற்குப் பிறகு, அவர் தனது தனிப்பட்ட ரிமோட் களஞ்சியத்தில் குறியீட்டை வைத்து, அதிகாரப்பூர்வ களஞ்சியத்திற்கு பொறுப்பானவர்களை எடுக்கும்படி கேட்கிறார்(இழுக்க) அதன் குறியீடு அவர்களின் உள்ளூர் களஞ்சியங்களில், அங்கு அவர்கள் மதிப்பாய்வு செய்து ஒருங்கிணைக்க முடியும்(ஒன்றாக்க) அவரது. இந்த கருத்து வேறு பெயர்களாலும் அறியப்படுகிறது, எடுத்துக்காட்டாக, ஒன்றிணைக்கும் கோரிக்கை.

நீங்கள் உண்மையில் GitHub அல்லது அதுபோன்ற இயங்குதளங்களின் இழுக்கும் கோரிக்கை அம்சத்தைப் பயன்படுத்த வேண்டியதில்லை. மேம்பாட்டுக் குழுக்கள், நேருக்கு நேர் தொடர்பு, குரல் அழைப்புகள் அல்லது மின்னஞ்சல் உள்ளிட்ட பிற தகவல்தொடர்பு முறைகளைப் பயன்படுத்தலாம், ஆனால் மன்ற பாணியில் இழுக்கும் கோரிக்கைகளைப் பயன்படுத்த இன்னும் பல காரணங்கள் உள்ளன. அவற்றில் சில இங்கே:

• குறிப்பிட்ட குறியீடு மாற்றங்கள் தொடர்பான ஒழுங்கமைக்கப்பட்ட விவாதங்கள்;
• ஆட்டோடெஸ்டர்கள் மற்றும் சகாக்கள் இருவரிடமிருந்தும் வேலையில் உள்ள கருத்துகளைப் பார்க்கும் இடமாக;
• குறியீடு மதிப்புரைகளை முறைப்படுத்துதல்;
• இந்த அல்லது அந்த குறியீட்டின் பின்னால் உள்ள காரணங்களையும் பரிசீலனைகளையும் பின்னர் நீங்கள் கண்டுபிடிக்கலாம்.

பொதுவாக நீங்கள் எதையாவது விவாதிக்க அல்லது கருத்துகளைப் பெற வேண்டியிருக்கும் போது இழுக்கும் கோரிக்கையை உருவாக்குவீர்கள். எடுத்துக்காட்டாக, ஒன்றுக்கு மேற்பட்ட வழிகளில் செயல்படுத்தக்கூடிய அம்சத்தில் நீங்கள் பணிபுரிந்தால், உங்கள் யோசனைகளைப் பகிர்ந்து கொள்ளவும், உங்கள் திட்டங்களை உங்கள் கூட்டுப்பணியாளர்களுடன் விவாதிக்கவும் குறியீட்டின் முதல் வரியை எழுதுவதற்கு முன் இழுக்கும் கோரிக்கையை உருவாக்கலாம். வேலை எளிமையானதாக இருந்தால், ஏதாவது ஏற்கனவே செய்து முடிக்கப்பட்டிருக்கும் போது, ​​ஒரு இழுப்புக் கோரிக்கை திறக்கப்பட்டு, விவாதிக்கப்படும். சில சூழ்நிலைகளில், தரக் கட்டுப்பாட்டு காரணங்களுக்காக மட்டுமே நீங்கள் PRஐத் திறக்க விரும்பலாம்: தானியங்கு சோதனைகளை இயக்க அல்லது குறியீடு மதிப்பாய்வுகளைத் தொடங்க. நீங்கள் என்ன முடிவெடுத்தாலும், உங்கள் கோரிக்கையில் அனுமதி பெற விரும்பும் நபர்களை @குறிப்பிட மறக்காதீர்கள்.

பொதுவாக, PR ஐ உருவாக்கும் போது, ​​பின்வருவனவற்றைச் செய்யுங்கள்.

• நீங்கள் எதை மாற்ற விரும்புகிறீர்கள், எங்கு குறிப்பிடுகிறீர்கள்.
• மாற்றங்களின் நோக்கத்தை விளக்கும் விளக்கத்தை எழுதுங்கள். நீங்கள் விரும்பலாம்:
  • குறியீட்டிலிருந்து தெளிவாகத் தெரியாத முக்கியமான எதையும் சேர்க்கவும் அல்லது சூழலைப் புரிந்துகொள்ள பயனுள்ள #பிழைகள் மற்றும் உறுதி எண்கள் போன்றவற்றைச் சேர்க்கவும்;
  • நீங்கள் யாருடன் பணிபுரிய விரும்புகிறீர்களோ அவர்களை @குறிப்பிடுங்கள் அல்லது பின்னர் கருத்துகளில் அவர்களை @குறிப்பிடலாம்;
  • ஏதாவது உதவி செய்ய சக ஊழியர்களைக் கேளுங்கள் அல்லது குறிப்பிட்ட ஒன்றைச் சரிபார்க்கவும்.

நீங்கள் PR ஐத் திறந்ததும், இதுபோன்ற சந்தர்ப்பங்களில் இயக்க கட்டமைக்கப்பட்ட சோதனைகள் செயல்படுத்தப்படும். எங்கள் விஷயத்தில், நாங்கள் உள்நாட்டில் நடத்திய அதே சோதனைகளின் தொகுப்பாக இது இருக்கும், ஆனால் உண்மையான திட்டத்தில் கூடுதல் சோதனைகள் மற்றும் காசோலைகள் இருக்கலாம்.

சோதனைகள் முடியும் வரை காத்திருக்கவும். GitHub இடைமுகத்தில் PR விவாதத்தின் கீழே சோதனைகளின் நிலையைப் பார்க்கலாம். சோதனைகள் முடிந்ததும் தொடரவும்.

️ CI படிகளின் பட்டியலின் சீரற்ற தன்மை பற்றிய குறிப்பைச் சேர்க்கவும்

இந்தப் பாடத்திட்டத்தில் பயன்படுத்தப்படும் பட்டியல் தன்னிச்சையானது மற்றும் அகநிலையானது, இதைப் பற்றிய குறிப்பை நாம் சேர்க்க வேண்டும்.

️ பணி: இந்தக் கருத்துக்கு இழுக்கும் கோரிக்கையை உருவாக்கவும்

1. கிளைக்கு மாறவும் master.
2. என்ற பெயரில் ஒரு கிளையை உருவாக்கவும் bugfix.
3. கோப்பின் முடிவில் குறிப்பு உரையைச் சேர்க்கவும் ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. மாற்றங்களைச் செய்யுங்கள்.
5. நூலை வெளியிடுங்கள் bugfix ஒரு தொலை களஞ்சியத்திற்கு.
6. என்ற பெயரில் இழுக்கும் கோரிக்கையை உருவாக்கவும் ஒரு கருத்தைச் சேர்த்தல் ஒரு தலை கிளையுடன் bugfix மற்றும் அடிப்படை கிளைmaster.

நீங்கள் நிறுவியுள்ளீர்கள் என்பதை உறுதிப்படுத்தவும் master அவரது களஞ்சியத்தை பலப்படுத்து "அடிப்படை கிளையாக", பாடப் பொருட்கள் களஞ்சியத்தில் மாற்றங்களுக்கான கோரிக்கைகளுக்கு நான் பதிலளிக்க மாட்டேன்.

உங்கள் களஞ்சியம் இப்படித்தான் இருக்க வேண்டும்.

கட்டளைகளை

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

"ஒரு குறிப்பைச் சேர்ப்பது" என்ற இழுக்கும் கோரிக்கையை அங்கீகரிக்கவும்

️ பணி

1. இழுக்கும் கோரிக்கையை உருவாக்கவும்.
2. "இழுக்கும் கோரிக்கையை ஒன்றிணை" என்பதைக் கிளிக் செய்யவும்.
3. "ஒன்றிணைப்பை உறுதிப்படுத்து" என்பதைக் கிளிக் செய்யவும்.
4. "கிளையை நீக்கு" என்பதைக் கிளிக் செய்யவும், எங்களுக்கு இனி அது தேவையில்லை.

இது ஒன்றிணைந்த பிறகு உறுதிமொழிகளின் வரைபடம்.

️ தொடர்ந்து வேலை செய்து சோதனைகளைச் சேர்க்கவும்

இழுக்கும் கோரிக்கையில் கூட்டுப்பணியாற்றுவது பெரும்பாலும் கூடுதல் வேலையில் விளைகிறது. இது வழக்கமாக ஒரு குறியீடு மதிப்பாய்வு அல்லது விவாதத்தின் விளைவாகும், ஆனால் எங்கள் பாடத்திட்டத்தில் எங்கள் CI படிகளின் பட்டியலில் புதிய உருப்படிகளைச் சேர்ப்பதன் மூலம் இதை மாதிரியாக மாற்றப் போகிறோம்.

தொடர்ச்சியான ஒருங்கிணைப்பு பொதுவாக சில சோதனைக் கவரேஜை உள்ளடக்கியது. சோதனை கவரேஜ் தேவைகள் மாறுபடும் மற்றும் பொதுவாக "பங்களிப்புக்கான வழிகாட்டுதல்கள்" போன்ற ஆவணத்தில் காணப்படுகின்றன. நாங்கள் அதை எளிமையாக வைத்து, எங்கள் சரிபார்ப்புப் பட்டியலில் ஒவ்வொரு வரிக்கும் ஒரு சோதனையைச் சேர்ப்போம்.

பணிகளை இயக்கும்போது, ​​முதலில் சோதனைகளைச் செய்ய முயற்சிக்கவும். நீங்கள் சரியாக நிறுவியிருந்தால் pre-commit முன்னதாக, புதிதாக சேர்க்கப்பட்ட சோதனை நடத்தப்படும், தோல்வியடையும், எதுவும் செய்யப்படாது. எங்கள் சோதனைகள் உண்மையில் எதையாவது சோதிக்கின்றன என்பதை நாங்கள் அறிவோம் என்பதை நினைவில் கொள்க. சுவாரஸ்யமாக, சோதனைகளுக்கு முன் குறியீட்டைக் கொண்டு தொடங்கினால், சோதனைகளில் தேர்ச்சி பெறுவது குறியீடு எதிர்பார்த்தபடி செயல்பட்டது அல்லது சோதனைகள் உண்மையில் எதையும் சோதிக்கவில்லை என்று அர்த்தம். கூடுதலாக, நாங்கள் முதலில் தேர்வுகளை எழுதவில்லை என்றால், அவற்றைப் பற்றி நாம் முற்றிலும் மறந்துவிடலாம், ஏனென்றால் எதுவும் நமக்கு நினைவூட்டியிருக்காது.

சோதனை உந்துதல் மேம்பாடு (TDD)

குறியீட்டிற்கு முன் சோதனைகளை எழுத TDD பரிந்துரைக்கிறது. TDD ஐப் பயன்படுத்தும் ஒரு பொதுவான பணிப்பாய்வு இதுபோல் தெரிகிறது.

1. ஒரு சோதனையைச் சேர்க்கவும்.
2. அனைத்து சோதனைகளையும் இயக்கவும் மற்றும் புதிய சோதனை தோல்வியடைவதை உறுதி செய்யவும்.
3. குறியீட்டை எழுதுங்கள்.
4. சோதனைகளை இயக்கவும், எல்லா சோதனைகளும் தேர்ச்சி பெறுவதை உறுதிப்படுத்தவும்.
5. உங்கள் குறியீட்டை மறுவடிவமைக்கவும்.
6. மீண்டும் செய்யவும்.

தோல்வியடைந்த சோதனைகளின் முடிவுகள் பொதுவாக சிவப்பு நிறத்திலும், தேர்ச்சி பெற்றவை பொதுவாக பச்சை நிறத்திலும் காட்டப்படுவதால், சுழற்சி சிவப்பு-பச்சை-ரீஃபாக்டர் என்றும் அழைக்கப்படுகிறது.

️ பணி

முதலில், சோதனைகளைச் செய்து அவற்றைத் தோல்வியடையச் செய்ய முயற்சிக்கவும், பின்னர் CI படிப் பட்டியலின் உரையைச் சேர்க்கவும். சோதனைகள் கடந்து வருவதை நீங்கள் காண்பீர்கள் ("பச்சை").
பின்னர் புதிய குறியீட்டை ரிமோட் களஞ்சியத்தில் வெளியிட்டு, புல் கோரிக்கை விவாதத்தின் கீழே உள்ள GitHub இடைமுகத்தில் சோதனைகள் இயங்குவதையும் PR நிலை புதுப்பித்தலையும் பார்க்கவும்.

1. கிளைக்கு மாறவும் feature.

2. இந்த சோதனைகளைச் சேர்க்கவும் ci.test.js கடைசி அழைப்புக்குப் பிறகு it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. சோதனைகளைச் செய்ய முயற்சிக்கவும். என்றால் pre-commit ஹூக் நிறுவப்பட்டது, உறுதி முயற்சி தோல்வியடையும்.
4. பின்னர் இந்த உரையைச் சேர்க்கவும் ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. உள்நாட்டில் மாற்றங்களைச் செய்யுங்கள்.
6. கிளையில் மாற்றங்களை இடுகையிடவும் feature.

உங்களிடம் இப்போது இதுபோன்ற ஏதாவது இருக்க வேண்டும்

கட்டளைகளை

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

மோதலை ஒன்றிணைக்கவும்

மாற்றுக் கோரிக்கைக்குச் செல்லவும் படிகள் மதிப்பாய்வு.

நாங்கள் எந்த தவறும் செய்யவில்லை என்றாலும், எங்கள் குறியீட்டிற்கான சோதனைகள் வெற்றி பெற்றாலும், எங்களால் இன்னும் கிளையை இணைக்க முடியவில்லை feature и master. இது மற்ற நூல் என்பதால் bugfix உடன் இணைக்கப்பட்டது master நாங்கள் இந்த PR இல் பணிபுரியும் போது.
இதனால் தொலைதூர கிளைகள் செல்லும் நிலை உருவாகிறது master நாங்கள் உருவாக்கிய கிளையை விட புதிய பதிப்பு உள்ளது feature. இதனாலேயே நம்மால் HEADஐ மட்டும் ரிவைண்ட் செய்ய முடியாது master நூலின் இறுதி வரை feature. இந்த சூழ்நிலையில், நாம் ஒன்றிணைக்க வேண்டும் அல்லது கமிட்களை விண்ணப்பிக்க வேண்டும் feature மறுதளம் master. எந்த முரண்பாடுகளும் இல்லாவிட்டால், கிட்ஹப் உண்மையில் தானாக ஒன்றிணைக்க முடியும். ஐயோ, எங்கள் சூழ்நிலையில், இரண்டு கிளைகளும் கோப்பில் போட்டியிடும் மாற்றங்களைக் கொண்டுள்ளன ci.md. இந்தச் சூழ்நிலையானது ஒன்றிணைப்பு முரண்பாடாக அறியப்படுகிறது, அதை நாம் கைமுறையாகத் தீர்க்க வேண்டும்.

ஒன்றிணைத்தல் அல்லது மறுசீரமைத்தல்

செல்ல

• கூடுதல் இணைப்பு உறுதியை உருவாக்கி, பணி வரலாற்றைச் சேமிக்கிறது.
  • கிளைகளின் அசல் கமிட்களை அவற்றின் அசல் நேர முத்திரைகள் மற்றும் ஆசிரியர்களுடன் பாதுகாக்கிறது.
  • மாற்றக் கோரிக்கை விவாதங்களில் கமிட்களின் SHA மற்றும் அவற்றுக்கான இணைப்புகளைச் சேமிக்கிறது.
• ஒரு முறை மோதல் தீர்வு தேவை.
• கதையை நான்-லீனியர் ஆக்குகிறது.
  • அதிக எண்ணிக்கையிலான கிளைகள் (ஐடிஇ கேபிளை நினைவூட்டுவது) காரணமாக கதையைப் படிப்பது கடினமாக இருக்கலாம்.
  • தானியங்கி பிழைத்திருத்தத்தை மிகவும் கடினமாக்குகிறது, எ.கா. git bisect குறைவான பயனுள்ளது - இது ஒன்றிணைப்பு உறுதியை மட்டுமே கண்டுபிடிக்கும்.

மறுதொடக்கம்

• ரீப்ளேக்கள் ஒன்றன் பின் ஒன்றாக அடிப்படைக் கிளையின் மேல் உள்ள தற்போதைய கிளையிலிருந்து உறுதியளிக்கிறது.
  • புதிய SHAகளுடன் புதிய கமிட்கள் உருவாக்கப்படுகின்றன, இதனால் GitHub இல் உள்ள கமிட்கள் அசல் இழுக்கும் கோரிக்கைகளுடன் பொருந்துகின்றன, ஆனால் தொடர்புடைய கருத்துகள் அல்ல.
  • செயல்பாட்டில் உறுதிகளை மீண்டும் இணைக்கலாம் மற்றும் மாற்றலாம் அல்லது ஒன்றில் இணைக்கலாம்.
• பல முரண்பாடுகள் தீர்க்கப்பட வேண்டியிருக்கலாம்.
• நேரியல் கதையை பராமரிக்க உங்களை அனுமதிக்கிறது.
  • எந்த நியாயமான காரணமும் இல்லாமல் நீண்டதாக இல்லாத வரை கதை படிக்க எளிதாக இருக்கும்.
  • தானியங்கி பிழைத்திருத்தம் மற்றும் சரிசெய்தல் சற்று எளிதானது: அதை சாத்தியமாக்குகிறது git bisect, தானியங்கு ரோல்பேக்குகளை தெளிவாகவும் யூகிக்கக்கூடியதாகவும் மாற்ற முடியும்.
• ஒரு கொடியுடன் இடம்பெயர்ந்த கமிட்களுடன் ஒரு கிளையை வெளியிட வேண்டும் --force இழுக்கும் கோரிக்கைகளுடன் பயன்படுத்தும் போது.

பொதுவாக, அணிகள் மாற்றங்களை ஒன்றிணைக்கும் போது எப்போதும் ஒரே உத்தியைப் பயன்படுத்த ஒப்புக்கொள்கின்றன. இது "தூய்மையான" இணைப்பு அல்லது மேலே "தூய்மையான" உறுதிமொழியாக இருக்கலாம் அல்லது இடையிலுள்ள ஏதோவொன்றாக இருக்கலாம்.git rebase -i) பொது களஞ்சியத்தில் வெளியிடப்படாத கிளைகளுக்கு உள்நாட்டில், ஆனால் "பொது" கிளைகளுக்கு ஒன்றிணைக்கப்படும்.

இங்கே நாம் ஒன்றிணைப்பதைப் பயன்படுத்துவோம்.

️ பணி

1. குறியீடு உள்ளூர் கிளையில் இருப்பதை உறுதிசெய்யவும் master தொலைநிலைக் களஞ்சியத்திலிருந்து புதுப்பிக்கப்பட்டது.
2. கிளைக்கு மாறவும் feature.
3. ஒரு கிளையுடன் இணைவதைத் தொடங்கவும் master. போட்டியிடும் மாற்றங்கள் காரணமாக ஒரு இணைப்பு முரண்பாடு ci.md.
4. எங்கள் CI படிகளின் பட்டியல் மற்றும் அதைப் பற்றிய குறிப்பு ஆகிய இரண்டும் உரையில் இருக்கும்படி மோதலைத் தீர்க்கவும்.
5. தொலைதூரக் கிளையில் ஒன்றிணைக்கும் உறுதிமொழியை வெளியிடவும் feature.
6. GitHub UI இல் இழுக்கும் கோரிக்கையின் நிலையைச் சரிபார்த்து, ஒன்றிணைப்பு தீர்க்கப்படும் வரை காத்திருக்கவும்.

கட்டளைகளை

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

பெரிய வேலை!

நீங்கள் பட்டியலை முடித்துவிட்டீர்கள், இப்போது நீங்கள் இழுக்கும் கோரிக்கையை அங்கீகரிக்க வேண்டும் master.

️ பணி: "படிகள் மதிப்பாய்வு" இழுக்கும் கோரிக்கையை அங்கீகரிக்கவும்

1. இழுக்கும் கோரிக்கையைத் திறக்கவும்.
2. "இழுக்கும் கோரிக்கையை ஒன்றிணை" என்பதைக் கிளிக் செய்யவும்.
3. "ஒன்றிணைப்பை உறுதிப்படுத்து" என்பதைக் கிளிக் செய்யவும்.
4. "கிளையை நீக்கு" என்பதைக் கிளிக் செய்யவும், ஏனெனில் அது நமக்கு இனி தேவையில்லை.

இந்த நேரத்தில் உங்கள் களஞ்சியமாகும்

தயாரிப்பு பிழை

"பரிசோதனை பிழைகள் இருப்பதைக் காட்டப் பயன்படும், ஆனால் அவை இல்லாததைக் காட்டக் கூடாது" என்று கூறப்படுகிறது. எங்களிடம் சோதனைகள் இருந்தபோதிலும், அவர்கள் எங்களுக்கு எந்த பிழையும் காட்டவில்லை என்றாலும், ஒரு நயவஞ்சகமான பிழை உற்பத்தியில் ஊடுருவியது.

இது போன்ற ஒரு சூழ்நிலையில், நாம் கவனிக்க வேண்டியது:

• உற்பத்தியில் என்ன பயன்படுத்தப்படுகிறது;
• நூலில் குறியீடு master ஒரு பிழையுடன், டெவலப்பர்கள் புதிய வேலையைத் தொடங்கலாம்.

நான் பின்வாங்க வேண்டுமா அல்லது அடுத்த பதிப்பில் சரி செய்ய வேண்டுமா?

ரோலிங் பேக் என்பது, நன்கு அறியப்பட்ட முந்தைய பதிப்பை உற்பத்திக்கு வரிசைப்படுத்துவதும், பிழையைக் கொண்டிருக்கும் கமிட்களை மாற்றியமைப்பதும் ஆகும். "ஃபிக்சிங் ஃபார்வர்ட்" என்பது ஒரு ஃபிக்ஸ் உடன் கூடுதலாகும் master மேலும் புதிய பதிப்பை கூடிய விரைவில் பயன்படுத்தவும். தொடர்ச்சியான டெலிவரி மற்றும் நல்ல சோதனைக் கவரேஜுடன், உற்பத்திக்கு குறியீடு பயன்படுத்தப்படுவதால், APIகள் மற்றும் தரவுத்தளத் திட்டங்கள் மாறுவதால், அடுத்த பதிப்பில் அதைச் சரிசெய்வதை விட, பின்வாங்குவது மிகவும் கடினம் மற்றும் ஆபத்தானது.

பின்வாங்குவது எங்கள் விஷயத்தில் எந்த ஆபத்தையும் ஏற்படுத்தாது என்பதால், நாங்கள் இந்த வழியில் செல்வோம், ஏனெனில் இது நம்மை அனுமதிக்கிறது

• தயாரிப்பில் உள்ள பிழையை விரைவில் சரிசெய்யவும்;
• குறியீட்டை உருவாக்கவும் master ஒரு புதிய வேலையைத் தொடங்குவதற்கு உடனடியாக ஏற்றது.

️ பணி

1. கிளைக்கு மாறவும் master உள்ளூரில்
2. தொலை களஞ்சியத்திலிருந்து உள்ளூர் களஞ்சியத்தைப் புதுப்பிக்கவும்.
3. PR இணைப்பு உறுதியை மாற்றவும் படிகள் மதிப்பாய்வு в master.
4. ரிமோட் களஞ்சியத்தில் மாற்றங்களை வெளியிடவும்.

இது ஒன்றிணைக்கப்பட்ட ஒரு களஞ்சியத்தின் வரலாறு மாற்றியமைக்கப்பட்டது

கட்டளைகளை

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ சுய பரிசோதனை

என்பதை உறுதி செய்து கொள்ளுங்கள் ci.md இணைப்பு உறுதியை மாற்றிய பின் "ஸ்னீக்கி பக்" என்ற உரை இனி இருக்காது.

CI படிகளின் பட்டியலைச் சரிசெய்து, அதை மாஸ்டருக்குத் திருப்பி விடுங்கள்

கிளையின் இணைப்பு உறுதிமொழியை முழுமையாக மாற்றிவிட்டோம். feature. நல்ல செய்தி என்னவென்றால், இப்போது நம்மிடம் எந்த தவறும் இல்லை master. மோசமான செய்தி என்னவென்றால், தொடர்ச்சியான ஒருங்கிணைப்பு படிகளின் எங்கள் விலைமதிப்பற்ற பட்டியலும் இல்லாமல் போய்விட்டது. எனவே, சிறந்த முறையில், நாம் செய்த கமிட்களுக்கு தீர்வைப் பயன்படுத்த வேண்டும் feature மற்றும் அவற்றை திரும்பவும் master சரிசெய்தலுடன்.

பிரச்சனையை நாம் வெவ்வேறு வழிகளில் அணுகலாம்:

• ஒன்றிணைப்பை செயல்தவிர்க்கும் உறுதிமொழியை மாற்றவும் feature с master;
• முன்னாள் இருந்து நகர்வு உறுதி feature.

வெவ்வேறு மேம்பாட்டுக் குழுக்கள் இந்த விஷயத்தில் வெவ்வேறு அணுகுமுறைகளைப் பயன்படுத்துகின்றன, ஆனால் நாங்கள் பயனுள்ள கமிட்களை ஒரு தனி கிளைக்கு நகர்த்துவோம் மற்றும் இந்த புதிய கிளைக்கு ஒரு தனி இழுக்கும் கோரிக்கையை உருவாக்குவோம்.

️ பணி

1. என்று ஒரு நூலை உருவாக்கவும் feature-fix மற்றும் அதற்கு மாறவும்.

2. முந்தைய கிளையிலிருந்து அனைத்து கடமைகளையும் நகர்த்தவும் feature ஒரு புதிய இழைக்கு. இடம்பெயர்வின் போது ஏற்பட்ட ஒன்றிணைப்பு மோதல்களைத் தீர்க்கவும்.

   

3. பின்னடைவு சோதனையைச் சேர்க்கவும் ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. சோதனைகள் தோல்வியடையவில்லை என்பதை உறுதிப்படுத்த உள்நாட்டில் நடத்தவும்.
5. "ஒரு ஸ்னீக்கி பிழையுடன்" என்ற உரையை அகற்றவும் ci.md.
6. குறியீட்டில் சோதனை மாற்றங்கள் மற்றும் படி பட்டியல் மாற்றங்களைச் சேர்த்து அவற்றைச் செய்யுங்கள்.
7. கிளையை தொலை களஞ்சியத்தில் வெளியிடவும்.

இதைப் போன்ற ஒன்றை நீங்கள் முடிக்க வேண்டும்:

கட்டளைகளை

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

இழுக்கும் கோரிக்கையை உருவாக்கவும்.

தலைப்புடன் இழுக்க கோரிக்கையை உருவாக்கவும் அம்சத்தை சரிசெய்தல். நிறுவு feature-fix "தலை கிளை" மற்றும் master "அடிப்படை கிளை" போன்றது.
சோதனைகள் முடியும் வரை காத்திருக்கவும். PR விவாதத்தின் கீழே சோதனைகளின் நிலையைப் பார்க்கலாம்.

நீங்கள் நிறுவியுள்ளீர்கள் என்பதை உறுதிப்படுத்தவும் master அவரது களஞ்சியத்தை பலப்படுத்து "அடிப்படை கிளையாக", பாடப் பொருட்கள் களஞ்சியத்தில் மாற்றங்களுக்கான கோரிக்கைகளுக்கு நான் பதிலளிக்க மாட்டேன்.

"அம்சத்தை சரிசெய்தல்" என்ற இழுக்கும் கோரிக்கையை அங்கீகரிக்கவும்

திருத்தத்திற்கு நன்றி! மாற்றங்களை அங்கீகரிக்கவும் master இழுக்க கோரிக்கையிலிருந்து.

️ பணி

1. "இழுக்கும் கோரிக்கையை ஒன்றிணை" என்பதைக் கிளிக் செய்யவும்.
2. "ஒன்றிணைப்பை உறுதிப்படுத்து" என்பதைக் கிளிக் செய்யவும்.
3. "கிளையை நீக்கு" என்பதைக் கிளிக் செய்யவும், ஏனெனில் அது நமக்கு இனி தேவையில்லை.

இந்த நேரத்தில் உங்களிடம் இருக்க வேண்டியது இதுதான்.

வாழ்த்துக்கள்!

தொடர்ச்சியான ஒருங்கிணைப்பின் போது பொதுவாக மக்கள் எடுக்கும் அனைத்து படிகளையும் முடித்துவிட்டீர்கள்.

பாடத்திட்டத்தில் ஏதேனும் சிக்கல்களை நீங்கள் கவனித்தால் அல்லது அதை எவ்வாறு மேம்படுத்துவது என்று தெரிந்தால், தயவுசெய்து சிக்கலை உருவாக்கவும் பாடப் பொருட்கள் கொண்ட களஞ்சியங்கள். இந்தப் பாடமும் உண்டு ஊடாடும் பதிப்பு GitHub கற்றல் ஆய்வகத்தை ஒரு தளமாகப் பயன்படுத்துதல்.

ஆதாரம்: www.habr.com