మీరు Git కమాండ్‌లను నేర్చుకున్నారా, అయితే వాస్తవానికి నిరంతర ఏకీకరణ (CI) ఎలా పనిచేస్తుందో ఊహించాలనుకుంటున్నారా? లేదా మీరు మీ రోజువారీ కార్యకలాపాలను ఆప్టిమైజ్ చేయాలనుకుంటున్నారా? ఈ కోర్సు మీకు GitHub రిపోజిటరీని ఉపయోగించి నిరంతర ఏకీకరణలో ఆచరణాత్మక నైపుణ్యాలను అందిస్తుంది. ఈ కోర్సు మీరు కేవలం క్లిక్ చేయగల విజార్డ్‌గా ఉద్దేశించబడలేదు; దీనికి విరుద్ధంగా, వ్యక్తులు వాస్తవానికి పనిలో చేసే చర్యలనే, వారు చేసే విధంగానే మీరు చేస్తారు. మీరు చేరి ఉన్న దశల ద్వారా వెళ్ళేటప్పుడు నేను సిద్ధాంతాన్ని వివరిస్తాను.

మనము ఏమి చేద్దాము?

మేము అభివృద్ధి చెందుతున్నప్పుడు, మేము సాధారణ CI దశల జాబితాను క్రమంగా సృష్టిస్తాము, ఇది ఈ జాబితాను గుర్తుంచుకోవడానికి గొప్ప మార్గం. మరో మాటలో చెప్పాలంటే, నిరంతర ఏకీకరణ చేస్తున్నప్పుడు, నిరంతర ఏకీకరణ చేస్తున్నప్పుడు డెవలపర్లు తీసుకునే చర్యల జాబితాను మేము సృష్టిస్తాము. మేము మా CI ప్రాసెస్‌ను నిజమైన దానికి దగ్గరగా తీసుకురావడానికి సాధారణ పరీక్షల సెట్‌ను కూడా ఉపయోగిస్తాము.

మీరు కోర్సులో పురోగతి చెందుతున్నప్పుడు ఈ GIF మీ రిపోజిటరీలోని కమిట్‌లను క్రమపద్ధతిలో చూపుతుంది. మీరు గమనిస్తే, ఇక్కడ సంక్లిష్టంగా ఏమీ లేదు మరియు చాలా అవసరమైనది మాత్రమే.

మీరు క్రింది ప్రామాణిక CI దృశ్యాల ద్వారా వెళతారు:

• ఫీచర్‌పై పని చేయండి;
• నాణ్యతను నిర్ధారించడానికి స్వయంచాలక పరీక్షల దరఖాస్తు;
• ప్రాధాన్యత విధిని అమలు చేయడం;
• శాఖలను విలీనం చేసేటప్పుడు సంఘర్షణ పరిష్కారం (విలీనం వైరుధ్యం);
• ఉత్పత్తి వాతావరణంలో లోపం ఏర్పడుతుంది.

మీరు ఏమి నేర్చుకుంటారు?

మీరు ఈ క్రింది ప్రశ్నలకు సమాధానం ఇవ్వగలరు:

• నిరంతర ఏకీకరణ (CI) అంటే ఏమిటి?
• CIలో ఏ రకమైన ఆటోమేటెడ్ పరీక్షలు ఉపయోగించబడతాయి మరియు ఏ చర్యలకు ప్రతిస్పందనగా అవి ప్రేరేపించబడతాయి?
• పుల్ అభ్యర్థనలు అంటే ఏమిటి మరియు అవి ఎప్పుడు అవసరం?
• టెస్ట్ డ్రైవెన్ డెవలప్‌మెంట్ (TDD) అంటే ఏమిటి మరియు ఇది CIకి ఎలా సంబంధం కలిగి ఉంటుంది?
• నేను మార్పులను విలీనం చేయాలా లేదా పునఃప్రారంభించాలా?
• తదుపరి సంస్కరణలో వెనక్కి వెళ్లాలా లేదా పరిష్కరించాలా?

మొదట నేను "అభ్యర్థనలను లాగండి" వంటి వాటిని ప్రతిచోటా అనువదించాను, కానీ దాని ఫలితంగా నేను టెక్స్ట్‌లోని పిచ్చి స్థాయిని తగ్గించడానికి కొన్ని ప్రదేశాలలో ఆంగ్లంలో పదబంధాలను తిరిగి ఇవ్వాలని నిర్ణయించుకున్నాను. నేను కొన్నిసార్లు "ప్రోగ్రామర్ సుర్జిక్" అనే అద్భుతమైన క్రియ "కమిట్" లాగా ఉపయోగిస్తాను, ఇక్కడ వ్యక్తులు దీన్ని పనిలో ఉపయోగిస్తున్నారు.

నిరంతర ఏకీకరణ అంటే ఏమిటి?

నిరంతర ఏకీకరణ, లేదా CI, అనేది ఒక సాంకేతిక అభ్యాసం, దీనిలో ప్రతి బృంద సభ్యుడు వారి కోడ్‌ను కనీసం రోజుకు ఒక్కసారైనా సాధారణ రిపోజిటరీలో విలీనం చేస్తారు మరియు ఫలితంగా కోడ్ కనీసం లోపాలు లేకుండా నిర్మించబడాలి.

ఈ పదానికి సంబంధించి భిన్నాభిప్రాయాలు ఉన్నాయి

వివాదాస్పద అంశం ఏకీకరణ యొక్క ఫ్రీక్వెన్సీ. వాస్తవానికి నిరంతరం ఏకీకృతం కావడానికి రోజుకు ఒకసారి మాత్రమే కోడ్‌ను విలీనం చేయడం సరిపోదని కొందరు వాదించారు. ప్రతి ఒక్కరూ ఉదయం తాజా కోడ్‌ని తీసుకొని సాయంత్రం ఒకసారి ఏకీకృతం చేసే బృందానికి ఒక ఉదాహరణ ఇవ్వబడింది. ఇది సహేతుకమైన అభ్యంతరం అయితే, సాధారణంగా రోజుకు ఒకసారి నిర్వచించడం అనేది సహేతుకంగా ఆచరణాత్మకమైనది, నిర్దిష్టమైనది మరియు విభిన్న పరిమాణాల జట్లకు అనుకూలంగా ఉంటుందని నమ్ముతారు.

మరొక అభ్యంతరం ఏమిటంటే, C++ అనేది ఇకపై అభివృద్ధిలో ఉపయోగించబడే ఏకైక భాష కాదు మరియు ధృవీకరణ మార్గంగా లోపం లేని అసెంబ్లీ అవసరం బలహీనంగా ఉంది. కొన్ని పరీక్షల సెట్లు (ఉదాహరణకు, స్థానికంగా అమలు చేయబడిన యూనిట్ పరీక్షలు) కూడా విజయవంతంగా పూర్తి చేయాలి. ప్రస్తుతానికి, సంఘం దీన్ని ఆవశ్యకంగా మార్చే దిశగా కదులుతోంది మరియు భవిష్యత్తులో "బిల్డ్ + యూనిట్ పరీక్షలు" ఇది ఇప్పటికే కాకపోతే బహుశా సాధారణ అభ్యాసంగా మారవచ్చు.

నిరంతర ఏకీకరణ నుండి భిన్నంగా ఉంటుంది నిరంతర డెలివరీ (నిరంతర డెలివరీ, CD) ప్రతి ఇంటిగ్రేషన్ సైకిల్ తర్వాత విడుదల అభ్యర్థి అవసరం లేదు.

మేము కోర్సు అంతటా ఉపయోగించే దశల జాబితా

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 చర్యలు ప్రారంభించబడకపోతే మీరు నా సూచనలను అనుసరించి కోర్సును పూర్తి చేయలేరు.

మేము ఇక్కడ కంపోజ్ చేస్తున్న జాబితా యొక్క ప్రస్తుత స్థితిని చూడటానికి మార్క్‌డౌన్‌ను రెండర్ చేసే 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 హుక్‌ని జోడిద్దాం. ఒక క్యాచ్ ఉంది: 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ని సృష్టించేటప్పుడు, మీరు ఈ క్రింది వాటిని చేస్తారు.

• మీరు ఏమి మార్చాలని మరియు ఎక్కడ ప్రతిపాదిస్తారో సూచించండి.
• మార్పుల ప్రయోజనాన్ని వివరిస్తూ వివరణను వ్రాయండి. మీరు కోరుకోవచ్చు:
  • కోడ్ నుండి స్పష్టంగా కనిపించని ఏదైనా ముఖ్యమైన వాటిని జోడించండి లేదా సందర్భాన్ని అర్థం చేసుకోవడానికి ఉపయోగకరమైన #బగ్‌లు మరియు కమిట్ నంబర్‌లు వంటివి;
  • మీరు ఎవరితో పని చేయాలనుకుంటున్నారో @పేర్కొనండి లేదా మీరు వాటిని తర్వాత వ్యాఖ్యలలో @పేర్కొనవచ్చు;
  • ఏదైనా విషయంలో సహాయం చేయమని సహోద్యోగులను అడగండి లేదా నిర్దిష్టమైనదాన్ని తనిఖీ చేయండి.

మీరు 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 దశల జాబితా యొక్క టెక్స్ట్‌ను జోడించి, కట్టుబడి ఉండండి. పరీక్షలు ఉత్తీర్ణత సాధిస్తున్నాయని మీరు చూస్తారు ("ఆకుపచ్చ").
ఆపై రిమోట్ రిపోజిటరీకి కొత్త కోడ్‌ను ప్రచురించండి మరియు పుల్ అభ్యర్థన చర్చ మరియు PR స్థితి నవీకరణ దిగువన ఉన్న 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. దీని కారణంగా మనం కేవలం HEADని రివైండ్ చేయలేము master థ్రెడ్ చివరి వరకు feature. ఈ పరిస్థితిలో, మేము కమిట్‌లను విలీనం చేయాలి లేదా వర్తింపజేయాలి feature పునఃస్థాపన master. వైరుధ్యాలు లేనట్లయితే GitHub వాస్తవానికి స్వయంచాలక విలీనాలను చేయగలదు. అయ్యో, మా పరిస్థితిలో, రెండు శాఖలు ఫైల్‌లో పోటీ మార్పులను కలిగి ఉన్నాయి ci.md. ఈ పరిస్థితిని విలీన వైరుధ్యం అని పిలుస్తారు మరియు మేము దానిని మాన్యువల్‌గా పరిష్కరించాలి.

విలీనం చేయండి లేదా రీబేస్ చేయండి

కలుపు

• అదనపు విలీన నిబద్ధతను సృష్టిస్తుంది మరియు పని చరిత్రను సేవ్ చేస్తుంది.
  • శాఖల యొక్క అసలైన కమిట్‌లను వాటి అసలు టైమ్‌స్టాంప్‌లు మరియు రచయితలతో భద్రపరుస్తుంది.
  • మార్పు అభ్యర్థన చర్చలలో కమిట్‌ల SHA మరియు వాటికి లింక్‌లను సేవ్ చేస్తుంది.
• ఒక పర్యాయ వైరుధ్య పరిష్కారం అవసరం.
• కథను నాన్‌లీనియర్‌గా చేస్తుంది.
  • పెద్ద సంఖ్యలో శాఖలు (IDE కేబుల్‌ను గుర్తుకు తెస్తాయి) కారణంగా కథ చదవడం కష్టంగా ఉంటుంది.
  • ఆటోమేటిక్ డీబగ్గింగ్‌ను మరింత కష్టతరం చేస్తుంది, ఉదా. 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