ভার্সন কন্ট্রোল বেসিকস — সেন্ট্রালাইজড বনাম ডিস্ট্রিবিউটেড
এই পাঠে যা শিখবেন
- ভার্সন কন্ট্রোল সিস্টেম (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 — ব্রাঞ্চিং/কমিটিং দ্রুত হয়, কারণ সবকিছুই লোকাল।
নিচের কোড সেলে দুটো মডেলের একটি সরাসরি তুলনা — একটি dict দিয়ে চারটি মূল বৈশিষ্ট্য পাশাপাশি রাখা হয়েছে, যাতে পার্থক্যগুলো শুধু বর্ণনা না হয়ে সরাসরি ডেটা থেকে দেখা যায়।
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-এর বাকি পাঠগুলোতে এই লোকাল-প্রথম
মডেলটিই বারবার ফিরে আসবে।
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-এ, যেখানে ইতিহাস শুধু
সার্ভারে থাকে, একটি নতুন "ব্রাঞ্চ" ধারণাগতভাবে অনেক ভারী এবং প্রায়ই নেটওয়ার্ক অপারেশন জড়িত।
অনুশীলন
-
চিন্তা করুন: একটি টিম যদি এমন একটি অফিসে কাজ করে যেখানে ইন্টারনেট প্রায়ই অস্থির/বিচ্ছিন্ন হয়ে যায়, তাহলে Centralized বনাম Distributed VCS বেছে নেওয়ার সিদ্ধান্তে এই বাস্তবতা কীভাবে প্রভাব ফেলবে তা ব্যাখ্যা করুন।
এই পরিস্থিতিতে Distributed VCS (Git) স্পষ্টভাবে বেশি ব্যবহারিক — কারণ কমিট করা, ইতিহাস দেখা, এমনকি ব্রাঞ্চ করার মতো বেশিরভাগ দৈনন্দিন কাজ সম্পূর্ণ লোকালি চলবে, ইন্টারনেট সংযোগ অস্থির থাকলেও ডেভেলপাররা কাজ চালিয়ে যেতে পারবে। Centralized VCS-এ প্রতিটি কমিটের জন্য সার্ভারের সাথে সংযোগ দরকার হতো, তাই অস্থির ইন্টারনেটে কাজ ঘন ঘন ব্লক হয়ে যেত।
-
পরীক্ষা করুন: উপরের কোড সেলের
vcs_comparisondict-এ একটি নতুন ফিল্ড"offline_commit_possible"যোগ করুন (centralized-এFalse, distributed-এTrue),fieldsলিস্ট ওlabelsdict-এও যোগ করে Run চাপুন — নতুন সারিটি সঠিকভাবে প্রিন্ট হচ্ছে কিনা যাচাই করুন।তিনটি জায়গায় (দুটো dict-এর ভেতরে এবং
fields/labels-এ) সামঞ্জস্যপূর্ণভাবে"offline_commit_possible"যোগ করলে লুপটি স্বয়ংক্রিয়ভাবে সেটিকেও প্রিন্ট করবে, কারণ লুপটিfieldsলিস্টের ওপর ভিত্তি করে চলে, কোনো হার্ডকোডেড ফিল্ড-নাম ছাড়াই — এটি দেখায় তুলনা টেবিলটি genuinely ডেটা-চালিত, নতুন বৈশিষ্ট্য যোগ করা সহজ।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পরবর্তী পাঠ · git init, add, commit — থ্রি-ট্রি আর্কিটেকচার L30 এখন থেকে Git-এর অভ্যন্তরীণ মডেল শুরু হচ্ছে — working directory, staging area, ও repository।
- সফটওয়্যার ইঞ্জিনিয়ারিং কী ও Git কেন গুরুত্বপূর্ণ L01 L01-এর সেই "৫ জন ডেভেলপার, Git ছাড়া" প্রশ্নটি আবার পড়ে দেখুন — এখন উত্তরটা আরও স্পষ্ট হবে।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৮টি পাঠ M7 Git ফাউন্ডেশন এইমাত্র শুরু হলো — থ্রি-ট্রি আর্কিটেকচার, status/diff/log, .gitignore, ও আরও অনেক কিছু।