Git commands များကို သင်လေ့လာပြီးသော်လည်း လက်တွေ့တွင် စဉ်ဆက်မပြတ်ပေါင်းစည်းခြင်း (CI) အလုပ်လုပ်ပုံကို စိတ်ကူးကြည့်လိုပါသလား။ ဒါမှမဟုတ် မင်းရဲ့နေ့စဉ်လှုပ်ရှားမှုတွေကို အကောင်းဆုံးဖြစ်အောင် လုပ်ချင်တာလား။ ဤသင်တန်းသည် သင့်အား GitHub repository ကို အသုံးပြု၍ စဉ်ဆက်မပြတ်ပေါင်းစည်းမှုတွင် လက်တွေ့ကျသောစွမ်းရည်များကို ပေးမည်ဖြစ်ပါသည်။ ဤသင်တန်းသည် သင်ရိုးရှင်းစွာ နှိပ်နိုင်သော wizard တစ်ခုဖြစ်လာရန် ရည်ရွယ်ခြင်းမဟုတ်ပါ၊ ဆန့်ကျင်ဘက်အနေနှင့်၊ သင်သည် ၎င်းတို့ပြုလုပ်သည့်အတိုင်းပင် အလုပ်တွင်လူများ အမှန်တကယ်လုပ်ဆောင်သည့် လုပ်ဆောင်ချက်များကို သင်လုပ်ဆောင်မည်ဖြစ်သည်။ ပါ၀င်တဲ့ အဆင့်တွေကို ဖြတ်ပြီး သီအိုရီကို ရှင်းပြမယ်။

ငါတို့ဘာလုပ်ကြမလဲ?

ကျွန်ုပ်တို့ တိုးတက်လာသည်နှင့်အမျှ၊ ဤစာရင်းကို မှတ်သားရန် အကောင်းဆုံးနည်းလမ်းဖြစ်သည့် ပုံမှန် CI အဆင့်များစာရင်းကို တဖြည်းဖြည်း ဖန်တီးပါမည်။ တစ်နည်းဆိုရသော်၊ စဉ်ဆက်မပြတ်ပေါင်းစည်းမှုကို လုပ်ဆောင်နေစဉ်၊ စဉ်ဆက်မပြတ်ပေါင်းစည်းမှုပြုလုပ်နေစဉ် developer များလုပ်ဆောင်သည့် လုပ်ဆောင်ချက်များစာရင်းကို ဖန်တီးပါမည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ CI လုပ်ငန်းစဉ်ကို အစစ်အမှန်နှင့် ပိုမိုနီးစပ်စေရန်အတွက် ရိုးရှင်းသော စစ်ဆေးမှုများကိုလည်း အသုံးပြုပါမည်။

ဤ GIF သည် သင်တန်းကာလတစ်လျှောက် သင်လုပ်ဆောင်လာသည်နှင့်အမျှ သင့်သိုလှောင်ရာရှိ ကတိက၀တ်များကို ဇယားကွက်ဖြင့်ပြသသည်။ သင်တွေ့မြင်နိုင်သည်အတိုင်း၊ ဤနေရာတွင်ရှုပ်ထွေးသောအရာမရှိပါ၊ အလိုအပ်ဆုံးသာဖြစ်သည်။

သင်သည် အောက်ပါစံနှုန်း CI အခြေအနေများကို ဖြတ်သန်းရလိမ့်မည်-

• အင်္ဂါရပ်တစ်ခုပေါ်တွင်အလုပ်လုပ်;
• အရည်အသွေးကိုသေချာစေရန်အလိုအလျောက်စမ်းသပ်မှုများလျှောက်လွှာ;
• ဦးစားပေးလုပ်ငန်းကို အကောင်အထည်ဖော်ခြင်း၊
• အကိုင်းအခက်များ ပေါင်းစည်းသောအခါ ပဋိပက္ခဖြေရှင်းခြင်း (merge conflict);
• ထုတ်လုပ်မှုပတ်ဝန်းကျင်တွင် အမှားအယွင်းတစ်ခု ဖြစ်ပေါ်သည်။

သင်ဘာသင်ယူမည်နည်း။

အောက်ပါမေးခွန်းများကို သင်ဖြေနိုင်ပါမည်-

• စဉ်ဆက်မပြတ်ပေါင်းစည်းခြင်း (CI) ဆိုသည်မှာ အဘယ်နည်း။
• CI တွင် မည်သည့် အလိုအလျောက် စမ်းသပ်မှု အမျိုးအစားများကို အသုံးပြုကြပြီး မည်သည့် လုပ်ဆောင်ချက်များကို အစပျိုးထားသနည်း ။
• Pull Request တွေက ဘာတွေလဲ၊ ဘယ်အချိန်က လိုအပ်လဲ။
• Test Driven Development (TDD) ဆိုတာ ဘာလဲ၊ CI နဲ့ ဘယ်လို ဆက်စပ်နေလဲ။
• ပြောင်းလဲမှုများကို ပေါင်းစည်းရန် သို့မဟုတ် ပြန်လည်အခြေခံသင့်ပါသလား။
• နောက်ဗားရှင်းတွင် ပြန်လှည့်ပါ သို့မဟုတ် ပြင်ဆင်မလား။

အစပိုင်းမှာတော့ “pull requests” လိုမျိုး အရာတွေကို နေရာတိုင်းကို ဘာသာပြန်ခဲ့ပေမယ့် ရလဒ်အနေနဲ့ တစ်ချို့နေရာတွေမှာ အင်္ဂလိပ်လို စကားစုတွေကို ပြန်ရေးဖို့ ဆုံးဖြတ်ခဲ့ပါတယ်။ တစ်ခါတရံမှာ လူတွေက အလုပ်မှာ တကယ်သုံးတဲ့ အံ့ဖွယ်ကြိယာ “commit” လိုမျိုး “ပရိုဂရမ်မာ surzhik” ကို သုံးပါတယ်။

စဉ်ဆက်မပြတ်ပေါင်းစည်းခြင်းဆိုတာဘာလဲ။

စဉ်ဆက်မပြတ် ပေါင်းစည်းမှုသို့မဟုတ် CI သည် အဖွဲ့၀င်တစ်ဦးစီသည် ၎င်းတို့၏ကုဒ်ကို ဘုံသိုလှောင်ရာသို့ အနည်းဆုံး တစ်နေ့တစ်ကြိမ် ပေါင်းစည်းပေးသည့် နည်းပညာဆိုင်ရာ အလေ့အကျင့်တစ်ခုဖြစ်ပြီး ရရှိလာသောကုဒ်ကို အနည်းဆုံး အမှားအယွင်းမရှိဘဲ တည်ဆောက်ရမည်ဖြစ်သည်။

ဤအသုံးအနှုန်းနှင့်ပတ်သက်၍ သဘောထားကွဲလွဲမှုများရှိသည်။

ငြင်းခုံခြင်း၏အချက်မှာ ပေါင်းစည်းခြင်း၏ အကြိမ်ရေဖြစ်သည်။ အချို့က တစ်နေ့လျှင် တစ်ကြိမ်သာ ကုဒ်ကို ပေါင်းစပ်ခြင်းသည် အမှန်တကယ် စဉ်ဆက်မပြတ် ပေါင်းစပ်ရန် မလုံလောက်ကြောင်း ငြင်းခုံကြသည်။ နံနက်ခင်းတွင် ကုဒ်အသစ်များယူကာ ညနေတစ်ကြိမ် ပေါင်းစပ်ထားသည့် အဖွဲ့တစ်ဖွဲ့၏ ဥပမာကို ပေးထားပါသည်။ ဤသည်မှာ ကျိုးကြောင်းဆီလျော်သော ကန့်ကွက်မှုဖြစ်သော်လည်း၊ တစ်နေ့လျှင် တစ်ကြိမ် အဓိပ္ပါယ်ဖွင့်ဆိုချက်သည် ကျိုးကြောင်းဆီလျော်စွာ လက်တွေ့ကျကျ၊ တိကျပြီး အရွယ်အစားအမျိုးမျိုးရှိသော အသင်းများအတွက် သင့်လျော်သည်ဟု ယေဘူယျအားဖြင့် ယုံကြည်ကြသည်။

နောက်ထပ်ကန့်ကွက်ချက်မှာ C++ သည် ဖွံ့ဖြိုးတိုးတက်မှုတွင်အသုံးပြုသည့်တစ်ခုတည်းသောဘာသာစကားမဟုတ်တော့ဘဲ အမှားအယွင်းကင်းသောစုဝေးမှုကိုလိုအပ်ကြောင်းအတည်ပြုရန်နည်းလမ်းမှာ အားနည်းပါသည်။ အချို့သော စမ်းသပ်မှုများ (ဥပမာ၊ စက်တွင်း၌ လုပ်ဆောင်ခဲ့သော ယူနစ်စမ်းသပ်မှုများ) ကိုလည်း အောင်မြင်စွာ ပြီးမြောက်ရပါမည်။ လောလောဆယ်တွင်၊ အသိုက်အဝန်းသည် ၎င်းကို လိုအပ်ချက်တစ်ခုအဖြစ် ပြုလုပ်ရန် ဦးတည်လုပ်ဆောင်နေပြီး နောင်တွင် "build + unit tests" သည် မဖြစ်သေးပါက သာမာန်အလေ့အကျင့် ဖြစ်လာနိုင်မည်ဖြစ်သည်။

စဉ်ဆက်မပြတ် ပေါင်းစည်းမှု ကနေကွဲပြားခြားနားသော စဉ်ဆက်မပြတ်ပေးပို့ခြင်း။ (ဆက်တိုက်ပေးပို့ခြင်း၊ CD) ပေါင်းစည်းမှုစက်ဝန်းတစ်ခုစီပြီးနောက် ထုတ်ဝေမည့် ကိုယ်စားလှယ်လောင်း မလိုအပ်ပါ။

သင်တန်းတစ်လျှောက် ကျွန်ုပ်တို့အသုံးပြုမည့် အဆင့်များစာရင်း

1. နောက်ဆုံးကုဒ်ကို ဆွဲယူပါ။ အခက်ကနေ ဖန်တီးပါ။ master. စတင်လုပ်ဆောင်ပါ။
2. သင်၏ဌာနခွဲအသစ်တွင် ကတိကဝတ်များဖန်တီးပါ။ ပြည်တွင်းမှာ တည်ဆောက်ပြီး စမ်းသပ်ပါ။ Pass တ? နောက်တစ်ဆင့်ကို သွားပါ။ ကျရှုံးလား? အမှားများ သို့မဟုတ် စမ်းသပ်မှုများကို ပြင်ဆင်ပြီး ထပ်စမ်းကြည့်ပါ။
3. သင့်အဝေးထိန်းဌာန သို့မဟုတ် အဝေးထိန်းဌာနခွဲသို့ တွန်းပါ။
4. ဆွဲထုတ်ရန် တောင်းဆိုချက်ကို ဖန်တီးပါ။ အပြောင်းအလဲများကို ဆွေးနွေးပါ၊ ဆက်လက်ဆွေးနွေးခြင်းဖြင့် ကတိကဝတ်များ ထပ်ထည့်ပါ။ အင်္ဂါရပ်ဌာနခွဲတွင် စာမေးပွဲများကို အောင်မြင်အောင်လုပ်ပါ။
5. ပေါင်းစည်းခြင်း/ပြန်လည်အခြေချခြင်းသည် မာစတာထံမှ ကတိပြုသည်။ ပေါင်းစည်းမှုရလဒ်အပေါ် စမ်းသပ်မှုများ အောင်မြင်ပါစေ။
6. အင်္ဂါရပ်ဌာနခွဲမှ ထုတ်လုပ်မှုအထိ အသုံးချပါ။
7. အချိန်အတိုင်းအတာတစ်ခုအထိ ထုတ်လုပ်မှုတွင် အရာအားလုံးကောင်းမွန်ပါက၊ အပြောင်းအလဲများကို ကျွမ်းကျင်ပိုင်နိုင်စွာ ပေါင်းစည်းလိုက်ပါ။

️ပြင်ဆင်ခြင်း။

သင့်တွင် မှန်ကန်သောဆော့ဖ်ဝဲလ်ရှိရန် သေချာပါစေ။

ဒီသင်တန်းတက်ဖို့တော့ လိုပါလိမ့်မယ်။ Node.js и Git client.

သင်သည်မည်သည့် Git ကလိုင်းယင့်ကိုမဆိုအသုံးပြုနိုင်သည်၊ သို့သော်ကျွန်ုပ်သည် command line အတွက်သာအမိန့်ပေးမည်ဖြစ်သည်။

အမိန့်ပေးစာကြောင်းကို ပံ့ပိုးပေးသည့် Git ကလိုင်းယင့် ထည့်သွင်းထားကြောင်း သေချာပါစေ။

သင့်တွင် command line ကိုပံ့ပိုးပေးသည့် Git client မရှိသေးပါက၊ တပ်ဆင်မှုလမ်းညွှန်ချက်များကို သင်ရှာတွေ့နိုင်ပါသည်။ ဒီမှာ.

သိုလှောင်ခန်းကိုပြင်ဆင်ပါ။

ကိုယ်ပိုင်မိတ္တူ (လမ်းဆုံလမ်းခွ) ဖန်တီးရန် လိုအပ်ပါမည်။ သင်တန်းအတွက် code ပါသော template repository GitHub တွင် ဤကိုယ်ရေးကိုယ်တာ မိတ္တူကို ခေါ်ရန် သဘောတူလိုက်ကြပါစို့ သင်တန်းသိုလှောင်ခန်း.

ပြီးပြီလား? မူရင်းဆက်တင်များကို သင်မပြောင်းရသေးပါက၊ သင်၏သင်တန်း သိုလှောင်ရာနေရာကို အများဆုံးခေါ်သည်။ continuous-integration-team-scenarios-students၎င်းသည် သင့် GitHub အကောင့်တွင် တည်ရှိပြီး URL သည် ဤပုံစံအတိုင်းဖြစ်သည်။

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

ဒီလိပ်စာကို ရိုးရိုးရှင်းရှင်းပဲ ခေါ်မယ်။ <URL репозитория>.

ထောင့်ကွင်း လိုမျိုး <тут> ထိုသို့သော စကားရပ်တစ်ခုကို သင့်လျော်သောတန်ဖိုးဖြင့် အစားထိုးရမည်ဟု ဆိုလိုသည်။

သေချာအောင်လုပ်ပါ။ GitHub လုပ်ဆောင်ချက်များ ဤသင်တန်းကို သိမ်းဆည်းရန် ပါဝင်သည်။ ၎င်းတို့ကို ဖွင့်မထားပါက၊ GitHub အင်တာဖေ့စ်ရှိ လုပ်ဆောင်ချက်များကို နှိပ်ခြင်းဖြင့် သင်ရောက်ရှိနိုင်သည့် စာမျက်နှာ၏အလယ်ရှိ ကြီးမားသောခလုတ်ကို နှိပ်ခြင်းဖြင့် ၎င်းတို့ကို ဖွင့်ပါ။

GitHub လုပ်ဆောင်ချက်များကို ဖွင့်မထားပါက ကျွန်ုပ်၏ညွှန်ကြားချက်များအတိုင်း သင်တန်းကို ပြီးမြောက်နိုင်မည်မဟုတ်ပါ။

ဤနေရာတွင်ကျွန်ုပ်တို့ရေးဖွဲ့နေသောစာရင်း၏လက်ရှိအခြေအနေကိုကြည့်ရန် GitHub ၏ Markdown ကိုပြန်ဆိုရန် သင်အမြဲအသုံးပြုနိုင်သည်

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>

အကယ်၍ သင်သည် ရလဒ်ကို ကျေနပ်ပါက၊ တစ်ချိန်ချိန်တွင် သင်သည် သင်၏ repository ဗားရှင်းကို အဝေးထိန်းနေရာသို့ ထုတ်ဝေရန် လိုအပ်ပါလိမ့်မည်။ သင်ဤအရာကိုလုပ်ဆောင်သည့်အခါ အဝေးထိန်းဌာနခွဲကို ပြတ်သားစွာသတ်မှတ်ရန် မမေ့ပါနှင့်။

git push --force origin master

အသုံးပြုကြောင်း သတိပြုပါ။ git push --force. သင်ဤအရာကိုမကြာခဏပြုလုပ်လိုမည်မဟုတ်သော်လည်း၊ ထို့အပြင်သူလုပ်ဆောင်နေသည်ကိုနားလည်သော repository အသုံးပြုသူတစ်ဦးနှင့်အတူဤနေရာတွင်အလွန်တိကျသောအခြေအနေတစ်ခုရှိသည်။

စတင်အလုပ်လုပ်သည်။

ကျွန်ုပ်တို့၏ CI အဆင့်များစာရင်းကို စတင်ပြုစုကြပါစို့။ ပုံမှန်အားဖြင့် သင်သည် အဝေးထိန်းသိုလှောင်မှုမှ ကုဒ်၏နောက်ဆုံးဗားရှင်းကို စစ်ကြည့်ခြင်းဖြင့် ဤအဆင့်ကို စတင်ရမည်ဖြစ်ပြီး၊ သို့သော် ကျွန်ုပ်တို့တွင် ဒေသဆိုင်ရာ သိမ်းဆည်းမှုတစ်ခု မရှိသေးသောကြောင့် ၎င်းအစား ၎င်းကို အဝေးထိန်းစနစ်မှ ကူးယူခြင်းဖြစ်သည်။

️ လုပ်ငန်းဆောင်တာ- ဒေသဆိုင်ရာသိုလှောင်မှုအား အပ်ဒိတ်လုပ်ပါ၊ ဘဏ်ခွဲတစ်ခု ဖန်တီးပါ။ master၊ အလုပ်စလုပ်ပါ။

1. သင်တန်းနေရာမှ ကူးယူပါ။ <URL репозитория>.
2. ပြေးပါ npm install သင်တန်းသိုလှောင်မှုလမ်းညွှန်တွင်၊ စမ်းသပ်မှုများလုပ်ဆောင်ရန် ကျွန်ုပ်တို့အသုံးပြုသည့် Jest ကို ထည့်သွင်းရန် လိုအပ်ပါသည်။
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 ပိုက်လိုင်းရှိ commit တွင်
• နှေးကွေးသောအစိတ်အပိုင်းနှင့် ပေါင်းစပ်စစ်ဆေးမှုများ - CI ပိုက်လိုင်းတွင်
• လုံခြုံရေးစမ်းသပ်ခြင်း၊ ဝန်စမ်းသပ်ခြင်းနှင့် အခြားအချိန်ကုန်သော သို့မဟုတ် စျေးကြီးသောစမ်းသပ်မှုများ - CI/CD ပိုက်လိုင်းများတွင်၊ ဥပမာအားဖြင့်၊ တည်ဆောက်မှု၏အချို့သောမုဒ်များ/အဆင့်များ/ပိုက်လိုင်းများတွင်သာ၊ ဥပမာ၊ ထုတ်ဝေသူအား ပြင်ဆင်သည့်အခါ သို့မဟုတ် ကိုယ်တိုင်လုပ်ဆောင်သည့်အခါတွင်သာ။

️တာဝန်

Command ကိုအသုံးပြု၍ စမ်းသပ်မှုများကို ကိုယ်တိုင်လုပ်ဆောင်ရန် အကြံပြုအပ်ပါသည်။ npm test. ထို့နောက် ကျွန်ုပ်တို့၏စမ်းသပ်မှုများကို commit တွင်လုပ်ဆောင်ရန် git hook ကိုထည့်လိုက်ကြပါစို့။ တစ်ခုရှိတာက Git hooks တွေကို repository ရဲ့ တစ်စိတ်တစ်ပိုင်းလို့ မယူဆတဲ့အတွက် ကျန်တဲ့ course ပစ္စည်းတွေနဲ့အတူ GitHub ကနေ cloned လုပ်လို့မရပါဘူး။ Hook ကို install လုပ်ဖို့သင် run ဖို့လိုအပ်ပါတယ်။ install_hook.sh သို့မဟုတ် ဖိုင်ကို ကော်ပီကူးပါ။ repo/hooks/pre-commit local directory သို့ .git/hooks/.
သင်ကတိကဝတ်ပြုသောအခါ၊ သင်သည်စမ်းသပ်မှုများလုပ်ဆောင်နေသည်ကိုတွေ့မြင်ရပြီးအချို့သောသော့ချက်စကားလုံးများသည်စာရင်းတွင်ရှိမရှိစစ်ဆေးရန်သူတို့စစ်ဆေးသည်။

1. command ကို run ခြင်းဖြင့် စမ်းသပ်မှုများကို ကိုယ်တိုင်လုပ်ဆောင်ပါ။ npm test သင်၏သင်တန်းသိုလှောင်မှုဖိုင်တွဲတွင်။ စာမေးပွဲများ ပြီးသွားကြောင်း စစ်ဆေးပါ။
2. လည်ပတ်ခြင်းဖြင့် ကွန်မစ်ချိတ် (pre-commit hook) ကို သတ်မှတ်ပါ။ 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"

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

အဝေးထိန်းဌာန သို့မဟုတ် အဝေးထိန်းဌာနသို့ ကုဒ်ကို လွှင့်တင်ပါ။

၎င်းတို့သည် ပြည်တွင်းတွင် အလုပ်လုပ်ပြီးသည်နှင့်၊ developer များသည် ၎င်းတို့၏ကုဒ်ကို အများသူငှာအသုံးပြုနိုင်အောင် ပြုလုပ်လေ့ရှိပြီး ၎င်းသည် နောက်ဆုံးတွင် အများသူငှာနှင့် ပေါင်းစည်းနိုင်မည်ဖြစ်သည်။ GitHub ဖြင့်၊ ၎င်းသည် သိုလှောင်မှု၏ ကိုယ်ရေးကိုယ်တာ မိတ္တူ (သို့) ကိုယ်ရေးကိုယ်တာဌာနခွဲသို့ ထုတ်ဝေခြင်းဖြင့် ၎င်းကို ပုံမှန်အားဖြင့် အောင်မြင်နိုင်သည်။

• forks ဖြင့်၊ developer သည် အဝေးထိန်း မျှဝေထားသော သိုလှောင်ခန်းကို ဖန်တီးပြီး ခက်ရင်းဟုလည်းသိကြသော ကိုယ်ပိုင်အဝေးထိန်းမိတ္တူတစ်ခုကို ဖန်တီးသည်။ ထို့နောက် ၎င်းသည် စက်တွင်းနှင့်အလုပ်လုပ်ရန် ဤကိုယ်ရေးကိုယ်တာသိုလှောင်မှုကို ပုံတူပွားသည်။ အလုပ်ပြီးမြောက်ပြီး ကတိကဝတ်များ ပြီးသောအခါ၊ သူသည် ၎င်းတို့ကို အခြားသူများ ရရှိနိုင်သည့် နေရာတွင် ထားရှိကာ ဘုံသိုလှောင်ရာသို့ ပေါင်းစည်းနိုင်သည်။ ဤချဉ်းကပ်နည်းကို GitHub ရှိ open source ပရောဂျက်များတွင် အသုံးများသည်။ ၎င်းကို ကျွန်ုပ်၏အဆင့်မြင့်သင်တန်း [Team Work and CI with Git] (http://devops.redpill.solutions/).
• အခြားနည်းလမ်းမှာ အဝေးထိန်းသိုလှောင်ရုံတစ်ခုတည်းကိုသာ အသုံးပြုပြီး ဌာနခွဲကိုသာ ရေတွက်ရန်ဖြစ်သည်။ master shared repository "ကာကွယ်ထားသည်"။ ဤအခြေအနေတွင်၊ developer တစ်ဦးချင်းစီသည် ၎င်းတို့၏ကုဒ်ကို အဝေးထိန်းသိုလှောင်မှု၏ အကိုင်းအခက်များသို့ လွှင့်တင်ကာ အခြားသူများအနေဖြင့် ဤကုဒ်ကို ကြည့်ရှုနိုင်စေရန်၊ အရာအားလုံး အဆင်ပြေပါက ၎င်းနှင့် ပေါင်းစည်းလိုက်ပါ။ master shared repository ။

ဤအထူးသင်တန်းတွင်၊ ကျွန်ုပ်တို့သည် အကိုင်းအခက်များကို အသုံးပြုသည့် အလုပ်အသွားအလာကို အသုံးပြုပါမည်။

ကျွန်ုပ်တို့၏ကုဒ်ကိုထုတ်ဝေကြပါစို့။

️တာဝန်

• သင့်လုပ်ငန်းခွင်ဌာနခွဲနှင့် နာမည်တူရှိသော အဝေးထိန်းဌာနခွဲသို့ ပြောင်းလဲမှုများကို ထုတ်ဝေပါ။

ပညတ်တော်တို့ကို

git push --set-upstream origin feature

ဆွဲထုတ်ရန် တောင်းဆိုချက်ကို ဖန်တီးပါ။

ခေါင်းစဉ်တစ်ခုဖြင့် ဆွဲယူတောင်းဆိုမှုကို ဖန်တီးပါ။ အဆင့်ဆင့်သုံးသပ်ချက်... တပ်ဆင်ပါ။ feature "ခေါင်းကိုင်း" နှင့်တူသည်။ master "အခြေခံအကိုင်းအခက်" ကဲ့သို့။

ထည့်သွင်းပြီးကြောင်း သေချာပါစေ။ master သူ့၌။ repository ကိုလမ်းခွဲပါ။ "အခြေခံဌာနခွဲ" အနေဖြင့် သင်တန်းပစ္စည်းများသိုလှောင်ရာသို့ အပြောင်းအလဲများအတွက် တောင်းဆိုမှုများကို ကျွန်ုပ်တုံ့ပြန်မည်မဟုတ်ပါ။

GitHub ဘာသာစကားတွင်၊ "အခြေခံအကိုင်းအခက်" သည် သင့်လုပ်ငန်းကိုအခြေခံသည့်ဌာနခွဲဖြစ်ပြီး "ခေါင်းကိုင်း" သည် အဆိုပြုထားသောပြောင်းလဲမှုများပါရှိသောဌာနခွဲဖြစ်သည်။

အပြောင်းအလဲများကို ဆွေးနွေးပါ၊ ဆက်လက်ဆွေးနွေးသည်နှင့်အမျှ ကတိကဝတ်အသစ်များထည့်ပါ။

တောင်းဆိုချက် (PR) ကို ဆွဲထုတ်ပါ

တောင်းဆိုချက် (PR) ကို ဆွဲထုတ်ပါ ဆွေးနွေးခြင်းနှင့် စာရွက်စာတမ်းကုဒ်အပြင် ကုဒ်ပြန်လည်သုံးသပ်ခြင်းလုပ်ဆောင်ရန် နည်းလမ်းတစ်ခုဖြစ်သည်။ Pull Requests များကို တစ်ဦးချင်းပြောင်းလဲမှုများအား ခြုံငုံကုဒ်သို့ ပေါင်းစပ်ထည့်သွင်းခြင်း၏ ယေဘုယျနည်းလမ်းကို အမည်ပေးထားသည်။ ပုံမှန်အားဖြင့်၊ လူတစ်ဦးသည် ပရောဂျက်၏ အဝေးထိန်းတရားဝင်သိုလှောင်မှုကို ပုံတူပွားပြီး ကုဒ်ကို စက်တွင်းတွင် လုပ်ဆောင်သည်။ ၎င်းနောက်၊ သူသည် ၎င်း၏ကိုယ်ပိုင်အဝေးထိန်းနေရာ၌ ကုဒ်ကို ထားရှိကာ တရားဝင်သိုလှောင်မှုတာဝန်ရှိသူများအား ကောက်ယူရန် တောင်းဆိုသည်(ဆွဲပါ၎င်းတို့ ပြန်လည်သုံးသပ်ပြီး ပေါင်းစည်းနိုင်သည့် ကုဒ်ကို ၎င်းတို့၏ ဒေသဆိုင်ရာ သိုလှောင်နေရာများတွင် )အဖှဲ့ပေါငျး) သူ့ ဤသဘောတရားကို အခြားအမည်များဖြင့် လူသိများသည် ဥပမာ၊ ပေါင်းစည်းရန် တောင်းဆိုချက်.

သင်သည် GitHub သို့မဟုတ် အလားတူပလပ်ဖောင်းများ၏ ဆွဲယူတောင်းဆိုမှုအင်္ဂါရပ်ကို အမှန်တကယ်အသုံးပြုရန် မလိုအပ်ပါ။ ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့များသည် မျက်နှာချင်းဆိုင်ဆက်သွယ်မှု၊ အသံခေါ်ဆိုမှုများ သို့မဟုတ် အီးမေးလ်များအပါအဝင် အခြားဆက်သွယ်ရေးနည်းလမ်းများကို အသုံးပြုနိုင်သော်လည်း ဖိုရမ်ပုံစံဆွဲယူတောင်းဆိုမှုများကို အသုံးပြုရသည့် အကြောင်းရင်းများစွာရှိနေသေးသည်။ ဤတွင် ၎င်းတို့ထဲမှ အချို့မှာ-

• သတ်မှတ်ထားသော ကုဒ်ပြောင်းလဲမှုများနှင့် ပတ်သက်သော စနစ်တကျ ဆွေးနွေးမှုများ၊
• autotesters နှင့် ရွယ်တူများ နှစ်ဦးစလုံးထံမှ အလုပ်တွင် တိုးတက်မှုအပေါ် တုံ့ပြန်ချက်များကို ကြည့်ရှုရန် နေရာတစ်ခုအဖြစ်၊
• ကုဒ်ပြန်လည်သုံးသပ်ခြင်းတရားဝင်ဖြစ်ခြင်း၊
• သို့မှသာ ဤသို့မဟုတ် ထိုကုဒ်၏နောက်ကွယ်ရှိ အကြောင်းရင်းများနှင့် ထည့်သွင်းစဉ်းစားချက်များကို သင်ရှာဖွေနိုင်မည်ဖြစ်သည်။

ပုံမှန်အားဖြင့် သင်သည် တစ်စုံတစ်ခုကို ဆွေးနွေးရန် သို့မဟုတ် တုံ့ပြန်ချက်ရယူရန် လိုအပ်သည့်အခါ ဆွဲယူတောင်းဆိုမှုကို ဖန်တီးသည်။ ဥပမာအားဖြင့်၊ သင်သည် နည်းလမ်းတစ်ခုထက်ပို၍ အကောင်အထည်ဖော်နိုင်သည့် အင်္ဂါရပ်တစ်ခုကို လုပ်ဆောင်နေပါက၊ သင်၏အကြံဉာဏ်များကို မျှဝေရန်နှင့် သင်၏အစီအစဉ်များကို ပူးပေါင်းလုပ်ဆောင်သူများနှင့် ဆွေးနွေးရန် ကုဒ်၏ပထမစာကြောင်းကို မရေးမီ ဆွဲယူတောင်းဆိုမှုကို ဖန်တီးနိုင်သည်။ အလုပ်က ပိုရိုးရှင်းပါက၊ တစ်စုံတစ်ခုပြီးပြီ၊ ကတိကဝတ်ပြုပြီး ဆွေးနွေးနိုင်သည့်အခါ ဆွဲငင်တောင်းဆိုမှုကို ဖွင့်ပေးသည်။ အချို့သောအခြေအနေများတွင် သင်သည် အရည်အသွေးထိန်းချုပ်မှုဆိုင်ရာအကြောင်းပြချက်များအတွက်သာ PR ကိုဖွင့်လိုနိုင်သည်- အလိုအလျောက်စမ်းသပ်မှုများကိုလုပ်ဆောင်ရန် သို့မဟုတ် ကုဒ်ပြန်လည်သုံးသပ်ခြင်းစတင်ရန်။ သင်ဆုံးဖြတ်သမျှ၊ သင့်ဆွဲတင်တောင်းဆိုမှုတွင် သင်အတည်ပြုလိုသည့်လူများကို @ mention ခေါ်ရန် မမေ့ပါနှင့်။

ပုံမှန်အားဖြင့် PR တစ်ခုဖန်တီးသောအခါတွင် သင်သည် အောက်ပါတို့ကို လုပ်ဆောင်သည်။

• ပြောင်းလဲရန် အဆိုပြုသည့်အရာနှင့် မည်သည့်နေရာတွင် ရှိသည်ကို ဖော်ပြပါ။
• အပြောင်းအလဲများ၏ ရည်ရွယ်ချက်ကို ရှင်းပြသည့် ဖော်ပြချက်တစ်ခုရေးပါ။ သင်လိုချင်နိုင်သည်-
  • သက်ဆိုင်ရာ #bugs နှင့် commit နံပါတ်များကဲ့သို့သော ဆက်စပ်အကြောင်းအရာကို နားလည်ရန်အတွက် အသုံးဝင်သော အရာတစ်ခုခုကို ကုဒ်မှ မသိသာသော အရေးကြီးသောအရာကို ထည့်ပါ။
  • သင်စတင်လုပ်ကိုင်လိုသည့် မည်သူမဆို @ mention ခေါ်ပါ သို့မဟုတ် နောက်မှ မှတ်ချက်များတွင် ၎င်းတို့ကို @ဖော်ပြနိုင်ပါသည်။
  • လုပ်ဖော်ကိုင်ဖက်များအား တစ်စုံတစ်ခုအကူအညီတောင်းရန် သို့မဟုတ် သီးခြားတစ်ခုခုကို စစ်ဆေးပါ။

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 သူ့၌။ repository ကိုလမ်းခွဲပါ။ "အခြေခံဌာနခွဲ" အနေဖြင့် သင်တန်းပစ္စည်းများသိုလှောင်ရာသို့ အပြောင်းအလဲများအတွက် တောင်းဆိုမှုများကို ကျွန်ုပ်တုံ့ပြန်မည်မဟုတ်ပါ။

ဤအရာသည် သင်၏သိုလှောင်မှုပုံစံဖြစ်သင့်သည်။

ပညတ်တော်တို့ကို

# Переключитесь на ветку 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. "Merge pull request" ကိုနှိပ်ပါ။
3. "Confirm Merge" ကိုနှိပ်ပါ။
4. "အကိုင်းအခက်ဖျက်မည်" ကိုနှိပ်ပါ၊ ကျွန်ုပ်တို့ ၎င်းကိုမလိုအပ်တော့ပါ။

ဤသည်မှာ ပေါင်းစည်းပြီးနောက် ကတိပြုမှု၏ ပုံကြမ်းဖြစ်သည်။

️ ဆက်လက်လုပ်ဆောင်ပြီး စာမေးပွဲများထည့်ပါ။

ဆွဲတင်တောင်းဆိုမှုတွင် ပူးပေါင်းဆောင်ရွက်ခြင်းသည် အပိုအလုပ်များကို ဖြစ်ပေါ်စေတတ်သည်။ ၎င်းသည် အများအားဖြင့် ကုဒ်ပြန်လည်သုံးသပ်ခြင်း သို့မဟုတ် ဆွေးနွေးခြင်း၏ရလဒ်ဖြစ်သော်လည်း ကျွန်ုပ်တို့၏သင်တန်းတွင် ကျွန်ုပ်တို့၏ CI အဆင့်များစာရင်းတွင် အကြောင်းအရာအသစ်များကို ထည့်သွင်းခြင်းဖြင့် ၎င်းကို နမူနာယူသွားမည်ဖြစ်ပါသည်။

စဉ်ဆက်မပြတ်ပေါင်းစည်းမှုသည် ပုံမှန်အားဖြင့် စမ်းသပ်မှုအချို့ပါဝင်ပါသည်။ စမ်းသပ်မှု အကျုံးဝင်မှု လိုအပ်ချက်များ ကွဲပြားပြီး "ပံ့ပိုးကူညီမှု လမ်းညွှန်ချက်များ" ဟုခေါ်သည့် စာရွက်စာတမ်းတစ်ခုတွင် အများအားဖြင့် တွေ့ရှိရသည်။ ကျွန်ုပ်တို့သည် ၎င်းကို ရိုးရိုးရှင်းရှင်းထားရှိပြီး ကျွန်ုပ်တို့၏စစ်ဆေးစာရင်းတွင် စာကြောင်းတစ်ခုစီအတွက် စစ်ဆေးမှုတစ်ခုထည့်ပါမည်။

assignments များလုပ်ဆောင်သောအခါ၊ စာမေးပွဲများကို ဦးစွာလုပ်ဆောင်ပါ။ မှန်ကန်စွာတပ်ဆင်လျှင် 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

ပဋိပက္ခကို ပေါင်းစည်းပါ။

Change Request သို့သွားပါ။ အဆင့်ဆင့်သုံးသပ်ချက်.

ကျွန်ုပ်တို့သည် အမှားအယွင်းတစ်စုံတစ်ရာမလုပ်ခဲ့ဘဲ ကျွန်ုပ်တို့၏ကုဒ်အတွက် စမ်းသပ်မှုများ အောင်မြင်ခဲ့သော်လည်း၊ ကျွန်ုပ်တို့သည် ဌာနခွဲကို ပေါင်းစည်းခြင်းမပြုနိုင်သေးပါ။ feature и master. တခြား ကြိုးကြောင့်လား။ bugfix နှင့် ပေါင်းစပ်ခဲ့သည်။ master ဒီ PR နဲ့ ပတ်သက်ပြီး လုပ်နေတုန်း။
ဝေးလံခေါင်သီသော အခက်အလက် အခြေအနေကို ဖန်တီးသည်။ master ကျွန်ုပ်တို့ ဌာနခွဲကို အခြေခံထားသော ဗားရှင်းထက် ပိုသစ်သော ဗားရှင်းတစ်ခုရှိသည်။ feature. အဲ့ဒါကြောင့် HEAD ကို ပြန်ကြည့်ရုံနဲ့ မရပါဘူး။ master thread ၏အဆုံးအထိ feature. ဤအခြေအနေတွင်၊ ကျွန်ုပ်တို့သည် ကတိပြုချက်များကို ပေါင်းစည်းရန် သို့မဟုတ် ကျင့်သုံးရန် လိုအပ်သည်။ feature ပြန်လည်အခြေစိုက်ပါ။ master. ပဋိပက္ခများ မရှိပါက GitHub သည် အမှန်တကယ် အလိုအလျောက် ပေါင်းစပ်မှုများကို လုပ်ဆောင်နိုင်သည်။ ကံမကောင်းစွာပဲ၊ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ဘဏ်ခွဲနှစ်ခုစလုံးသည် ဖိုင်တွင် အပြိုင်အဆိုင်ပြောင်းလဲမှုများရှိသည်။ ci.md. ဤအခြေအနေကို ပေါင်းစပ်ပဋိပက္ခဟု လူသိများပြီး ၎င်းကို ကျွန်ုပ်တို့ကိုယ်တိုင် ဖြေရှင်းရန် လိုအပ်ပါသည်။

ပေါင်းစည်းခြင်း သို့မဟုတ် ပြန်လည်အခြေစိုက်ပါ။

အဖှဲ့ပေါငျး

• နောက်ထပ်ပေါင်းစည်းမှုတစ်ခု ဖန်တီးပြီး အလုပ်မှတ်တမ်းကို သိမ်းဆည်းပါ။
  • ၎င်းတို့၏မူလအချိန်တံဆိပ်နှင့် စာရေးဆရာများဖြင့် ဘဏ်ခွဲများ၏ မူလကတိကဝတ်များကို ထိန်းသိမ်းပါ။
  • ပြောင်းလဲမှု တောင်းဆိုချက် ဆွေးနွေးမှုများတွင် ၎င်းတို့ထံ ကတိကဝတ်များနှင့် လင့်ခ်များ၏ SHA ကို သိမ်းဆည်းသည်။
• တစ်ကြိမ်တည်း ပဋိပက္ခဖြေရှင်းရန် လိုအပ်သည်။
• ဇာတ်လမ်းကို မျဉ်းမဖြောင့်အောင် လုပ်သည်။
  • အကိုင်းအခက် အများအပြား (IDE ကေဘယ်လ်ကို အမှတ်ရနေသည်) ကြောင့် ဇာတ်လမ်းကို ဖတ်ရန် ခက်ခဲနိုင်သည်။
  • အလိုအလျောက် အမှားရှာပြင်ခြင်းကို ပိုခက်ခဲစေသည်၊ ဥပမာ၊ git bisect အသုံးဝင်မှုနည်းသည် - ပေါင်းစည်းမှုကိုသာ တွေ့ရလိမ့်မည်။

ပြန်ယူ

• ပြန်လည်ပြသမှုများသည် အခြေခံအကိုင်းအခက်၏ထိပ်ရှိ လက်ရှိအကိုင်းအခက်မှ တစ်ခုပြီးတစ်ခုလုပ်ဆောင်သည်။
  • SHAs အသစ်များနှင့် ကတိကဝတ်အသစ်များကို ထုတ်ပေးပြီး GitHub ရှိ ကတိကဝတ်များသည် မူရင်းဆွဲတင်တောင်းဆိုမှုများနှင့် ကိုက်ညီသော်လည်း သက်ဆိုင်ရာ မှတ်ချက်များ မဟုတ်ပါ။
  • ကတိကဝတ်များကို လုပ်ငန်းစဉ်တွင် ပြန်လည်ပေါင်းစည်းနိုင်ပြီး ပြင်ဆင်နိုင်သည်၊ သို့မဟုတ် တစ်ခုအဖြစ်ပင် ပေါင်းစည်းနိုင်သည်။
• ပဋိပက္ခများစွာကို ဖြေရှင်းရန် လိုအပ်နိုင်သည်။
• linear story ကို ထိန်းသိမ်းထားနိုင်ရမယ်။
  • အကြောင်းပြချက်မရှိဘဲ ရှည်လျားလွန်းနေသ၍ ဇာတ်လမ်းသည် ဖတ်ရပိုလွယ်နိုင်သည်။
  • အလိုအလျောက် အမှားရှာပြင်ခြင်းနှင့် ပြဿနာဖြေရှင်းခြင်းသည် အနည်းငယ်ပိုမိုလွယ်ကူသည်- ဖြစ်နိုင်သည်။ git bisectအလိုအလျောက်ပြန်လှည့်မှုများကို ပိုမိုရှင်းလင်းစေပြီး ပိုမိုခန့်မှန်းနိုင်စေနိုင်သည်။
• အလံတစ်ခုဖြင့် ရွှေ့ပြောင်းထားသော ကတိကဝတ်များဖြင့် ဌာနခွဲတစ်ခုကို ထုတ်ဝေရန် လိုအပ်သည်။ --force Pull Requests နဲ့ သုံးတဲ့အခါ။

ပုံမှန်အားဖြင့်၊ အသင်းများသည် အပြောင်းအလဲများကို ပေါင်းစည်းရန် လိုအပ်သည့်အခါ တူညီသောဗျူဟာကို အမြဲအသုံးပြုရန် သဘောတူကြသည်။ ၎င်းသည် "သန့်စင်သော" ပေါင်းစည်းခြင်း သို့မဟုတ် ထိပ်မှ "သန့်စင်သော" ကတိပြုခြင်း သို့မဟုတ် ထိပ်မှအပြန်အလှန်တုံ့ပြန်မှုတစ်ခုပြုလုပ်ခြင်းကဲ့သို့သော အကြားရှိအရာတစ်ခု ဖြစ်နိုင်သည်(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. "Merge pull request" ကိုနှိပ်ပါ။
3. "Confirm Merge" ကိုနှိပ်ပါ။
4. ကျွန်ုပ်တို့ ၎င်းကို မလိုအပ်တော့သောကြောင့် "Delete Branch" ကိုနှိပ်ပါ။

ဤအရာသည် ယခုအချိန်တွင် သင်၏သိုလှောင်မှုဖြစ်သည်။

ထုတ်ကုန်အမှား

“စစ်ဆေးမှုသည် အမှားအယွင်းများ ရှိနေကြောင်း ပြသရန် အသုံးပြုသော်လည်း ၎င်းတို့၏ ပျက်ကွက်မှုကို ဘယ်တော့မှ မပြသရန်” ဟုဆိုသည်။ ကျွန်ုပ်တို့တွင် စမ်းသပ်မှုများ ပြုလုပ်ခဲ့ပြီး ၎င်းတို့သည် ကျွန်ုပ်တို့အား အမှားအယွင်းများ မပြသော်လည်း၊ ဆိုးရွားသော ချို့ယွင်းချက်တစ်ခုသည် ထုတ်လုပ်ရေးသို့ ဝင်ရောက်လာသည်။

ဤကဲ့သို့သောအခြေအနေမျိုးတွင်၊ ကျွန်ုပ်တို့ဂရုစိုက်ရန်လိုအပ်သည်-

• ထုတ်လုပ်မှုတွင် အသုံးချသောအရာများ၊
• thread ထဲမှာ code master developer များမှ အလုပ်အသစ်ကို စတင်နိုင်သည့် အမှားတစ်ခုရှိသည်။

နောက်ဗားရှင်းမှာ ပြန်ပြင်သင့်သလား ဒါမှမဟုတ် ပြင်သင့်လား။

နောက်ကြောင်းပြန်လှည့်ခြင်းသည် အမှားပါရှိသော အစောပိုင်းဗားရှင်းကို ထုတ်လုပ်ခြင်းနှင့် ပြန်ပြောင်းခြင်းတွင် လူသိများသော ကောင်းမွန်သောဗားရှင်းကို အသုံးပြုခြင်းလုပ်ငန်းစဉ်ဖြစ်သည်။ "Fixing forward" သည် fix တစ်ခု၏ ထပ်တိုးခြင်း ဖြစ်သည်။ master နှင့် ဗားရှင်းအသစ်ကို တတ်နိုင်သမျှ အမြန်ဆုံး အသုံးချပါ။ API များနှင့် ဒေတာဘေ့စ်အစီအစဉ်များသည် ကုဒ်များကို ထုတ်လုပ်ရန်အတွက် ဖြန့်ကျက်ထားသောကြောင့် ပြောင်းလဲသွားသောကြောင့်၊ စဉ်ဆက်မပြတ်ပေးပို့ခြင်းနှင့် စမ်းသပ်မှုကောင်းမွန်ခြင်းနှင့်အတူ၊ နောက်ဗားရှင်းတွင် ပြုပြင်ခြင်းထက် ပုံမှန်အားဖြင့် ပိုမိုခက်ခဲပြီး အန္တရာယ်များပါသည်။

နောက်ကြောင်းပြန်လှည့်ခြင်းသည် ကျွန်ုပ်တို့၏ကိစ္စတွင် မည်သည့်အန္တရာယ်မှ မဆောင်ထားသောကြောင့်၊ ကျွန်ုပ်တို့အား ခွင့်ပြုပေးသောကြောင့် ဤလမ်းကြောင်းအတိုင်း သွားပါမည်။

• ထုတ်ကုန်ပေါ်ရှိ အမှားအယွင်းကို တတ်နိုင်သမျှ အမြန်ဆုံးပြုပြင်ပါ။
• ကုဒ်လုပ်ပါ။ master အလုပ်သစ်တစ်ခုစတင်ရန် ချက်ချင်းသင့်တော်သည်။

️တာဝန်

1. ဌာနခွဲသို့ပြောင်းပါ။ master ပြည်တွင်း။
2. ဝေးလံခေါင်သီသော repository မှ စက်တွင်းသိုလှောင်မှုကို အပ်ဒိတ်လုပ်ပါ။
3. PR ပေါင်းစည်းမှု commit ကို ပြန်ပြောင်းပါ။ အဆင့်ဆင့်သုံးသပ်ချက် в 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 ပေါင်းစည်းခြင်းကို ပြန်ပြောင်းပြီးနောက် "sneaky bug" ဟူသော စာသား မပါဝင်တော့ပါ။

CI အဆင့်များစာရင်းကို ပြင်ဆင်ပြီး ၎င်းကို မာစတာသို့ ပြန်ပို့ပါ။

ဌာနခွဲ၏ ပေါင်းစည်းခြင်းဆိုင်ရာ ကတိကဝတ်ကို ကျွန်ုပ်တို့ လုံးလုံးလျားလျား ပြန်ပြောင်းလိုက်ပါပြီ။ feature. သတင်းကောင်းကတော့ ကျွန်တော်တို့မှာ အမှားအယွင်းမရှိသေးပါဘူး။ master. သတင်းဆိုးမှာ ကျွန်ုပ်တို့၏ အဖိုးတန် စဉ်ဆက်မပြတ် ပေါင်းစည်းရေး အဆင့်များစာရင်းမှာလည်း မရှိတော့ကြောင်း သိရသည်။ ထို့ကြောင့်၊ အကောင်းဆုံးအားဖြင့်၊ ကျွန်ုပ်တို့သည် commits တွင် fix ကိုအသုံးချရန်လိုအပ်သည်။ feature သူတို့ကို ပြန်ပို့ပါ။ master fix နှင့်အတူ။

ကျွန်ုပ်တို့သည် ပြဿနာကို နည်းလမ်းအမျိုးမျိုးဖြင့် ချဉ်းကပ်နိုင်သည်-

• ပေါင်းစည်းခြင်းကို ဖျက်သော ကတိပြုချက်ကို ပြန်ပြောင်းပါ။ feature с master;
• ယခင် ကတိကဝတ်အတိုင်း ရွှေ့သည်။ feature.

မတူညီသော ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့များသည် ဤကိစ္စရပ်တွင် မတူညီသောချဉ်းကပ်မှုများကို အသုံးပြုသော်လည်း၊ ကျွန်ုပ်တို့သည် အသုံးဝင်သော ကတိကဝတ်များကို သီးခြားဌာနခွဲတစ်ခုသို့ ရွှေ့ကာ ဤဌာနခွဲအသစ်အတွက် သီးခြားဆွဲယူတောင်းဆိုမှုကို ဖန်တီးပါမည်။

️တာဝန်

1. ဟုခေါ်သော ကြိုးကို ဖန်တီးပါ။ feature-fix ၎င်းသို့ပြောင်းပါ။

2. ယခင်ဌာနခွဲမှ ကတိပြုမှုအားလုံးကို ရွှေ့ပြောင်းပါ။ feature thread အသစ်တစ်ခုသို့ ပြောင်းရွှေ့မှုအတွင်း ဖြစ်ပွားခဲ့သော ပဋိပက္ခများကို ပေါင်းစည်းဖြေရှင်းပါ။

   

3. ဆုတ်ယုတ်မှုစမ်းသပ်မှုကို ထည့်ပါ။ ci.test.js:

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

4. ၎င်းတို့ မအောင်မြင်ကြောင်း သေချာစေရန် စမ်းသပ်မှုများကို စက်တွင်းတွင် လုပ်ဆောင်ပါ။
5. ထဲတွင် "sneaky bug" ဟူသောစာသားကိုဖယ်ရှားပါ။ 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 သူ့၌။ repository ကိုလမ်းခွဲပါ။ "အခြေခံဌာနခွဲ" အနေဖြင့် သင်တန်းပစ္စည်းများသိုလှောင်ရာသို့ အပြောင်းအလဲများအတွက် တောင်းဆိုမှုများကို ကျွန်ုပ်တုံ့ပြန်မည်မဟုတ်ပါ။

"အင်္ဂါရပ်ကိုပြင်ခြင်း" ဆွဲယူတောင်းဆိုမှုကိုအတည်ပြုပါ

ပြုပြင်မှုအတွက် ကျေးဇူးတင်ပါသည်။ ပြောင်းလဲမှုများကို အတည်ပြုပေးပါ။ master ဆွဲတင်တောင်းဆိုမှုမှ။

️တာဝန်

1. "Merge pull request" ကိုနှိပ်ပါ။
2. "Confirm Merge" ကိုနှိပ်ပါ။
3. ကျွန်ုပ်တို့ ၎င်းကို မလိုအပ်တော့သောကြောင့် "Delete Branch" ကိုနှိပ်ပါ။

ဒါက လက်ရှိမှာ ရှိသင့်တဲ့အရာပါ။

ဂုဏ်ယူပါသည်။

စဉ်ဆက်မပြတ် ပေါင်းစည်းမှုတွင် လူများ ပုံမှန်အားဖြင့် လုပ်ဆောင်သည့် အဆင့်များအားလုံးကို သင် ပြီးမြောက်ပြီးဖြစ်သည်။

သင်တန်းတွင် ပြဿနာတစ်စုံတစ်ရာ သတိပြုမိပါက သို့မဟုတ် ပိုမိုကောင်းမွန်အောင် ပြုလုပ်နည်းကို သိရှိပါက၊ ပြဿနာတစ်ခု ဖန်တီးပါ။ သင်တန်းပစ္စည်းများနှင့်အတူ သိုလှောင်ရုံများ. ဒီသင်တန်းလည်းရှိတယ်။ အပြန်အလှန်အကျိုးသက်ရောက်မှုဗားရှင်း ပလက်ဖောင်းတစ်ခုအနေဖြင့် GitHub Learning Lab ကိုအသုံးပြုခြင်း။

source: www.habr.com