আপনি কি গিট কমান্ড শিখেছেন কিন্তু কল্পনা করতে চান কিভাবে ক্রমাগত ইন্টিগ্রেশন (CI) বাস্তবে কাজ করে? অথবা হয়তো আপনি আপনার দৈনন্দিন কার্যক্রম অপ্টিমাইজ করতে চান? এই কোর্সটি আপনাকে একটি GitHub সংগ্রহস্থল ব্যবহার করে ক্রমাগত একীকরণে ব্যবহারিক দক্ষতা দেবে। এই কোর্সটি একটি উইজার্ড হওয়ার উদ্দেশ্যে নয় যেটির মাধ্যমে আপনি কেবল ক্লিক করতে পারেন; বিপরীতে, আপনি একই ক্রিয়া সম্পাদন করবেন যা লোকেরা আসলে কর্মক্ষেত্রে করে, তারা যেভাবে করে। আপনি জড়িত পদক্ষেপের মধ্য দিয়ে যাওয়ার সাথে সাথে আমি তত্ত্বটি ব্যাখ্যা করব।

আমরা কি করি?

আমরা যখন অগ্রগতি করব, আমরা ধীরে ধীরে সাধারণ CI পদক্ষেপগুলির একটি তালিকা তৈরি করব, যা এই তালিকাটি মনে রাখার একটি দুর্দান্ত উপায়। অন্য কথায়, আমরা ক্রমাগত ইন্টিগ্রেশন করার সময়, ক্রমাগত ইন্টিগ্রেশন করার সময় বিকাশকারীরা যে ক্রিয়াগুলি গ্রহণ করে তার একটি তালিকা তৈরি করব। আমরা আমাদের CI প্রক্রিয়াটিকে আসলটির কাছাকাছি আনতে পরীক্ষার একটি সাধারণ সেটও ব্যবহার করব।

এই GIF পরিকল্পিতভাবে আপনার সংগ্রহস্থলে কমিটগুলি দেখায় যখন আপনি কোর্সের মাধ্যমে অগ্রসর হন। আপনি দেখতে পাচ্ছেন, এখানে জটিল কিছু নেই এবং শুধুমাত্র সবচেয়ে প্রয়োজনীয়।

আপনি নিম্নলিখিত স্ট্যান্ডার্ড CI পরিস্থিতির মধ্য দিয়ে যাবেন:

• একটি বৈশিষ্ট্য কাজ;
• গুণমান নিশ্চিত করতে স্বয়ংক্রিয় পরীক্ষার প্রয়োগ;
• অগ্রাধিকার কাজ বাস্তবায়ন;
• শাখা একত্রিত করার সময় দ্বন্দ্বের সমাধান (সংঘাত একত্রিত করা);
• একটি উত্পাদন পরিবেশে একটি ত্রুটি ঘটে৷

আপনি কি শিখবেন?

আপনি নিম্নলিখিত প্রশ্নের উত্তর দিতে সক্ষম হবে:

• একটানা ইন্টিগ্রেশন (CI) কি?
• সিআই-তে কী ধরনের স্বয়ংক্রিয় পরীক্ষা ব্যবহার করা হয় এবং কোন ক্রিয়াগুলির প্রতিক্রিয়া হিসাবে সেগুলি ট্রিগার করা হয়?
• টান অনুরোধ কি এবং কখন তাদের প্রয়োজন হয়?
• টেস্ট ড্রাইভেন ডেভেলপমেন্ট (টিডিডি) কী এবং এটি কীভাবে সিআই-এর সাথে সম্পর্কিত?
• আমি কি পরিবর্তনগুলিকে একত্রিত করব বা পুনরায় স্থাপন করব?
• রোল ব্যাক বা পরবর্তী সংস্করণে ঠিক করবেন?

প্রথমে আমি সব জায়গায় "পুল রিকোয়েস্ট" এর মতো জিনিস অনুবাদ করেছি, কিন্তু ফলস্বরূপ আমি পাঠ্যের পাগলামি কমাতে কিছু জায়গায় ইংরেজিতে বাক্যাংশ ফেরত দেওয়ার সিদ্ধান্ত নিয়েছি। আমি মাঝে মাঝে "প্রোগ্রামার সুরজিক" ব্যবহার করব যেমন বিস্ময়কর ক্রিয়া "কমিট" যেখানে লোকেরা আসলে এটি কাজে ব্যবহার করে।

ক্রমাগত একীকরণ কি?

একটানা সমাকলান, বা CI, একটি প্রযুক্তিগত অনুশীলন যেখানে প্রতিটি দলের সদস্য তাদের কোডকে দিনে অন্তত একবার একটি সাধারণ সংগ্রহস্থলে একীভূত করে, এবং ফলস্বরূপ কোডটি অন্তত ত্রুটি ছাড়াই তৈরি করা আবশ্যক।

এই শব্দটি নিয়ে মতভেদ রয়েছে

বিরোধের বিষয় হল একীকরণের ফ্রিকোয়েন্সি। কেউ কেউ যুক্তি দেন যে দিনে একবার কোড মার্জ করা আসলে ক্রমাগত সংহত করার জন্য যথেষ্ট নয়। একটি দলের উদাহরণ দেওয়া হয়েছে যেখানে প্রত্যেকে সকালে তাজা কোড নেয় এবং সন্ধ্যায় একবার এটি সংহত করে। যদিও এটি একটি যুক্তিসঙ্গত আপত্তি, এটি সাধারণত বিশ্বাস করা হয় যে দিনে একবারের সংজ্ঞাটি যুক্তিসঙ্গতভাবে ব্যবহারিক, নির্দিষ্ট এবং বিভিন্ন আকারের দলের জন্য উপযুক্ত।

আরেকটি আপত্তি হল যে C++ এখন আর উন্নয়নে ব্যবহৃত একমাত্র ভাষা নয়, এবং বৈধকরণের উপায় হিসাবে কেবল ত্রুটি-মুক্ত সমাবেশের প্রয়োজন দুর্বল। কিছু পরীক্ষার সেট (উদাহরণস্বরূপ, স্থানীয়ভাবে সম্পাদিত ইউনিট পরীক্ষা) অবশ্যই সফলভাবে সম্পন্ন করতে হবে। এই মুহুর্তে, সম্প্রদায় এটিকে একটি প্রয়োজনীয়তা করার দিকে এগিয়ে যাচ্ছে, এবং ভবিষ্যতে "বিল্ড + ইউনিট পরীক্ষা" সম্ভবত সাধারণ অভ্যাস হয়ে উঠবে, যদি এটি ইতিমধ্যে না থাকে।

একটানা সমাকলান থেকে পৃথক ক্রমাগত বিতরণ (কন্টিনিউয়াস ডেলিভারি, সিডি) যাতে প্রতিটি ইন্টিগ্রেশন সাইকেলের পরে রিলিজ প্রার্থীর প্রয়োজন হয় না।

আমরা পুরো কোর্স জুড়ে ব্যবহার করব পদক্ষেপের তালিকা

1. সর্বশেষ কোড টানুন. থেকে একটি শাখা তৈরি করুন master. কাজ শুরু কর.
2. আপনার নতুন শাখায় প্রতিশ্রুতি তৈরি করুন। স্থানীয়ভাবে তৈরি করুন এবং পরীক্ষা করুন। পাস? পরবর্তী ধাপে যাও. ব্যর্থ? ত্রুটি বা পরীক্ষা ঠিক করুন এবং আবার চেষ্টা করুন।
3. আপনার রিমোট রিপোজিটরি বা দূরবর্তী শাখায় ধাক্কা দিন।
4. একটি টান অনুরোধ তৈরি করুন. পরিবর্তনগুলি নিয়ে আলোচনা করুন, আলোচনা চলতে থাকলে আরও কমিট যোগ করুন৷ ফিচার শাখায় পরীক্ষা পাস করুন।
5. মাস্টার থেকে মার্জ/রিবেস কমিট। মার্জ ফলাফলে পরীক্ষা পাস করুন।
6. বৈশিষ্ট্য শাখা থেকে উৎপাদনে স্থাপন করুন।
7. কিছু সময়ের জন্য উৎপাদনে সবকিছু ভালো থাকলে, মাস্টারে পরিবর্তনগুলি মার্জ করুন।

️ প্রস্তুতি

আপনার সঠিক সফ্টওয়্যার আছে তা নিশ্চিত করুন

এই কোর্সটি নিতে আপনার প্রয়োজন হবে node.js и গিট ক্লায়েন্ট.

আপনি যেকোন গিট ক্লায়েন্ট ব্যবহার করতে পারেন, কিন্তু আমি শুধুমাত্র কমান্ড লাইনের জন্য কমান্ড প্রদান করব।

নিশ্চিত করুন যে আপনার একটি গিট ক্লায়েন্ট ইনস্টল করা আছে যা কমান্ড লাইন সমর্থন করে

আপনার যদি এখনও কমান্ড লাইন সমর্থন করে এমন একটি গিট ক্লায়েন্ট না থাকে তবে আপনি ইনস্টলেশন নির্দেশাবলী খুঁজে পেতে পারেন এখানে.

সংগ্রহস্থল প্রস্তুত করুন

আপনাকে একটি ব্যক্তিগত অনুলিপি তৈরি করতে হবে (কাঁটা) কোর্সের জন্য কোড সহ টেমপ্লেট সংগ্রহস্থল গিটহাবে। আসুন এই ব্যক্তিগত অনুলিপি কল করতে সম্মত হন কোর্স ভান্ডার.

সম্পন্ন? আপনি যদি ডিফল্ট সেটিংস পরিবর্তন না করে থাকেন, তাহলে আপনার কোর্স রিপোজিটরিকে সম্ভবত বলা হবে continuous-integration-team-scenarios-students, এটি আপনার GitHub অ্যাকাউন্টে অবস্থিত এবং URLটি এইরকম দেখাচ্ছে৷

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

আমি শুধু এই ঠিকানায় কল করব <URL репозитория>.

কোণ বন্ধনী মত <тут> এর মানে হল যে আপনাকে অবশ্যই উপযুক্ত মান দিয়ে এই ধরনের একটি অভিব্যক্তি প্রতিস্থাপন করতে হবে।

নিশ্চিত করো যে GitHub অ্যাকশন এই কোর্স ভান্ডার জন্য অন্তর্ভুক্ত. যদি সেগুলি সক্ষম না থাকে, অনুগ্রহ করে পৃষ্ঠার মাঝখানে বড় বোতামটি ক্লিক করে তাদের সক্ষম করুন, যা আপনি গিটহাব ইন্টারফেসে অ্যাকশনে ক্লিক করে পেতে পারেন৷

GitHub অ্যাকশন চালু না থাকলে আপনি আমার নির্দেশাবলী অনুসরণ করে কোর্সটি সম্পূর্ণ করতে পারবেন না।

আমরা এখানে যে তালিকাটি রচনা করছি তার বর্তমান অবস্থা দেখতে আপনি সর্বদা মার্কডাউন রেন্ডার করার জন্য গিটহাবের ক্ষমতা ব্যবহার করতে পারেন

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

উত্তর সম্পর্কে

যদিও এই কোর্সটি সম্পূর্ণ করার সর্বোত্তম উপায় হল এটি নিজে করা, আপনার কিছু অসুবিধা হতে পারে।

আপনি যদি মনে করেন যে আপনি কী করবেন তা বুঝতে পারছেন না এবং চালিয়ে যেতে পারবেন না, আপনি থ্রেডটি দেখতে পারেন solution, যা আপনার স্টার্ট রিপোজিটরিতে রয়েছে।
একত্রিত করবেন না দয়া করে solution в master অবশ্যই সময়. গিট আমাদের যে সমস্ত ক্ষমতা দেয় তা ব্যবহার করে আপনি এই শাখাটি ব্যবহার করতে পারেন কি করতে হবে বা লেখকের সাথে আপনার কোড তুলনা করতে। আপনি সম্পূর্ণরূপে হারিয়ে গেলে, আপনি সম্পূর্ণরূপে আপনার শাখা প্রতিস্থাপন করতে পারেন 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-এর সাথে, এটি সাধারণত সংগ্রহস্থলের একটি ব্যক্তিগত অনুলিপি (ব্যক্তিগত কাঁটা) বা একটি ব্যক্তিগত শাখায় কাজটি প্রকাশ করার মাধ্যমে অর্জন করা হয়।

• কাঁটাচামচের সাহায্যে, একজন বিকাশকারী একটি দূরবর্তী শেয়ার্ড রিপোজিটরি ক্লোন করে, এটির একটি ব্যক্তিগত দূরবর্তী অনুলিপি তৈরি করে, যা একটি ফর্ক নামেও পরিচিত। তারপরে এটি স্থানীয়ভাবে কাজ করার জন্য এই ব্যক্তিগত সংগ্রহস্থলটি ক্লোন করে। যখন কাজটি সম্পূর্ণ হয় এবং প্রতিশ্রুতিগুলি তৈরি করা হয়, তখন সে সেগুলিকে তার কাঁটাচামচের মধ্যে ঠেলে দেয়, যেখানে সেগুলি অন্যদের জন্য উপলব্ধ এবং সাধারণ ভান্ডারে একত্রিত করা যেতে পারে। এই পদ্ধতিটি সাধারণত গিটহাবের ওপেন সোর্স প্রকল্পগুলিতে ব্যবহৃত হয়। এটি আমার উন্নত কোর্সেও ব্যবহার করা হয় [Team Work এবং CI with Git] (http://devops.redpill.solutions/).
• আরেকটি পদ্ধতি হল শুধুমাত্র একটি দূরবর্তী সংগ্রহস্থল ব্যবহার করা এবং শুধুমাত্র শাখা গণনা করা master শেয়ার্ড রিপোজিটরি "সুরক্ষিত"। এই পরিস্থিতিতে, স্বতন্ত্র বিকাশকারীরা তাদের কোড একটি দূরবর্তী সংগ্রহস্থলের শাখায় প্রকাশ করে যাতে অন্যরা এই কোডটি দেখতে পারে, যদি সবকিছু ঠিকঠাক থাকে তবে এটির সাথে একত্রিত করুন master শেয়ার্ড রিপোজিটরি।

এই বিশেষ কোর্সে, আমরা একটি কর্মপ্রবাহ ব্যবহার করব যা শাখাগুলি ব্যবহার করে।

আমাদের কোড প্রকাশ করা যাক.

️টাস্ক

• আপনার কর্মরত শাখার মতো একই নামের একটি দূরবর্তী শাখায় পরিবর্তনগুলি প্রকাশ করুন

কমান্ড

git push --set-upstream origin feature

একটি টান অনুরোধ তৈরি করুন

একটি শিরোনাম সহ একটি টান অনুরোধ তৈরি করুন পদক্ষেপ পর্যালোচনা... ইনস্টল করুন feature যেমন "মাথা শাখা" এবং master যেমন "বেস শাখা"।

আপনি ইনস্টল করেছেন নিশ্চিত করুন master তার মধ্যে সংগ্রহস্থল কাঁটাচামচ একটি "বেস শাখা" হিসাবে, আমি কোর্স উপকরণ সংগ্রহস্থলে পরিবর্তনের জন্য অনুরোধের জবাব দেব না।

GitHub lingo-এ, "বেস শাখা" হল সেই শাখা যার উপর আপনি আপনার কাজকে ভিত্তি করে থাকেন এবং "হেড ব্রাঞ্চ" হল সেই শাখা যেখানে প্রস্তাবিত পরিবর্তনগুলি রয়েছে৷

পরিবর্তনগুলি নিয়ে আলোচনা করুন, আলোচনা চলতে থাকলে নতুন কমিট যোগ করুন৷

পুল রিকোয়েস্ট (পিআর)

পুল রিকোয়েস্ট (পিআর) আলোচনা এবং নথির কোড, সেইসাথে কোড পর্যালোচনা করার একটি উপায়। সামগ্রিক কোডে স্বতন্ত্র পরিবর্তনগুলিকে একীভূত করার সাধারণ উপায় অনুসারে পুল অনুরোধগুলির নামকরণ করা হয়েছে। সাধারণত, একজন ব্যক্তি প্রজেক্টের রিমোট অফিসিয়াল রিপোজিটরি ক্লোন করে এবং স্থানীয়ভাবে কোডে কাজ করে। এর পরে, তিনি কোডটি তার ব্যক্তিগত রিমোট রিপোজিটরিতে রাখেন এবং অফিসিয়াল রিপোজিটরির জন্য দায়ী ব্যক্তিদের নিতে বলেন(টান) এর কোড তাদের স্থানীয় সংগ্রহস্থলে, যেখানে তারা পর্যালোচনা করে এবং সম্ভবত সংহত করে(মার্জ) তার। এই ধারণাটি অন্যান্য নামেও পরিচিত, উদাহরণস্বরূপ, একত্রিত করার অনুরোধ.

আপনাকে আসলে GitHub বা অনুরূপ প্ল্যাটফর্মগুলির পুল অনুরোধ বৈশিষ্ট্যটি ব্যবহার করতে হবে না। ডেভেলপমেন্ট দলগুলি মুখোমুখি যোগাযোগ, ভয়েস কল বা ইমেল সহ যোগাযোগের অন্যান্য পদ্ধতি ব্যবহার করতে পারে, তবে ফোরাম-স্টাইল পুল অনুরোধগুলি ব্যবহার করার জন্য এখনও বেশ কয়েকটি কারণ রয়েছে। এখানে তাদের কিছু:

• সংগঠিত আলোচনা নির্দিষ্ট কোড পরিবর্তন সম্পর্কিত;
• অটোটেস্টার এবং সমবয়সীদের উভয়ের কাছ থেকে কাজের অগ্রগতির প্রতিক্রিয়া দেখার জায়গা হিসাবে;
• কোড পর্যালোচনা আনুষ্ঠানিককরণ;
• যাতে পরে আপনি কোডের এই বা সেই অংশের পিছনের কারণ এবং বিবেচনাগুলি খুঁজে পেতে পারেন৷

সাধারণত আপনি যখন কিছু আলোচনা করতে বা প্রতিক্রিয়া পেতে চান তখন আপনি একটি পুল অনুরোধ তৈরি করেন। উদাহরণস্বরূপ, আপনি যদি এমন একটি বৈশিষ্ট্য নিয়ে কাজ করছেন যা একাধিক উপায়ে প্রয়োগ করা যেতে পারে, তাহলে আপনি আপনার ধারণাগুলি ভাগ করতে এবং আপনার সহযোগীদের সাথে আপনার পরিকল্পনাগুলি নিয়ে আলোচনা করার জন্য কোডের প্রথম লাইন লেখার আগে একটি পুল অনুরোধ তৈরি করতে পারেন৷ যদি কাজটি সহজ হয়, একটি টান অনুরোধ খোলা হয় যখন কিছু ইতিমধ্যে করা হয়েছে, প্রতিশ্রুতিবদ্ধ এবং আলোচনা করা যেতে পারে। কিছু পরিস্থিতিতে, আপনি শুধুমাত্র মান নিয়ন্ত্রণের কারণে একটি PR খুলতে চাইতে পারেন: স্বয়ংক্রিয় পরীক্ষা চালানো বা কোড পর্যালোচনা শুরু করতে। আপনি যাই সিদ্ধান্ত নিন না কেন, আপনার পুল অনুরোধে যাদের অনুমোদন আপনি চান তাদের @ উল্লেখ করতে ভুলবেন না।

সাধারণত, পিআর তৈরি করার সময়, আপনি নিম্নলিখিতগুলি করেন।

• আপনি কি পরিবর্তন করতে চান এবং কোথায় তা নির্দেশ করুন।
• পরিবর্তনের উদ্দেশ্য ব্যাখ্যা করে একটি বর্ণনা লিখুন। তুমি চাইতে পারো:
  • কোড থেকে স্পষ্ট নয় এমন কিছু গুরুত্বপূর্ণ, বা প্রসঙ্গ বোঝার জন্য দরকারী কিছু যোগ করুন, যেমন প্রাসঙ্গিক #বাগ এবং কমিট নম্বর;
  • আপনি যার সাথে কাজ শুরু করতে চান তাকে @উল্লেখ করুন, অথবা আপনি পরে মন্তব্যে তাদের @উল্লেখ করতে পারেন;
  • সহকর্মীদের কিছুতে সাহায্য করতে বা নির্দিষ্ট কিছু পরীক্ষা করতে বলুন।

একবার আপনি PR খুললে, এই ধরনের ক্ষেত্রে চালানোর জন্য কনফিগার করা পরীক্ষাগুলি কার্যকর করা হয়। আমাদের ক্ষেত্রে, এটি একই পরীক্ষাগুলির সেট হবে যা আমরা স্থানীয়ভাবে চালিয়েছি, তবে একটি বাস্তব প্রকল্পে অতিরিক্ত পরীক্ষা এবং চেক থাকতে পারে।

পরীক্ষাগুলো সম্পন্ন হওয়ার সময় অনুগ্রহ করে অপেক্ষা করুন। আপনি GitHub ইন্টারফেসে PR আলোচনার নীচে পরীক্ষার অবস্থা দেখতে পারেন। পরীক্ষা শেষ হলে চালিয়ে যান।

️ CI ধাপের তালিকার এলোমেলোতা সম্পর্কে একটি নোট যোগ করুন

এই কোর্সে ব্যবহৃত তালিকাটি নির্বিচারে এবং বিষয়ভিত্তিক, আমাদের এই সম্পর্কে একটি নোট যোগ করা উচিত।

️ টাস্ক: এই মন্তব্যের জন্য একটি টান অনুরোধ তৈরি করুন

1. শাখায় স্যুইচ করুন master.
2. নামে একটি শাখা তৈরি করুন bugfix.
3. ফাইলের শেষে নোট টেক্সট যোগ করুন ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. পরিবর্তনগুলি প্রতিশ্রুতিবদ্ধ করুন।
5. থ্রেড প্রকাশ করুন bugfix একটি দূরবর্তী ভান্ডারে।
6. নামে একটি পুল অনুরোধ তৈরি করুন একটি মন্তব্য যোগ করা একটি প্রধান শাখা সহ bugfix এবং ভিত্তি শাখাmaster.

আপনি ইনস্টল করেছেন নিশ্চিত করুন master তার মধ্যে সংগ্রহস্থল কাঁটাচামচ একটি "বেস শাখা" হিসাবে, আমি কোর্স উপকরণ সংগ্রহস্থলে পরিবর্তনের জন্য অনুরোধের জবাব দেব না।

এটি আপনার সংগ্রহস্থলের মত হওয়া উচিত।

কমান্ড

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

"একটি মন্তব্য যোগ করা" টান অনুরোধ অনুমোদন করুন

️টাস্ক

1. একটি টান অনুরোধ তৈরি করুন.
2. "মার্জ টান রিকোয়েস্ট" এ ক্লিক করুন।
3. "একত্রীকরণ নিশ্চিত করুন" ক্লিক করুন।
4. "শাখা মুছুন" ক্লিক করুন, আমাদের আর এটির প্রয়োজন নেই।

এটি একত্রিত হওয়ার পরে কমিটের একটি চিত্র।

️ কাজ চালিয়ে যান এবং পরীক্ষা যোগ করুন

একটি টান অনুরোধে সহযোগিতা প্রায়ই অতিরিক্ত কাজ ফলাফল. এটি সাধারণত একটি কোড পর্যালোচনা বা আলোচনার ফলাফল, কিন্তু আমাদের কোর্সে আমরা আমাদের CI ধাপের তালিকায় নতুন আইটেম যোগ করে এটি মডেল করতে যাচ্ছি।

ক্রমাগত ইন্টিগ্রেশনে সাধারণত কিছু পরীক্ষার কভারেজ জড়িত থাকে। পরীক্ষার কভারেজ প্রয়োজনীয়তা পরিবর্তিত হয় এবং সাধারণত "অবদান নির্দেশিকা" এর মত কিছু বলা একটি নথিতে পাওয়া যায়। আমরা এটিকে সহজ রাখব এবং আমাদের চেকলিস্টে প্রতিটি লাইনের জন্য একটি পরীক্ষা যোগ করব।

অ্যাসাইনমেন্ট চালানোর সময়, প্রথমে পরীক্ষা করার চেষ্টা করুন। আপনি যদি সঠিকভাবে ইনস্টল করেন pre-commit আগে hook, নতুন যোগ করা পরীক্ষা চালানো হবে, ব্যর্থ হবে, এবং কিছুই প্রতিশ্রুতিবদ্ধ হবে না। মনে রাখবেন যে এইভাবে আমরা জানি যে আমাদের পরীক্ষাগুলি আসলে কিছু পরীক্ষা করছে। মজার বিষয় হল, যদি আমরা পরীক্ষার আগে কোড দিয়ে শুরু করি, তাহলে পরীক্ষায় উত্তীর্ণ হওয়ার মানে হতে পারে যে কোডটি প্রত্যাশিতভাবে কাজ করেছে, অথবা পরীক্ষাগুলি আসলে কিছু পরীক্ষা করছে না। এছাড়াও, যদি আমরা প্রথম স্থানে পরীক্ষাগুলি না লিখতাম, তাহলে আমরা সেগুলি সম্পর্কে সম্পূর্ণ ভুলে যেতে পারতাম, যেহেতু কিছুই আমাদের মনে করিয়ে দিত না।

টেস্ট ড্রাইভেন ডেভেলপমেন্ট (TDD)

TDD কোডের আগে পরীক্ষা লেখার সুপারিশ করে। টিডিডি ব্যবহার করে একটি সাধারণ ওয়ার্কফ্লো এইরকম দেখায়।

1. একটি পরীক্ষা যোগ করুন.
2. সমস্ত পরীক্ষা চালান এবং নিশ্চিত করুন যে নতুন পরীক্ষা ব্যর্থ হয়েছে।
3. কোড লিখুন।
4. পরীক্ষা চালান, নিশ্চিত করুন যে সমস্ত পরীক্ষা পাস।
5. আপনার কোড রিফ্যাক্টর.
6. পুনরাবৃত্তি করুন।

কারণ যে পরীক্ষার ফলাফলগুলি ব্যর্থ হয় সেগুলি সাধারণত লাল রঙে দেখানো হয় এবং যেগুলি পাস করা হয় সেগুলি সাধারণত সবুজ রঙে দেখানো হয়, চক্রটিকে লাল-সবুজ-রিফ্যাক্টর হিসাবেও পরিচিত।

️টাস্ক

প্রথমে, পরীক্ষা করার চেষ্টা করুন এবং তাদের ব্যর্থ হতে দিন, তারপর CI ধাপ তালিকার পাঠ্য যোগ করুন এবং কমিট করুন। আপনি দেখতে পাবেন যে পরীক্ষাগুলি পাস হচ্ছে ("সবুজ")।
তারপরে রিমোট রিপোজিটরিতে নতুন কোডটি প্রকাশ করুন এবং পুল অনুরোধ আলোচনা এবং পিআর স্ট্যাটাস আপডেটের নীচে গিটহাব ইন্টারফেসে চালানো পরীক্ষাগুলি দেখুন।

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 এবং যত তাড়াতাড়ি সম্ভব নতুন সংস্করণ স্থাপন করা হচ্ছে। যেহেতু এপিআই এবং ডাটাবেস স্কিমাগুলি কোড প্রোডাকশনে মোতায়েন করার সাথে সাথে পরিবর্তিত হয়, ক্রমাগত ডেলিভারি এবং ভাল পরীক্ষার কভারেজ সহ, পরবর্তী সংস্করণে এটি ঠিক করার চেয়ে রোল ব্যাক করা সাধারণত অনেক বেশি কঠিন এবং ঝুঁকিপূর্ণ।

যেহেতু রোল ব্যাক করা আমাদের ক্ষেত্রে কোনো ঝুঁকি বহন করে না, তাই আমরা এই পথে যাব, কারণ এটি আমাদের অনুমতি দেয়

• যত তাড়াতাড়ি সম্ভব পণ্যের ত্রুটি ঠিক করুন;
• কোড তৈরি করুন master অবিলম্বে একটি নতুন কাজ শুরু করার জন্য উপযুক্ত।

️টাস্ক

1. শাখায় স্যুইচ করুন master স্থানীয়ভাবে
2. দূরবর্তী সংগ্রহস্থল থেকে স্থানীয় সংগ্রহস্থল আপডেট করুন।
3. পিআর মার্জ কমিট প্রত্যাবর্তন করুন পদক্ষেপ পর্যালোচনা в master.
4. রিমোট রিপোজিটরিতে পরিবর্তনগুলি প্রকাশ করুন।

এটি একটি মার্জ কমিট প্রত্যাবর্তন সহ একটি সংগ্রহস্থলের ইতিহাস

কমান্ড

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ স্ব-পরীক্ষা

নিশ্চিত করো যে ci.md একটি মার্জ কমিট প্রত্যাবর্তনের পরে "sneaky bug" লেখাটি আর থাকে না।

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