શું તમે ગિટ કમાન્ડ્સ શીખ્યા છો પરંતુ કલ્પના કરવા માંગો છો કે સતત એકીકરણ (CI) વાસ્તવિકતામાં કેવી રીતે કાર્ય કરે છે? અથવા કદાચ તમે તમારી દૈનિક પ્રવૃત્તિઓને ઑપ્ટિમાઇઝ કરવા માંગો છો? આ કોર્સ તમને GitHub રીપોઝીટરીનો ઉપયોગ કરીને સતત એકીકરણમાં વ્યવહારુ કૌશલ્ય આપશે. આ કોર્સનો હેતુ વિઝાર્ડ બનવાનો નથી કે જેના દ્વારા તમે ફક્ત ક્લિક કરી શકો; તેનાથી વિપરિત, તમે તે જ ક્રિયાઓ કરશો જે લોકો ખરેખર કામ પર કરે છે, તે જ રીતે તેઓ કરે છે. તમે સામેલ પગલાંઓમાંથી પસાર થશો તેમ હું સિદ્ધાંત સમજાવીશ.

આપણે શું કરીએ?

જેમ જેમ આપણે પ્રગતિ કરીશું તેમ, અમે ધીમે ધીમે લાક્ષણિક CI પગલાંઓની સૂચિ બનાવીશું, જે આ સૂચિને યાદ રાખવાની એક સરસ રીત છે. બીજા શબ્દોમાં કહીએ તો, અમે સતત એકીકરણ કરતી વખતે, સતત એકીકરણ કરતી વખતે વિકાસકર્તાઓ લેતી ક્રિયાઓની સૂચિ બનાવીશું. અમે અમારી CI પ્રક્રિયાને વાસ્તવિક પ્રક્રિયાની નજીક લાવવા માટે પરીક્ષણોના એક સરળ સેટનો પણ ઉપયોગ કરીશું.

આ GIF યોજનાકીય રીતે તમારા રિપોઝીટરીમાં કમિટ્સને બતાવે છે કારણ કે તમે કોર્સમાં આગળ વધો છો. જેમ તમે જોઈ શકો છો, અહીં કંઈ જટિલ નથી અને માત્ર સૌથી જરૂરી છે.

તમે નીચેના પ્રમાણભૂત CI દૃશ્યોમાંથી પસાર થશો:

• લક્ષણ પર કામ કરો;
• ગુણવત્તા સુનિશ્ચિત કરવા માટે સ્વચાલિત પરીક્ષણોની અરજી;
• અગ્રતા કાર્યનું અમલીકરણ;
• શાખાઓ મર્જ કરતી વખતે સંઘર્ષનું નિરાકરણ (મર્જ સંઘર્ષ);
• પ્રોડક્શન એન્વાયર્નમેન્ટમાં ભૂલ થાય છે.

તમે શું શીખશો?

તમે નીચેના પ્રશ્નોના જવાબ આપવા માટે સમર્થ હશો:

• સતત એકીકરણ (CI) શું છે?
• CI માં કયા પ્રકારના સ્વચાલિત પરીક્ષણોનો ઉપયોગ કરવામાં આવે છે, અને તે કઈ ક્રિયાઓ ટ્રિગર થાય છે તેના જવાબમાં?
• પુલ વિનંતીઓ શું છે અને તેમની ક્યારે જરૂર છે?
• ટેસ્ટ ડ્રિવન ડેવલપમેન્ટ (TDD) શું છે અને તે CI સાથે કેવી રીતે સંબંધિત છે?
• શું મારે ફેરફારોને મર્જ કરવું જોઈએ અથવા રીબેઝ કરવું જોઈએ?
• રોલ બેક કરીએ કે પછીના વર્ઝનમાં ઠીક કરીએ?

શરૂઆતમાં મેં દરેક જગ્યાએ "પુલ વિનંતીઓ" જેવી વસ્તુઓનો અનુવાદ કર્યો, પરંતુ પરિણામે મેં ટેક્સ્ટમાં ગાંડપણની ડિગ્રી ઘટાડવા માટે કેટલીક જગ્યાએ અંગ્રેજીમાં શબ્દસમૂહો પરત કરવાનું નક્કી કર્યું. હું કેટલીકવાર અદ્ભુત ક્રિયાપદ "કમિટ" ની જેમ "પ્રોગ્રામર સર્ઝિક" નો ઉપયોગ કરીશ જ્યાં લોકો ખરેખર કામ પર તેનો ઉપયોગ કરે છે.

સતત એકીકરણ શું છે?

સતત એકીકરણ, અથવા CI, એક તકનીકી પ્રેક્ટિસ છે જેમાં દરેક ટીમના સભ્ય તેમના કોડને દિવસમાં ઓછામાં ઓછા એક વખત એક સામાન્ય ભંડારમાં એકીકૃત કરે છે, અને પરિણામી કોડ ઓછામાં ઓછો ભૂલો વિના બાંધવો જોઈએ.

આ શબ્દ વિશે મતભેદો છે

વિવાદનો મુદ્દો એ એકીકરણની આવર્તન છે. કેટલાક એવી દલીલ કરે છે કે દિવસમાં માત્ર એક જ વાર કોડ મર્જ કરવો એ વાસ્તવમાં સતત એકીકૃત થવા માટે પૂરતું નથી. એક ટીમનું ઉદાહરણ આપવામાં આવ્યું છે જ્યાં દરેક વ્યક્તિ સવારે તાજો કોડ લે છે અને સાંજે એકવાર તેને એકીકૃત કરે છે. આ વાજબી વાંધો હોવા છતાં, સામાન્ય રીતે એવું માનવામાં આવે છે કે દિવસમાં એકવારની વ્યાખ્યા વ્યાજબી રીતે વ્યવહારુ, વિશિષ્ટ અને વિવિધ કદની ટીમો માટે યોગ્ય છે.

બીજો વાંધો એ છે કે C++ એ હવે વિકાસમાં વપરાતી એકમાત્ર ભાષા નથી, અને માન્યતાના માર્ગ તરીકે ભૂલ-મુક્ત એસેમ્બલીની આવશ્યકતા નબળી છે. પરીક્ષણોના કેટલાક સેટ (ઉદાહરણ તરીકે, સ્થાનિક રીતે ચલાવવામાં આવતા એકમ પરીક્ષણો) પણ સફળતાપૂર્વક પૂર્ણ થવા જોઈએ. આ ક્ષણે, સમુદાય આને જરૂરિયાત બનાવવા તરફ આગળ વધી રહ્યો છે, અને ભવિષ્યમાં "બિલ્ડ + યુનિટ પરીક્ષણો" કદાચ સામાન્ય પ્રથા બની જશે, જો તે પહેલાથી નથી.

સતત એકીકરણ થી અલગ સતત ડિલિવરી (સતત ડિલિવરી, સીડી) જેમાં દરેક એકીકરણ ચક્ર પછી તેને રિલીઝ ઉમેદવારની જરૂર નથી.

પગલાંઓની સૂચિ જેનો અમે સમગ્ર અભ્યાસક્રમ દરમિયાન ઉપયોગ કરીશું

1. નવીનતમ કોડ ખેંચો. થી શાખા બનાવો master. કામ કરવાનું શરુ કરો.
2. તમારી નવી શાખા પર કમિટ બનાવો. સ્થાનિક રીતે બનાવો અને પરીક્ષણ કરો. પાસ? આગલા પગલા પર જાઓ. નિષ્ફળ? ભૂલો અથવા પરીક્ષણોને ઠીક કરો અને ફરી પ્રયાસ કરો.
3. તમારા રિમોટ રિપોઝીટરી અથવા રિમોટ બ્રાન્ચ પર દબાણ કરો.
4. પુલ વિનંતી બનાવો. ફેરફારોની ચર્ચા કરો, ચર્ચા ચાલુ રહે તેમ વધુ કમિટ ઉમેરો. ફીચર બ્રાન્ચ પર ટેસ્ટ પાસ કરાવો.
5. માસ્ટર તરફથી મર્જ/રીબેસ કમિટ. મર્જ પરિણામ પર પરીક્ષણો પાસ કરો.
6. સુવિધા શાખાથી ઉત્પાદન સુધી જમાવટ કરો.
7. જો અમુક સમયગાળા માટે ઉત્પાદનમાં બધું સારું હોય, તો ફેરફારોને માસ્ટરમાં મર્જ કરો.

️ તૈયારી

ખાતરી કરો કે તમારી પાસે યોગ્ય સોફ્ટવેર છે

આ કોર્સ લેવા માટે તમારે જરૂર પડશે Node.js и 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. તે પછી, ચાલો કમિટ પર અમારા પરીક્ષણો ચલાવવા માટે ગિટ હૂક ઉમેરીએ. ત્યાં એક કેચ છે: ગિટ હુક્સને ભંડારનો ભાગ માનવામાં આવતો નથી અને તેથી બાકીની કોર્સ સામગ્રી સાથે ગિટહબમાંથી ક્લોન કરી શકાતું નથી. હૂક ઇન્સ્ટોલ કરવા માટે તમારે ચલાવવાની જરૂર છે 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 પર ઓપન સોર્સ પ્રોજેક્ટ્સમાં વપરાય છે. તેનો ઉપયોગ મારા એડવાન્સ કોર્સમાં પણ થાય છે [ટીમ વર્ક અને સીઆઈ વિથ ગિટ] (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. આ કારણે આપણે ફક્ત હેડ રીવાઇન્ડ કરી શકતા નથી 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 અને શક્ય તેટલી વહેલી તકે નવા સંસ્કરણનો ઉપયોગ કરી રહ્યાં છીએ. કારણ કે APIs અને ડેટાબેઝ સ્કીમા કોડને ઉત્પાદનમાં તૈનાત કરવામાં આવતાં બદલાય છે, સતત ડિલિવરી અને સારા પરીક્ષણ કવરેજ સાથે, રોલ બેક કરવું સામાન્ય રીતે આગલા સંસ્કરણમાં તેને ઠીક કરવા કરતાં વધુ મુશ્કેલ અને જોખમી છે.

કારણ કે પાછા ફરવાથી અમારા કિસ્સામાં કોઈ જોખમ નથી, અમે આ માર્ગ પર જઈશું, કારણ કે તે અમને પરવાનગી આપે છે

• શક્ય તેટલી વહેલી તકે ઉત્પાદન પરની ભૂલને ઠીક કરો;
• માં કોડ બનાવો 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