Git-এ Main এবং Master Branch: এটি কী এবং কেন প্রধান শাখার প্রয়োজন

Git-এ Main / Master Branch কী

Main Branch (বা Master — রিপোজিটরি সেটিংসের উপর নির্ভর করে) হল ডিফল্ট শাখা যা যেকোনো Git রিপোজিটরি ইনিশিয়ালাইজ করার সময় তৈরি হয়। এটি প্রকল্পের প্রধান শাখা এবং প্রোডাকশনে ডিপ্লয় করার জন্য প্রস্তুত কোড ধারণ করে।

develop-এর বিপরীতে, যেখানে নতুন বৈশিষ্ট্য নিয়ে দৈনন্দিন কাজ চলছে, main হল প্রকল্পের শোকেস। main-এ কোডের প্রতিটি ভার্সন একটি পূর্ণ চক্রের মধ্য দিয়ে গেছে: feature শাখায় ডেভেলপমেন্ট, develop-এ ইন্টিগ্রেশন, release শাখায় রিলিজ প্রস্তুতি এবং চূড়ান্ত পরীক্ষা। তার পরেই পরিবর্তনগুলি main-এ পৌঁছায়।

মূল নীতি: main সর্বদা স্থিতিশীল থাকতে হবে। যদি main-এ কোনো ত্রুটি পাওয়া যায়, তবে এর অর্থ জরুরি hotfix প্রয়োজন। তাই, পেশাদার প্রকল্পগুলিতে, main শাখা সুরক্ষা নিয়ম দ্বারা আকস্মিক পরিবর্তন থেকে সুরক্ষিত থাকে।

Git Book অনুসারে, main কোনো অনন্য বৈশিষ্ট্যসহ বিশেষ শাখা নয়, বরং একটি কমিটের সাধারণ রেফারেন্স যা প্রথা অনুসারে প্রধান হিসেবে বিবেচিত হয়। Git সিস্টেম স্তরে main এবং অন্য যেকোনো শাখার মধ্যে কোনো পার্থক্য করে না।

master থেকে main-এ রূপান্তর

ঐতিহাসিকভাবে, Git-এ ডিফল্ট শাখাটিকে master বলা হত। জুন 2020-এ, Black Lives Matter আন্দোলন IT শিল্পে master এবং slave শব্দগুলির প্রতি দৃষ্টি আকর্ষণ করে। GitHub ডিফল্ট শাখার জন্য main শব্দটিতে রূপান্তরের ঘোষণা দেয়।

অক্টোবর 2020 থেকে, GitHub-এর সমস্ত নতুন রিপোজিটরি main শাখা দিয়ে তৈরি হয়। GitLab এবং Bitbucket-ও ডিফল্ট নাম হিসেবে main-এর জন্য সমর্থন বাস্তবায়ন করেছে। Git 2.28 (জুলাই 2020) ডিফল্ট শাখার নাম কনফিগার করার জন্য init.defaultBranch অপশন যুক্ত করেছে।

প্রযুক্তিগতভাবে, বিদ্যমান শাখার নাম master থেকে main-এ পরিবর্তন করা একটি সহজ অপারেশন। মূল চ্যালেঞ্জ হল CI/CD কনফিগারেশন, ডকুমেন্টেশন এবং ডেভেলপারদের স্থানীয় রিপোজিটরির সমস্ত রেফারেন্স আপডেট করা।

বিদ্যমান রিপোজিটরিতে শাখার নাম পরিবর্তন করতে, চালান:

# স্থানীয়ভাবে master-কে main-এ নাম পরিবর্তন
git branch -m master main

# রিমোট রিপোজিটরি আপডেট
git push -u origin main

# সার্ভারে পুরানো master মুছে ফেলা
git push origin --delete master

# সার্ভারে HEAD আপডেট
# (GitHub ওয়েব ইন্টারফেসের মাধ্যমে: Settings → Branches → Default branch)

Git Flow এবং GitHub Flow-এ main-এর ভূমিকা

Git Flow এবং GitHub Flow main শাখার ভূমিকা ভিন্নভাবে সংজ্ঞায়িত করে। মডেলের পছন্দ টিমের আকার, রিলিজ ফ্রিকোয়েন্সি এবং কোড স্থিতিশীলতার প্রয়োজনীয়তার উপর নির্ভর করে।

মোবাইল ডেভেলপমেন্টের জন্য, Git Flow হল মান, কারণ App Store এবং Google Play-তে অ্যাপ প্রকাশের নির্দিষ্ট রিলিজ চক্র রয়েছে। GitHub Flow ওয়েব প্রকল্পগুলির জন্য বেশি উপযোগী যা দিনে একাধিকবার ডিপ্লয় করা যায়।

GitHub Flow — সরলীকৃত পদ্ধতি

GitHub Flow-এ, কোনো develop শাখা নেই। সমস্ত feature শাখা সরাসরি main থেকে তৈরি হয় এবং সম্পূর্ণ হলে Pull Request-এর মাধ্যমে আবার মার্জ করা হয়। main-এ প্রতিটি মার্জ স্বয়ংক্রিয়ভাবে প্রোডাকশনে ডিপ্লয়মেন্ট ট্রিগার করে। এই মডেলের জন্য উচ্চ স্তরের টেস্ট অটোমেশন এবং টিম শৃঙ্খলা প্রয়োজন।

GitHub Flow-এ, কোনো develop শাখা নেই। সমস্ত feature শাখা সরাসরি main থেকে তৈরি হয় এবং সম্পূর্ণ হলে Pull Request-এর মাধ্যমে আবার মার্জ করা হয়। main-এ প্রতিটি মার্জ স্বয়ংক্রিয়ভাবে প্রোডাকশনে ডিপ্লয়মেন্ট ট্রিগার করে। এই মডেলের জন্য উচ্চ স্তরের টেস্ট অটোমেশন এবং টিম শৃঙ্খলা প্রয়োজন।

main শাখার সুরক্ষা

শাখা সুরক্ষা main-এর জন্য যেকোনো বাণিজ্যিক প্রকল্পে বাধ্যতামূলক সেটিং। এটি ছাড়া, একটি আকস্মিক push অসম্পূর্ণ কোড প্রোডাকশনে পাঠাতে পারে বা সমস্ত ব্যবহারকারীর জন্য কাজ করা অ্যাপ্লিকেশন ভেঙে দিতে পারে।

• Require pull request — main-এ সরাসরি push নিষিদ্ধ। পর্যালোচনাসহ PR-এর মাধ্যমে সমস্ত পরিবর্তন।
• Require approvals — main-এ মার্জ করার জন্য ন্যূনতম 2 অনুমোদন (যদি কোনো পর্যালোচক কিছু মিস করে)।
• Require status checks — মার্জ করার আগে সমস্ত CI/CD চেক সফল হতে হবে।
• Require up-to-date — PR সর্বশেষ main কমিটের উপর ভিত্তি করে হতে হবে।
• Include administrators — সুরক্ষা রিপোজিটরি মালিকদের জন্যও প্রযোজ্য।
• Require signed commits — main-এর সমস্ত কমিট GPG কী দিয়ে স্বাক্ষরিত হতে হবে।

ছয়টি নিয়ম কনফিগার করা 10,000+ ব্যবহারকারীর মোবাইল প্রকল্পের জন্য মান। ছোট প্রকল্পের জন্য, প্রথম তিনটি নিয়ম যথেষ্ট।

বিভিন্ন ধরনের প্রকল্পের জন্য সুরক্ষা স্তরের তুলনা

main-এর সুরক্ষার স্তর প্রকল্পের স্কেলের উপর নির্ভর করে। একটি স্টার্টআপ ন্যূনতম সুরক্ষা দিয়ে চালাতে পারে, যখন এন্টারপ্রাইজ অ্যাপ্লিকেশনের সর্বোচ্চ বিধিনিষেধ প্রয়োজন।

main-এ রিলিজ এবং ট্যাগ

ট্যাগিং হল main-এ নির্দিষ্ট কমিটের নামযুক্ত রেফারেন্স তৈরি করার অনুশীলন। প্রতিটি ট্যাগ প্রোডাকশনে প্রকাশিত অ্যাপ্লিকেশনের একটি ভার্সনের সাথে মিলে যায়। এটি ডিবাগিং বা প্যাচের জন্য যেকোনো পূর্ববর্তী রিলিজে দ্রুত স্যুইচ করার অনুমতি দেয়।

মোবাইল ডেভেলপমেন্টে ট্যাগ নামকরণের মান হল SemVer (সিম্যান্টিক ভার্সনিং): v1.2.3, যেখানে প্রথম সংখ্যা মেজর ভার্সন (ব্রেকিং চেঞ্জ), দ্বিতীয়টি মাইনর ভার্সন (নতুন বৈশিষ্ট্য), এবং তৃতীয়টি প্যাচ (সংশোধন)।

release শাখা main-এ মার্জ করার পরে একটি ট্যাগ তৈরি করা হয়। তারপর এই কমিটটি CI/CD-তে বিল্ড করা হয়, স্বাক্ষরিত হয় এবং অ্যাপ স্টোরে পাঠানো হয়। যদি ট্যাগে কোনো ত্রুটি পাওয়া যায়, তবে সেই ট্যাগ থেকে একটি hotfix শাখা তৈরি করা হয়।

# এনোটেটেড রিলিজ ট্যাগ তৈরি
git tag -a v2.4.1 -m "Release version 2.4.1"

# সার্ভারে ট্যাগ পাঠানো
git push origin v2.4.1

# রিপোজিটরিতে সব ট্যাগ দেখা
git tag -l "v2.*"

# একটি নির্দিষ্ট ট্যাগ থেকে hotfix শাখা তৈরি
git checkout -b hotfix/crash-fix v2.4.1

Git Flow শাখা শ্রেণিবিন্যাস

Git Flow-এ শাখা শ্রেণিবিন্যাস বোঝা সহযোগী ডেভেলপমেন্ট সঠিকভাবে সংগঠিত করার ভিত্তি। প্রতিটি শাখার প্রকারের নিজস্ব উৎস, উদ্দেশ্য এবং মার্জ নিয়ম রয়েছে।

• Main (স্তর 1) — মূল শাখা, শুধু রিলিজ ভার্সন ধারণ করে। রিপোজিটরি ইনিশিয়ালাইজ করার সময় তৈরি হয়।
• Develop (স্তর 2) — প্রকল্প শুরু হলে main থেকে তৈরি হয়। সমস্ত বৈশিষ্ট্যের ইন্টিগ্রেশন কোড ধারণ করে।
• Feature (স্তর 3) — develop থেকে তৈরি হয়। পৃথক বৈশিষ্ট্যের বিচ্ছিন্ন ডেভেলপমেন্ট।
• Release (স্তর 2) — develop থেকে তৈরি হয়। নির্দিষ্ট রিলিজ লঞ্চের জন্য প্রস্তুতি।
• Hotfix (স্তর 2) — main থেকে তৈরি হয়। গুরুতর প্রোডাকশন ত্রুটির জরুরি সংশোধন।

গুরুত্বপূর্ণ নিয়ম: feature কখনো সরাসরি main-এ মার্জ হয় না। feature → develop → release → main সঠিক মার্জ চেইন। এই নিয়ম ভঙ্গ করা পুরো Git Flow মডেলের উদ্দেশ্য নষ্ট করে।

main-এর সাথে কাজ করার কমান্ড উদাহরণ

একটি পরিস্থিতি বিবেচনা করুন: টিম রিলিজ v2.5.0-এর প্রস্তুতি সম্পন্ন করেছে। release শাখা পর্যালোচনা করা হয়েছে এবং main-এ মার্জ করার জন্য প্রস্তুত। মার্জ করার পরে, একটি ট্যাগ তৈরি করা হয় এবং রিলিজ প্রকাশিত হয়।

# main-এ সুইচ এবং আপডেট
git checkout main
git pull origin main

# যাচাইকৃত release শাখা মার্জ
git merge --no-ff release/2.5.0

# রিলিজ ট্যাগ তৈরি
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# main এবং ট্যাগ সার্ভারে পাঠানো
git push origin main --tags

--no-ff ফ্ল্যাগ (নো ফাস্ট-ফরওয়ার্ড) একটি মার্জ কমিট তৈরি নিশ্চিত করে, এমনকি যদি মার্জটি কেবল পয়েন্টার সরিয়ে করা যেত। এটি তথ্য সংরক্ষণ করে যে পরিবর্তনগুলি release শাখা থেকে এসেছে, যা ইতিহাস বিশ্লেষণ সহজ করে।

main-এর মাধ্যমে hotfix নিয়ে কাজ করা

যদি প্রোডাকশনে একটি গুরুতর ত্রুটি আবিষ্কৃত হয়, প্রক্রিয়াটি সাধারণ রিলিজ থেকে ভিন্ন। Hotfix main থেকে তৈরি করা হয় এবং সংশোধনের পরে, এটি main এবং develop উভয়েই মার্জ করা হয়।

যদি প্রোডাকশনে একটি গুরুতর ত্রুটি আবিষ্কৃত হয়, প্রক্রিয়াটি সাধারণ রিলিজ থেকে ভিন্ন। Hotfix main থেকে তৈরি করা হয় এবং সংশোধনের পরে, এটি main এবং develop উভয়েই মার্জ করা হয়।

# main থেকে hotfix শাখা তৈরি
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# সংশোধন এবং কমিট
git add src/fix/
git commit -m "Fix crash on login screen"

# hotfix আবার main-এ মার্জ
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# develop-এও hotfix মার্জ
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# hotfix শাখা মুছে ফেলা
git branch -d hotfix/2.5.1-crash-fix