നിങ്ങൾ Git കമാൻഡുകൾ പഠിച്ചിട്ടുണ്ടോ, എന്നാൽ യഥാർത്ഥത്തിൽ തുടർച്ചയായ ഏകീകരണം (CI) എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് സങ്കൽപ്പിക്കാൻ ആഗ്രഹിക്കുന്നുണ്ടോ? അല്ലെങ്കിൽ നിങ്ങളുടെ ദൈനംദിന പ്രവർത്തനങ്ങൾ ഒപ്റ്റിമൈസ് ചെയ്യാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുണ്ടോ? ഒരു GitHub റിപ്പോസിറ്ററി ഉപയോഗിച്ച് തുടർച്ചയായ സംയോജനത്തിൽ ഈ കോഴ്സ് നിങ്ങൾക്ക് പ്രായോഗിക കഴിവുകൾ നൽകും. ഈ കോഴ്‌സ് നിങ്ങൾക്ക് ക്ലിക്കുചെയ്യാൻ കഴിയുന്ന ഒരു മാന്ത്രികനാകാൻ ഉദ്ദേശിച്ചുള്ളതല്ല; നേരെമറിച്ച്, ആളുകൾ യഥാർത്ഥത്തിൽ ജോലിസ്ഥലത്ത് ചെയ്യുന്ന അതേ പ്രവർത്തനങ്ങൾ അവർ ചെയ്യുന്ന അതേ രീതിയിൽ നിങ്ങൾ ചെയ്യും. നിങ്ങൾ ഉൾപ്പെട്ട ഘട്ടങ്ങളിലൂടെ കടന്നുപോകുമ്പോൾ ഞാൻ സിദ്ധാന്തം വിശദീകരിക്കും.

എന്തു ചെയ്യണം?

ഞങ്ങൾ പുരോഗമിക്കുമ്പോൾ, സാധാരണ CI ഘട്ടങ്ങളുടെ ഒരു ലിസ്റ്റ് ഞങ്ങൾ ക്രമേണ സൃഷ്ടിക്കും, ഇത് ഈ ലിസ്റ്റ് ഓർമ്മിക്കുന്നതിനുള്ള മികച്ച മാർഗമാണ്. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, തുടർച്ചയായ സംയോജനം നടത്തുകയും തുടർച്ചയായ സംയോജനം നടത്തുകയും ചെയ്യുമ്പോൾ ഡവലപ്പർമാർ ചെയ്യുന്ന പ്രവർത്തനങ്ങളുടെ ഒരു ലിസ്റ്റ് ഞങ്ങൾ സൃഷ്ടിക്കും. ഞങ്ങളുടെ CI പ്രക്രിയയെ യഥാർത്ഥമായ ഒന്നിലേക്ക് അടുപ്പിക്കുന്നതിന് ഞങ്ങൾ ലളിതമായ ഒരു കൂട്ടം ടെസ്റ്റുകളും ഉപയോഗിക്കും.

നിങ്ങൾ കോഴ്‌സിലൂടെ പുരോഗമിക്കുമ്പോൾ ഈ GIF നിങ്ങളുടെ ശേഖരത്തിലെ പ്രതിബദ്ധതകൾ സ്കീമാറ്റിക് ആയി കാണിക്കുന്നു. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഇവിടെ സങ്കീർണ്ണമായ ഒന്നും തന്നെയില്ല, ഏറ്റവും ആവശ്യമുള്ളത് മാത്രം.

ഇനിപ്പറയുന്ന സ്റ്റാൻഡേർഡ് CI സാഹചര്യങ്ങളിലൂടെ നിങ്ങൾ കടന്നുപോകും:

• ഒരു സവിശേഷതയിൽ പ്രവർത്തിക്കുക;
• ഗുണനിലവാരം ഉറപ്പാക്കാൻ ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകളുടെ പ്രയോഗം;
• മുൻഗണനാ ചുമതല നടപ്പിലാക്കൽ;
• ശാഖകൾ ലയിപ്പിക്കുമ്പോൾ വൈരുദ്ധ്യ പരിഹാരം (തർക്കം ലയിപ്പിക്കുക);
• ഉൽപ്പാദന പരിതസ്ഥിതിയിൽ ഒരു പിശക് സംഭവിക്കുന്നു.

നിങ്ങൾ എന്ത് പഠിക്കും?

ഇനിപ്പറയുന്ന ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകാൻ നിങ്ങൾക്ക് കഴിയും:

• എന്താണ് തുടർച്ചയായ സംയോജനം (CI)?
• CI-ൽ ഏത് തരത്തിലുള്ള ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകളാണ് ഉപയോഗിക്കുന്നത്, അവ ഏതൊക്കെ പ്രവർത്തനങ്ങളാണ് പ്രവർത്തനക്ഷമമാക്കുന്നത്?
• പുൾ അഭ്യർത്ഥനകൾ എന്തൊക്കെയാണ്, അവ എപ്പോൾ ആവശ്യമാണ്?
• എന്താണ് ടെസ്റ്റ് ഡ്രൈവൺ ഡെവലപ്‌മെന്റ് (ടിഡിഡി) അത് സിഐയുമായി എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നു?
• ഞാൻ മാറ്റങ്ങൾ ലയിപ്പിക്കണോ അതോ റീബേസ് ചെയ്യണോ?
• റോൾ ബാക്ക് ചെയ്യണോ അതോ അടുത്ത പതിപ്പിൽ പരിഹരിക്കണോ?

ആദ്യം ഞാൻ എല്ലായിടത്തും "അഭ്യർത്ഥനകൾ വലിച്ചിടുക" പോലെയുള്ള കാര്യങ്ങൾ വിവർത്തനം ചെയ്തു, പക്ഷേ അതിന്റെ ഫലമായി വാചകത്തിലെ ഭ്രാന്തിന്റെ അളവ് കുറയ്ക്കുന്നതിന് ചില സ്ഥലങ്ങളിൽ ഇംഗ്ലീഷിൽ വാക്യങ്ങൾ തിരികെ നൽകാൻ ഞാൻ തീരുമാനിച്ചു. ആളുകൾ യഥാർത്ഥത്തിൽ ജോലിസ്ഥലത്ത് ഉപയോഗിക്കുന്ന "കമ്മിറ്റ്" എന്ന അത്ഭുതകരമായ ക്രിയ പോലെ ഞാൻ ചിലപ്പോൾ "പ്രോഗ്രാമർ സുർജിക്" ഉപയോഗിക്കും.

എന്താണ് തുടർച്ചയായ സംയോജനം?

തുടർച്ചയായ ഏകീകരണം, അല്ലെങ്കിൽ CI, ഒരു സാങ്കേതിക സമ്പ്രദായമാണ്, അതിൽ ഓരോ ടീം അംഗവും ഒരു ദിവസത്തിൽ ഒരിക്കലെങ്കിലും അവരുടെ കോഡ് ഒരു പൊതു ശേഖരത്തിലേക്ക് സംയോജിപ്പിക്കുന്നു, തത്ഫലമായുണ്ടാകുന്ന കോഡ് കുറഞ്ഞത് പിശകുകളില്ലാതെ നിർമ്മിക്കണം.

ഈ പദത്തെക്കുറിച്ച് അഭിപ്രായവ്യത്യാസങ്ങളുണ്ട്

സംയോജനത്തിന്റെ ആവൃത്തിയാണ് തർക്കവിഷയം. തുടർച്ചയായി സംയോജിപ്പിക്കാൻ ദിവസത്തിൽ ഒരിക്കൽ മാത്രം കോഡ് ലയിപ്പിക്കുന്നത് പര്യാപ്തമല്ലെന്ന് ചിലർ വാദിക്കുന്നു. എല്ലാവരും രാവിലെ പുതിയ കോഡ് എടുക്കുകയും വൈകുന്നേരം ഒരിക്കൽ അത് സംയോജിപ്പിക്കുകയും ചെയ്യുന്ന ഒരു ടീമിന്റെ ഒരു ഉദാഹരണം നൽകിയിരിക്കുന്നു. ഇതൊരു ന്യായമായ എതിർപ്പാണെങ്കിലും, ഒരു ദിവസത്തിൽ ഒരിക്കൽ എന്ന നിർവചനം ന്യായമായും പ്രായോഗികവും നിർദ്ദിഷ്ടവും വ്യത്യസ്ത വലുപ്പത്തിലുള്ള ടീമുകൾക്ക് അനുയോജ്യവുമാണെന്ന് പൊതുവെ വിശ്വസിക്കപ്പെടുന്നു.

മറ്റൊരു എതിർപ്പ്, വികസനത്തിൽ ഉപയോഗിക്കുന്ന ഒരേയൊരു ഭാഷ C++ മാത്രമല്ല, മൂല്യനിർണ്ണയത്തിനുള്ള ഒരു മാർഗമായി പിശക് രഹിത അസംബ്ലി ആവശ്യപ്പെടുന്നത് ദുർബലമാണ്. ചില ടെസ്റ്റുകൾ (ഉദാഹരണത്തിന്, പ്രാദേശികമായി എക്സിക്യൂട്ട് ചെയ്ത യൂണിറ്റ് ടെസ്റ്റുകൾ) വിജയകരമായി പൂർത്തിയാക്കണം. ഇപ്പോൾ, കമ്മ്യൂണിറ്റി ഇത് ഒരു ആവശ്യകതയാക്കുന്നതിലേക്ക് നീങ്ങുകയാണ്, ഭാവിയിൽ "ബിൽഡ് + യൂണിറ്റ് ടെസ്റ്റുകൾ" ഇത് ഇതിനകം ചെയ്തിട്ടില്ലെങ്കിൽ, ഒരുപക്ഷേ സാധാരണ രീതിയായി മാറും.

തുടർച്ചയായ ഏകീകരണം അതിൽ നിന്ന് വ്യത്യസ്തമാണ് തുടർച്ചയായ ഡെലിവറി (തുടർച്ചയുള്ള ഡെലിവറി, സിഡി) ഓരോ ഏകീകരണ സൈക്കിളിന് ശേഷവും ഒരു റിലീസ് കാൻഡിഡേറ്റ് ആവശ്യമില്ല.

കോഴ്‌സിലുടനീളം ഞങ്ങൾ ഉപയോഗിക്കുന്ന ഘട്ടങ്ങളുടെ പട്ടിക

1. ഏറ്റവും പുതിയ കോഡ് വലിക്കുക. നിന്ന് ഒരു ശാഖ സൃഷ്ടിക്കുക master. ജോലി തുടങ്ങുക.
2. നിങ്ങളുടെ പുതിയ ശാഖയിൽ കമ്മിറ്റുകൾ സൃഷ്ടിക്കുക. പ്രാദേശികമായി നിർമ്മിക്കുകയും പരീക്ഷിക്കുകയും ചെയ്യുക. പാസ്സ്? അടുത്ത ഘട്ടത്തിലേക്ക് പോകുക. പരാജയപ്പെടുമോ? പിശകുകളോ പരിശോധനകളോ പരിഹരിച്ച് വീണ്ടും ശ്രമിക്കുക.
3. നിങ്ങളുടെ വിദൂര സംഭരണിയിലേക്കോ റിമോട്ട് ബ്രാഞ്ചിലേക്കോ അമർത്തുക.
4. ഒരു പുൾ അഭ്യർത്ഥന സൃഷ്ടിക്കുക. മാറ്റങ്ങൾ ചർച്ച ചെയ്യുക, ചർച്ച തുടരുമ്പോൾ കൂടുതൽ കമ്മിറ്റുകൾ ചേർക്കുക. ഫീച്ചർ ബ്രാഞ്ചിൽ ടെസ്റ്റുകൾ വിജയിപ്പിക്കുക.
5. മാസ്റ്ററിൽ നിന്ന് ലയിപ്പിക്കുക/റീബേസ് കമ്മിറ്റുകൾ. ലയന ഫലത്തിൽ ടെസ്റ്റുകൾ വിജയിപ്പിക്കുക.
6. ഫീച്ചർ ബ്രാഞ്ചിൽ നിന്ന് ഉൽപ്പാദനത്തിലേക്ക് വിന്യസിക്കുക.
7. കുറച്ച് സമയത്തേക്ക് ഉൽപ്പാദനത്തിൽ എല്ലാം മികച്ചതാണെങ്കിൽ, മാസ്റ്ററിലേക്ക് മാറ്റങ്ങൾ ലയിപ്പിക്കുക.

️ തയ്യാറാക്കൽ

നിങ്ങൾക്ക് ശരിയായ സോഫ്‌റ്റ്‌വെയർ ഉണ്ടെന്ന് ഉറപ്പാക്കുക

ഈ കോഴ്സ് എടുക്കാൻ നിങ്ങൾക്ക് ആവശ്യമാണ് നൊദെ.ജ്സ് и 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 പ്രവർത്തനങ്ങൾ പ്രവർത്തനക്ഷമമാക്കിയില്ലെങ്കിൽ എന്റെ നിർദ്ദേശങ്ങൾ പാലിച്ച് നിങ്ങൾക്ക് കോഴ്സ് പൂർത്തിയാക്കാൻ കഴിയില്ല.

ഞങ്ങൾ ഇവിടെ രചിക്കുന്ന ലിസ്‌റ്റിന്റെ നിലവിലെ അവസ്ഥ കാണാൻ മാർക്ക്ഡൗൺ റെൻഡർ ചെയ്യാനുള്ള 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"

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

ഒരു റിമോട്ട് റിപ്പോസിറ്ററിയിലോ റിമോട്ട് ബ്രാഞ്ചിലോ കോഡ് പ്രസിദ്ധീകരിക്കുക

അവർ പ്രാദേശികമായി പ്രവർത്തിച്ചുകഴിഞ്ഞാൽ, ഡവലപ്പർമാർ സാധാരണയായി അവരുടെ കോഡ് പൊതുവായി ലഭ്യമാക്കുന്നതിനാൽ അത് പൊതുജനങ്ങളുമായി സംയോജിപ്പിക്കാൻ കഴിയും. GitHub ഉപയോഗിച്ച്, ശേഖരത്തിന്റെ (വ്യക്തിഗത ഫോർക്ക്) ഒരു വ്യക്തിഗത പകർപ്പിലേക്കോ ഒരു വ്യക്തിഗത ശാഖയിലേക്കോ സൃഷ്ടി പ്രസിദ്ധീകരിക്കുന്നതിലൂടെ ഇത് സാധാരണയായി കൈവരിക്കാനാകും.

• ഫോർക്കുകൾ ഉപയോഗിച്ച്, ഒരു ഡെവലപ്പർ റിമോട്ട് പങ്കിട്ട ശേഖരം ക്ലോൺ ചെയ്യുന്നു, അതിന്റെ ഒരു വ്യക്തിഗത റിമോട്ട് കോപ്പി സൃഷ്ടിക്കുന്നു, ഇത് ഫോർക്ക് എന്നും അറിയപ്പെടുന്നു. പ്രാദേശികമായി പ്രവർത്തിക്കാൻ ഇത് ഈ വ്യക്തിഗത ശേഖരത്തെ ക്ലോൺ ചെയ്യുന്നു. ജോലി പൂർത്തിയാകുകയും കമ്മിറ്റ് ചെയ്യപ്പെടുകയും ചെയ്യുമ്പോൾ, അവൻ അവരെ തന്റെ നാൽക്കവലയിലേക്ക് തള്ളിയിടുന്നു, അവിടെ അവ മറ്റുള്ളവർക്ക് ലഭ്യമാകുകയും പൊതുവായ ശേഖരത്തിലേക്ക് സംയോജിപ്പിക്കുകയും ചെയ്യും. GitHub-ലെ ഓപ്പൺ സോഴ്സ് പ്രോജക്ടുകളിൽ ഈ സമീപനം സാധാരണയായി ഉപയോഗിക്കുന്നു. എന്റെ വിപുലമായ കോഴ്‌സിലും ഇത് ഉപയോഗിക്കുന്നു [ടീം വർക്ക്, CI വിത്ത് Git] (http://devops.redpill.solutions/).
• ഒരു റിമോട്ട് റിപ്പോസിറ്ററി മാത്രം ഉപയോഗിക്കുക, ബ്രാഞ്ച് മാത്രം എണ്ണുക എന്നതാണ് മറ്റൊരു സമീപനം master "സംരക്ഷിത" എന്ന പങ്കിട്ട ശേഖരം. ഈ സാഹചര്യത്തിൽ, വ്യക്തിഗത ഡെവലപ്പർമാർ അവരുടെ കോഡ് ഒരു റിമോട്ട് റിപ്പോസിറ്ററിയുടെ ശാഖകളിലേക്ക് പ്രസിദ്ധീകരിക്കുന്നു, അതുവഴി മറ്റുള്ളവർക്ക് ഈ കോഡ് നോക്കാനാകും, എല്ലാം ക്രമത്തിലാണെങ്കിൽ, അത് ലയിപ്പിക്കുക master പങ്കിട്ട ശേഖരം.

ഈ പ്രത്യേക കോഴ്സിൽ, ഞങ്ങൾ ശാഖകൾ ഉപയോഗിക്കുന്ന ഒരു വർക്ക്ഫ്ലോ ഉപയോഗിക്കും.

നമുക്ക് നമ്മുടെ കോഡ് പ്രസിദ്ധീകരിക്കാം.

️ടാസ്ക്

• നിങ്ങളുടെ പ്രവർത്തിക്കുന്ന ബ്രാഞ്ചിന്റെ അതേ പേരിൽ ഒരു റിമോട്ട് ബ്രാഞ്ചിലേക്ക് മാറ്റങ്ങൾ പ്രസിദ്ധീകരിക്കുക

Команды

git push --set-upstream origin feature

ഒരു പുൾ അഭ്യർത്ഥന സൃഷ്ടിക്കുക

ഒരു ശീർഷകം ഉപയോഗിച്ച് ഒരു പുൾ അഭ്യർത്ഥന സൃഷ്ടിക്കുക ഘട്ടങ്ങളുടെ അവലോകനം... ഇൻസ്റ്റാൾ ചെയ്യുക feature "തല ശാഖ" പോലെയും master "ബേസ് ബ്രാഞ്ച്" പോലെ.

നിങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക master അവന്റെ ശേഖരം ഫോർക്ക് ചെയ്യുക ഒരു "ബേസ് ബ്രാഞ്ച്" എന്ന നിലയിൽ, കോഴ്‌സ് മെറ്റീരിയലുകളുടെ ശേഖരണത്തിലേക്കുള്ള മാറ്റത്തിനുള്ള അഭ്യർത്ഥനകളോട് ഞാൻ പ്രതികരിക്കില്ല.

GitHub ലിംഗോയിൽ, "ബേസ് ബ്രാഞ്ച്" എന്നത് നിങ്ങളുടെ ജോലിയെ അടിസ്ഥാനമാക്കിയുള്ള ശാഖയാണ്, കൂടാതെ "ഹെഡ് ബ്രാഞ്ച്" എന്നത് നിർദ്ദേശിച്ച മാറ്റങ്ങൾ ഉൾക്കൊള്ളുന്ന ശാഖയാണ്.

മാറ്റങ്ങൾ ചർച്ച ചെയ്യുക, ചർച്ച തുടരുമ്പോൾ പുതിയ കമ്മിറ്റുകൾ ചേർക്കുക

അഭ്യർത്ഥന വലിക്കുക(PR)

അഭ്യർത്ഥന വലിക്കുക(PR) കോഡ് ചർച്ച ചെയ്യാനും ഡോക്യുമെന്റ് ചെയ്യാനും കോഡ് അവലോകനം നടത്താനുമുള്ള ഒരു മാർഗമാണ്. മൊത്തത്തിലുള്ള കോഡിലേക്ക് വ്യക്തിഗത മാറ്റങ്ങൾ സമന്വയിപ്പിക്കുന്നതിനുള്ള പൊതുവായ രീതിയുടെ പേരിലാണ് പുൾ അഭ്യർത്ഥനകൾക്ക് പേര് നൽകിയിരിക്കുന്നത്. സാധാരണഗതിയിൽ, ഒരു വ്യക്തി പ്രോജക്റ്റിന്റെ റിമോട്ട് ഒഫീഷ്യൽ റിപ്പോസിറ്ററി ക്ലോൺ ചെയ്യുകയും പ്രാദേശികമായി കോഡിൽ പ്രവർത്തിക്കുകയും ചെയ്യുന്നു. ഇതിനുശേഷം, അവൻ തന്റെ സ്വകാര്യ റിമോട്ട് റിപ്പോസിറ്ററിയിൽ കോഡ് സ്ഥാപിക്കുകയും ഔദ്യോഗിക ശേഖരണത്തിന്റെ ഉത്തരവാദിത്തമുള്ളവരോട് എടുക്കാൻ ആവശ്യപ്പെടുകയും ചെയ്യുന്നു(വലിക്കുക) അതിന്റെ കോഡ് അവരുടെ പ്രാദേശിക ശേഖരണങ്ങളിലേക്ക്, അവിടെ അവർ അവലോകനം ചെയ്യുകയും സംയോജിപ്പിക്കുകയും ചെയ്യും(ലയിപ്പിക്കുക) അദ്ദേഹത്തിന്റെ. ഈ ആശയം മറ്റ് പേരുകളിലും അറിയപ്പെടുന്നു, ഉദാഹരണത്തിന്, ലയിപ്പിക്കാനുള്ള അഭ്യർത്ഥന.

നിങ്ങൾ യഥാർത്ഥത്തിൽ GitHub അല്ലെങ്കിൽ സമാനമായ പ്ലാറ്റ്‌ഫോമുകളുടെ പുൾ അഭ്യർത്ഥന സവിശേഷത ഉപയോഗിക്കേണ്ടതില്ല. ഡെവലപ്‌മെന്റ് ടീമുകൾ മുഖാമുഖ ആശയവിനിമയം, വോയ്‌സ് കോളുകൾ അല്ലെങ്കിൽ ഇമെയിൽ ഉൾപ്പെടെയുള്ള ആശയവിനിമയത്തിന്റെ മറ്റ് രീതികൾ ഉപയോഗിച്ചേക്കാം, എന്നാൽ ഫോറം ശൈലിയിലുള്ള പുൾ അഭ്യർത്ഥനകൾ ഉപയോഗിക്കുന്നതിന് ഇനിയും നിരവധി കാരണങ്ങളുണ്ട്. അവയിൽ ചിലത് ഇതാ:

• നിർദ്ദിഷ്ട കോഡ് മാറ്റങ്ങളുമായി ബന്ധപ്പെട്ട ചർച്ചകൾ സംഘടിപ്പിച്ചു;
• ഓട്ടോടെസ്റ്റർമാരിൽ നിന്നും സമപ്രായക്കാരിൽ നിന്നുമുള്ള പുരോഗതിയെക്കുറിച്ചുള്ള ഫീഡ്‌ബാക്ക് കാണാനുള്ള ഒരു സ്ഥലമായി;
• കോഡ് അവലോകനങ്ങളുടെ ഔപചാരികത;
• അതിനാൽ ഈ അല്ലെങ്കിൽ ആ കോഡിന്റെ പിന്നിലെ കാരണങ്ങളും പരിഗണനകളും പിന്നീട് നിങ്ങൾക്ക് കണ്ടെത്താനാകും.

നിങ്ങൾക്ക് എന്തെങ്കിലും ചർച്ച ചെയ്യാനോ ഫീഡ്‌ബാക്ക് നേടാനോ ആവശ്യമുള്ളപ്പോൾ സാധാരണയായി നിങ്ങൾ ഒരു പുൾ അഭ്യർത്ഥന സൃഷ്ടിക്കുന്നു. ഉദാഹരണത്തിന്, നിങ്ങൾ ഒന്നിലധികം വിധത്തിൽ നടപ്പിലാക്കാൻ കഴിയുന്ന ഒരു ഫീച്ചറിലാണ് പ്രവർത്തിക്കുന്നതെങ്കിൽ, നിങ്ങളുടെ ആശയങ്ങൾ പങ്കുവെക്കുന്നതിനും നിങ്ങളുടെ സഹകാരികളുമായി നിങ്ങളുടെ പദ്ധതികൾ ചർച്ച ചെയ്യുന്നതിനുമായി കോഡിന്റെ ആദ്യ വരി എഴുതുന്നതിന് മുമ്പ് നിങ്ങൾക്ക് ഒരു പുൾ അഭ്യർത്ഥന സൃഷ്ടിക്കാവുന്നതാണ്. ജോലി ലളിതമാണെങ്കിൽ, എന്തെങ്കിലും ഇതിനകം ചെയ്തുകഴിഞ്ഞാൽ ഒരു പുൾ അഭ്യർത്ഥന തുറക്കും, പ്രതിജ്ഞാബദ്ധമാണ്, ചർച്ച ചെയ്യാം. ചില സാഹചര്യങ്ങളിൽ, ഗുണനിലവാര നിയന്ത്രണ കാരണങ്ങളാൽ മാത്രം നിങ്ങൾ ഒരു 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 ഇന്റർഫേസിൽ ടെസ്റ്റുകൾ റൺ ചെയ്യുന്നത് കാണുക.

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. ഇക്കാരണത്താൽ, നമുക്ക് ഹെഡ് റിവൈൻഡ് ചെയ്യാൻ കഴിയില്ല master ത്രെഡിന്റെ അവസാനം വരെ feature. ഈ സാഹചര്യത്തിൽ, ഒന്നുകിൽ നമുക്ക് കമ്മിറ്റുകൾ ലയിപ്പിക്കുകയോ പ്രയോഗിക്കുകയോ ചെയ്യേണ്ടതുണ്ട് feature റീബേസ് master. പൊരുത്തക്കേടുകൾ ഇല്ലെങ്കിൽ GitHub-ന് യഥാർത്ഥത്തിൽ യാന്ത്രിക ലയനങ്ങൾ നടത്താൻ കഴിയും. അയ്യോ, ഞങ്ങളുടെ സാഹചര്യത്തിൽ, രണ്ട് ശാഖകൾക്കും ഫയലിൽ മത്സര മാറ്റങ്ങളുണ്ട് 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. പിആർ ലയന കമ്മിറ്റ് പഴയപടിയാക്കുക ഘട്ടങ്ങളുടെ അവലോകനം в 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