ایا تاسو د 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 پیرودونکی نلرئ چې د کمانډ لاین ملاتړ کوي ، تاسو کولی شئ د نصب کولو لارښوونې ومومئ دلته.

ذخیره چمتو کړئ

تاسو به اړتیا ولرئ یو شخصي کاپي جوړه کړئ (فورک) د کورس لپاره د کوډ سره د ټیمپلیټ ذخیره په 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. له هغې وروسته ، راځئ چې په ژمنې کې زموږ ازموینې پرمخ وړلو لپاره ګیټ هک اضافه کړو. دلته یو کیچ شتون لري: د ګیټ هکس د ذخیره کولو برخه نه ګڼل کیږي او له همدې امله د کورس پاتې موادو سره د ګیټ هب څخه کلون نشي کیدی. د هک نصبولو لپاره تاسو باید چلولو ته اړتیا ولرئ 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 د ګیټ سره] (http://devops.redpill.solutions/).
• بله لاره دا ده چې یوازې یو ریموټ ذخیره وکاروئ او یوازې څانګه حساب کړئ master شریک شوی ذخیره "محفوظ شوی". په دې سناریو کې، انفرادي پراختیا کونکي خپل کوډ د لیرې پرتو ذخیره څانګو ته خپروي ترڅو نور کولی شي دا کوډ وګوري، که هرڅه سم وي، دا سره یوځای کړئ. master شریک ذخیره.

پدې ځانګړي کورس کې ، موږ به د کاري فلو څخه کار واخلو چې څانګې کاروي.

راځئ چې زموږ کوډ خپور کړو.

️ دنده

• په لیرې پرتو څانګې کې بدلونونه د ورته نوم سره ستاسو د کاري څانګې په څیر خپاره کړئ

کنوانډیټ

git push --set-upstream origin feature

د کشولو غوښتنه جوړه کړئ

د سرلیک سره د پلټ غوښتنه جوړه کړئ د ګامونو بیاکتنه. نصب کړئ feature لکه "سر څانګه" او master لکه "بیس څانګه".

ډاډ ترلاسه کړئ چې تاسو نصب کړی master د هغه د پټنځای د غوڅولو د "بیس څانګې" په توګه، زه به د کورس موادو ذخیره کې د بدلونونو غوښتنو ته ځواب ونه وایم.

په GitHub lingo کې، "بیس برانچ" هغه څانګه ده چې تاسو یې خپل کار پر مخ وړئ، او "سر څانګه" هغه څانګه ده چې وړاندیز شوي بدلونونه لري.

د بدلونونو په اړه بحث وکړئ، نوي ژمنې اضافه کړئ لکه څنګه چې بحث دوام لري

د کشولو غوښتنه (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 حالت تازه کولو په پای کې د ګیټ هب انٹرفیس کې ازموینې وګورئ.

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 لږ ګټور - دا به یوازې د ادغام ژمنې ومومي.

ریبیس

• د اوسنۍ څانګې څخه د بیس څانګې په پورتنۍ برخه کې یو له بل وروسته ژمنې تکراروي.
  • د نوي SHAs سره نوي ژمنې رامینځته کیږي ، د دې لامل کیږي چې په ګیټ هب کې ژمنې د اصلي پل غوښتنې سره سمون ولري ، مګر ورته نظرونه ندي.
  • ژمنې په پروسه کې بیا سره یوځای او تعدیل کیدی شي، یا حتی په یو کې ضمیمه کیدی شي.
• ډیری شخړې باید حل شي.
• تاسو ته اجازه درکوي یو خطي کیسه وساتئ.
  • کیسه ممکن لوستل اسانه وي ځکه چې د کوم معقول دلیل لپاره خورا اوږد نه وي.
  • اتوماتیک ډیبګ کول او د ستونزو حل کول یو څه اسانه دي: دا ممکنه کوي 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