পাঠ ২৯ · ৫৮-এর মধ্যে · মডিউল ৭
Home / Courses / Software Engineering Principles & Git / Git ফাউন্ডেশন

ভার্সন কন্ট্রোল বেসিকস — সেন্ট্রালাইজড বনাম ডিস্ট্রিবিউটেড

Version control basics — centralized vs distributed
৮ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • ভার্সন কন্ট্রোল সিস্টেম (VCS) ঠিক কী সমস্যা সমাধান করে
  • Centralized VCS কীভাবে কাজ করে এবং এর genuine ঝুঁকি — সিঙ্গেল পয়েন্ট অফ ফেইলিউর
  • Distributed VCS (Git) কীভাবে ভিন্নভাবে কাজ করে — প্রতিটি ক্লোনে সম্পূর্ণ ইতিহাস
  • Python দিয়ে দুটোর একটি সরাসরি তুলনা করে concrete পার্থক্যগুলো দেখা

১ · ভার্সন কন্ট্রোল সিস্টেম (VCS) কী সমস্যা সমাধান করে

ভার্সন কন্ট্রোল সিস্টেমVersion Control System (VCS)সময়ের সাথে ফাইলের পরিবর্তন ট্র্যাক করে এমন সফটওয়্যার — যেকোনো আগের ভার্সন ফিরিয়ে আনা যায়, এবং একাধিক মানুষ একই ফাইলে কাজ করে তাদের পরিবর্তন মিলিয়ে নিতে পারে। হলো এমন সফটওয়্যার যা ফাইলের পরিবর্তন সময়ের সাথে ট্র্যাক করে — যেকোনো নির্দিষ্ট আগের ভার্সন ফিরিয়ে আনা যায়, এবং সবচেয়ে গুরুত্বপূর্ণভাবে, একাধিক মানুষকে একই ফাইলে কাজ করার একটি নির্দিষ্ট, সংগঠিত উপায় দেয়, যেখানে তাদের পরিবর্তনগুলো একত্রিত/মিলিয়ে নেওয়ার একটি পরিষ্কার পদ্ধতি থাকে। L01-এর অনুশীলনে প্রশ্ন করা হয়েছিল — ৫ জন ডেভেলপার একই ফোল্ডার শেয়ার করে সরাসরি ফাইল এডিট করলে কী সমস্যা হতে পারে? VCS হলো সেই সমস্যাগুলোর সরাসরি, concrete সমাধান।

২ · Centralized VCS — একটি মাত্র কেন্দ্রীয় সত্য

Centralized VCSCentralized Version Control Systemএকটি মাত্র কেন্দ্রীয় সার্ভারে পুরো রিপোজিটরি/ইতিহাস থাকে — প্রতিটি ডেভেলপারের কাছে শুধু একটি ওয়ার্কিং কপি থাকে, কোনো লোকাল ইতিহাস থাকে না। বাস্তব ঐতিহাসিক উদাহরণ: SVN (Subversion)। (উদাহরণ: SVN, একটি real, ঐতিহাসিকভাবে গুরুত্বপূর্ণ VCS) -এ একটি মাত্র কেন্দ্রীয় সার্ভার পুরো প্রামাণিক (authoritative) রিপোজিটরি ও ইতিহাস ধরে রাখে — প্রতিটি ডেভেলপারের "চেকআউট" আসলে শুধু ফাইলের একটি ওয়ার্কিং কপি, কোনো লোকাল ইতিহাস ছাড়াই। প্রতিটি অর্থপূর্ণ অপারেশন — ইতিহাস দেখা, কমিট করা — কেন্দ্রীয় সার্ভারে নেটওয়ার্ক অ্যাক্সেস দরকার করে। এখানেই একটি genuine, বাস্তব ঝুঁকি — যদি কেন্দ্রীয় সার্ভার অ্যাক্সেসযোগ্য না থাকে, তাহলে বেশিরভাগ VCS অপারেশনই অসম্ভব হয়ে পড়ে — এটিকে বলা হয় সিঙ্গেল পয়েন্ট অফ ফেইলিউর।

৩ · Distributed VCS — প্রতিটি ক্লোনে সম্পূর্ণ ইতিহাস

Distributed VCSDistributed Version Control Systemপ্রতিটি ডেভেলপারের লোকাল ক্লোনে পুরো রিপোজিটরির সম্পূর্ণ ইতিহাস থাকে — বেশিরভাগ অপারেশন সম্পূর্ণ লোকালি চলে, নেটওয়ার্ক লাগে শুধু অন্যদের সাথে সিঙ্ক্রোনাইজ করতে। উদাহরণ: Git — এই কোর্সের বাকি অংশজুড়ে। (উদাহরণ: Git — এখন থেকে এই কোর্সের বাকি সবটুকু জুড়ে) -এ প্রতিটি ডেভেলপারের লোকাল ক্লোনে পুরো রিপোজিটরির ইতিহাস থাকে, শুধু একটি ওয়ার্কিং কপি নয়। বেশিরভাগ অপারেশন — ইতিহাস দেখা, কমিট তৈরি করা, ব্রাঞ্চ করা — সম্পূর্ণ লোকালি ঘটে, কোনো নেটওয়ার্ক অ্যাক্সেস ছাড়াই। নেটওয়ার্ক দরকার হয় শুধুমাত্র অন্য কপির সাথে সিঙ্ক্রোনাইজ করার সময় (M9/L39-এ push/pull/fetch-এর বিস্তারিত আসবে)। এর genuine, বাস্তব সুবিধা: বেশিরভাগ কাজ অফলাইনেও চলে, কোনো সিঙ্গেল পয়েন্ট অফ ফেইলিউর নেই (প্রতিটি ক্লোনই পুরো ইতিহাসের একটি স্বাধীন, সম্পূর্ণ ব্যাকআপ), এবং — M8-এর সরাসরি foreshadow — ব্রাঞ্চিং/কমিটিং দ্রুত হয়, কারণ সবকিছুই লোকাল।

Centralized (SVN) কেন্দ্রীয় সার্ভার ডেভ ১ (কপি) ডেভ ২ (কপি) ডেভ ৩ (কপি) Distributed (Git) ডেভ ১ সম্পূর্ণ history ডেভ ২ সম্পূর্ণ history ডেভ ৩ সম্পূর্ণ history
Centralized VCS-এ প্রতিটি অপারেশন কেন্দ্রীয় সার্ভারের ওপর নির্ভরশীল — সার্ভার ডাউন মানেই কাজ থেমে যাওয়া। Distributed VCS-এ প্রতিটি ক্লোনই স্বয়ংসম্পূর্ণ — কোনো একক ব্যর্থতার বিন্দু নেই।

নিচের কোড সেলে দুটো মডেলের একটি সরাসরি তুলনা — একটি dict দিয়ে চারটি মূল বৈশিষ্ট্য পাশাপাশি রাখা হয়েছে, যাতে পার্থক্যগুলো শুধু বর্ণনা না হয়ে সরাসরি ডেটা থেকে দেখা যায়।

Python
vcs_comparison = {
    "centralized_vcs": {
        "requires_network_for_most_operations": True,
        "single_point_of_failure": True,
        "each_clone_has_full_history": False,
        "typical_example": "SVN",
    },
    "distributed_vcs": {
        "requires_network_for_most_operations": False,
        "single_point_of_failure": False,
        "each_clone_has_full_history": True,
        "typical_example": "Git",
    },
}

fields = [
    "requires_network_for_most_operations",
    "single_point_of_failure",
    "each_clone_has_full_history",
    "typical_example",
]
labels = {
    "requires_network_for_most_operations": "বেশিরভাগ অপারেশনে নেটওয়ার্ক লাগে?",
    "single_point_of_failure": "সিঙ্গেল পয়েন্ট অফ ফেইলিউর আছে?",
    "each_clone_has_full_history": "প্রতিটি ক্লোনে সম্পূর্ণ history থাকে?",
    "typical_example": "বাস্তব উদাহরণ",
}

print("Centralized VCS  বনাম  Distributed VCS")
print("=" * 42)
for f in fields:
    c = vcs_comparison["centralized_vcs"][f]
    d = vcs_comparison["distributed_vcs"][f]
    print(f"- {labels[f]}")
    print(f"    Centralized (SVN):  {c}")
    print(f"    Distributed (Git):  {d}")

    
সবচেয়ে স্পষ্ট কলামটি লক্ষ্য করুন — requires_network_for_most_operations। এটিই প্র্যাকটিক্যাল পার্থক্যের মূল কারণ: Distributed VCS-এ নেটওয়ার্ক False, মানে আপনি ট্রেনে, প্লেনে, বা যেকোনো অফলাইন জায়গায় বসেও কমিট, ব্রাঞ্চ, বা ইতিহাস দেখার কাজ করতে পারবেন — M7-এর বাকি পাঠগুলোতে এই লোকাল-প্রথম মডেলটিই বারবার ফিরে আসবে।
মূল কথা · Key takeaway

Centralized VCS একটি একক কেন্দ্রীয় সত্যের ওপর নির্ভর করে — সহজবোধ্য, কিন্তু ঝুঁকিপূর্ণ। Distributed VCS (Git) প্রতিটি ক্লোনকে সম্পূর্ণ, স্বাধীন করে তোলে — এই একটি স্থাপত্যগত সিদ্ধান্তই ব্যাখ্যা করে কেন Git অফলাইনে কাজ করে, কেন কোনো একক ব্যর্থতার বিন্দু নেই, আর কেন M7-এর পরের পাঠ (L30) থেকে শুরু করে সবকিছুই প্রথমে লোকালি ঘটবে, নেটওয়ার্কের কোনো প্রয়োজন ছাড়াই।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ Centralized VCS-এ যদি কেন্দ্রীয় সার্ভারের হার্ড ডিস্ক পুরোপুরি নষ্ট হয়ে যায় (কোনো ব্যাকআপ ছাড়াই), তাহলে কী ঘটবে? Distributed VCS-এ একই ঘটনা ঘটলে পরিস্থিতি কেমন আলাদা হবে?

Centralized VCS-এ পুরো ইতিহাস (প্রতিটি পুরোনো কমিট) স্থায়ীভাবে হারিয়ে যেতে পারে, কারণ শুধু সার্ভারেই সম্পূর্ণ ইতিহাস ছিল — ডেভেলপারদের কাছে শুধু ওয়ার্কিং কপি ছিল, ইতিহাস নয়। Distributed VCS-এ, প্রতিটি ডেভেলপারের লোকাল ক্লোনেই সম্পূর্ণ ইতিহাস আছে, তাই যেকোনো একটি ক্লোন থেকেই সম্পূর্ণ রিপোজিটরি পুনরুদ্ধার করা যায় — এটিই "প্রতিটি ক্লোনই একটি সম্পূর্ণ, স্বাধীন ব্যাকআপ" ধারণার concrete বাস্তব ফলাফল।

প্র ০২ Distributed VCS-এ "নেটওয়ার্ক দরকার হয় শুধু সিঙ্ক্রোনাইজ করতে" — তাহলে দুইজন ডেভেলপার সম্পূর্ণ আলাদাভাবে অফলাইনে কাজ করলে তাদের কাজ কি কখনো একসাথে মেলাতে হবে না?

মেলাতে হবে — কিন্তু সেই মেলানোর কাজটি (সিঙ্ক্রোনাইজেশন) একটি আলাদা, ব্যাখ্যাযোগ্য ধাপ, যা শুধু তখনই ঘটে যখন তারা একে অপরের সাথে যোগাযোগ করতে (push/pull, M9/L39) প্রস্তুত হয়। এর আগ পর্যন্ত প্রতিটি ডেভেলপার সম্পূর্ণ স্বাধীনভাবে, সংঘর্ষ ছাড়াই কমিট করে যেতে পারে — Centralized VCS-এর মতো প্রতিটি কমিটে তাৎক্ষণিকভাবে কেন্দ্রীয় সার্ভারের সাথে সমন্বয় করার দরকার নেই।

প্র ০৩ উপরের কোড সেলের comparison dict-এ each_clone_has_full_history ফিল্ডটি সরাসরি কীভাবে ব্যাখ্যা করে যে Git-এ ব্রাঞ্চ তৈরি করা এত দ্রুত হয় (M8-এ আসবে)?

যেহেতু পুরো ইতিহাস ইতিমধ্যেই লোকালি বিদ্যমান (each_clone_has_full_history: True), তাই একটি নতুন ব্রাঞ্চ তৈরি করতে গেলে নেটওয়ার্ক থেকে কোনো ডেটা আনতে হয় না, এমনকি কোনো ফাইলও কপি করতে হয় না — শুধু একটি নতুন নাম-পয়েন্টার লোকালি তৈরি হয় বর্তমান কমিটের দিকে। Centralized VCS-এ, যেখানে ইতিহাস শুধু সার্ভারে থাকে, একটি নতুন "ব্রাঞ্চ" ধারণাগতভাবে অনেক ভারী এবং প্রায়ই নেটওয়ার্ক অপারেশন জড়িত।

অনুশীলন

  1. চিন্তা করুন: একটি টিম যদি এমন একটি অফিসে কাজ করে যেখানে ইন্টারনেট প্রায়ই অস্থির/বিচ্ছিন্ন হয়ে যায়, তাহলে Centralized বনাম Distributed VCS বেছে নেওয়ার সিদ্ধান্তে এই বাস্তবতা কীভাবে প্রভাব ফেলবে তা ব্যাখ্যা করুন।

    এই পরিস্থিতিতে Distributed VCS (Git) স্পষ্টভাবে বেশি ব্যবহারিক — কারণ কমিট করা, ইতিহাস দেখা, এমনকি ব্রাঞ্চ করার মতো বেশিরভাগ দৈনন্দিন কাজ সম্পূর্ণ লোকালি চলবে, ইন্টারনেট সংযোগ অস্থির থাকলেও ডেভেলপাররা কাজ চালিয়ে যেতে পারবে। Centralized VCS-এ প্রতিটি কমিটের জন্য সার্ভারের সাথে সংযোগ দরকার হতো, তাই অস্থির ইন্টারনেটে কাজ ঘন ঘন ব্লক হয়ে যেত।

  2. পরীক্ষা করুন: উপরের কোড সেলের vcs_comparison dict-এ একটি নতুন ফিল্ড "offline_commit_possible" যোগ করুন (centralized-এ False, distributed-এ True), fields লিস্ট ও labels dict-এও যোগ করে Run চাপুন — নতুন সারিটি সঠিকভাবে প্রিন্ট হচ্ছে কিনা যাচাই করুন।

    তিনটি জায়গায় (দুটো dict-এর ভেতরে এবং fields/labels-এ) সামঞ্জস্যপূর্ণভাবে "offline_commit_possible" যোগ করলে লুপটি স্বয়ংক্রিয়ভাবে সেটিকেও প্রিন্ট করবে, কারণ লুপটি fields লিস্টের ওপর ভিত্তি করে চলে, কোনো হার্ডকোডেড ফিল্ড-নাম ছাড়াই — এটি দেখায় তুলনা টেবিলটি genuinely ডেটা-চালিত, নতুন বৈশিষ্ট্য যোগ করা সহজ।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
MVC ও MVVM প্যাটার্ন