Skip to main content

গিট




গিট নামটা শুনলে লোকের মাথায় প্রথমে কি আসে?
আমি যখন প্রথম গিটহ্যাবের নামটা শুনি, গিট শব্দটা শুনে ভেবেছি,
এখানে কি কোনকিছু দড়ির গিট দিয়ে বেঁধে রাখার ব্যাপার আছে নাকি!
পরে যখন বিষয়টি নিয়ে হালকাপাতলা জ্ঞান অর্জন করলাম,
অবাক হয়ে লক্ষ্য করলাম,
ব্যাপারটায় বেঁধে রাখার বিষয়ও আছে! 


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


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







এই সমস্যাগুলি একনিমিষে সমাধান করে গিট। গিট হচ্ছে একটি ডিস্ট্রিবিউটেড ভার্সন কন্ট্রোল সিস্টেম, যা মূলত একটা কোডের যেকোন সময়ে যেকোন পরিবর্তন ট্র্যাক করার ক্ষমতা রাখে। এখন মাথায় স্বাভাবিক কিছু প্রশ্ন আসছে, এই ভার্সন কন্ট্রোল বস্তুটা কি? এর সামনে ডিস্ট্রিবিউটেড ট্যাগ ঝুলানোর মানেটা কি?  




গিট কি?

গিট বুঝতে গিয়ে প্রথম যে কথা বলব তা হলো, 

গিট এবং গিটহ্যাব এক জিনিস নয়।  


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

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

ভার্সনগুলি প্যাকেজ করে করে রাখা হয়, এদেরকে বলা হয় একেকটা ব্রাঞ্চ।
একটা গিটে প্রোগ্রামাররা সাধারণত চারটা ব্রাঞ্চ রাখেন,
মাস্টার ব্রাঞ্চ, ডেভেলপ ব্রাঞ্চ, ফিচার ব্রাঞ্চ, রিলিজ ব্রাঞ্চ।


মাস্টার ব্রাঞ্চ,
যখন আপনি গিটে একটি রিপোজিটরি খুলে প্রথম কমিট করবেন, তখন গিট থেকে বাই ডিফল্ট একটা ভার্সন সৃষ্টি করবে, যেখানে ভার্সন থাকবে তাঁর নাম মাস্টার ব্রাঞ্চ, 
রিপোজিটরিতে ডাইরেক্ট কমিট করা যায় মাস্টার ব্রাঞ্চের মাধ্যমে।


ফিচার বা টপিক ব্রাঞ্চ।
এই ব্রাঞ্চে আপনি একটি নির্দিষ্ট কাজের জন্য কোড ডেভেলপ করবেন, হতে পারে সেটা সেই প্রজেক্টের নতুন কোন ফিচার তৈরি বা কোন বাগ ফিক্স করা।

সেই বাগ বা ফিচার তৈরী হয়ে এলে তা ডেভেলপ ব্রাঞ্চে ঠেলে দিয়ে 'গিট' দিয়ে বেঁধে দিব।
এবং বাকি কাজ ডেভেলপার ব্রাঞ্চের হাতে।
ডেভেলপার ব্রাঞ্চের কাজ এতগুলি ফিচার জোড়া দেয়া এবং রিলিজের জন্য প্রস্তুত করা।
শেষ ধাপে আসে রিলিজ ব্রাঞ্চ, এই ব্রাঞ্চ মোটামুটি শেষ হলে খোলা হয়। এবং এই ব্রাঞ্চে রিলিজের জন্য প্রস্তুত প্রজেক্ট রাখা হয়।

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

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


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



সুতরাং, গিট বলতে আমরা বুঝতে পারছি, এমন একটা সিস্টেমের এপ্লাইড রূপ যেখানে কোডের চেঞ্জ আপডেট দ্রুত পাওয়া যায়, যেকোন কোডের যেকোন সময়ের অবস্থা বা ভার্সন ট্র্যাক করা যায়। এবং তাতে আলাদা সার্ভারও লাগে না।

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



আশা করি, গিট কি সে ধারণা অন্তত পাওয়া গেছে এই লেখা থেকে।

এখন গিট কিভাবে ব্যবহার করতে হয়, সে আলোচনা এখন শুরু করলে অনেকেই হয়তো এক্ষুণি  ঘুমিয়ে পড়বেন, তাই সে আলোচনা হবে অন্যদিন।


তবে কিছু কি-ওয়ার্ড সম্পর্কে জানা যাক -

রিপোজিটরি -  গিট সংরক্ষণের জন্য একটি ডাটা স্ট্রাকচার, যা গিটের সমস্ত এলিমেন্ট ধারণ করে।
ক্লোন বা ফোর্ক - কোন রিপোজিটরি পুরো কপি করে নিজের কম্পিউটারে আনা।
লোকাল রিপোজিটরি - নিজের কম্পিউটারে থাকা রিপোজিটরি।
রিমোট রিপোজিটরি - যেই রিপোজিটরিতে একসঙ্গে অনেকে কাজ করছে।
কমিট - লোকাল রিপোজিটরিতে ভার্সন তৈরি।
পুশ - কোন ব্রাঞ্চে কমিট করা।


Comments

  1. সহজ সরল করে গিটের ধারনা দেয়া।সত্যি বলতে আমারো কিছু ব্যাপার ক্লিয়ার হলো। ধন্যবাদ রাইটারকে

    ReplyDelete
  2. GITHUB ER NAM SUNLEI MATHAI GIT LAGE..JAK EI POST TA PORAR POR ASA KORI KICHU GIT KOM LAGBE!!

    ReplyDelete
  3. Dip Bhai na bole, Dip Bhai mane sothik bhai.

    ReplyDelete

Post a Comment

Popular posts from this blog

অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং

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

অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং - এ SOLID

এই পোস্টে ব্যাখ্যা দেওয়া হলো SOLID এর। যা অবজেক্ট ওরিয়েন্টেড ডিজাইনে বহুল ব্যবহৃত।  SOLID এর পুরো অর্থ হলো - S – Single Responsibility Principle (SRP) O – Open Closed Principle (OCP) L – Liskov Substitution Principle (LSP) I – Interface Segregation Principle (ISP) D – Dependency Inversion Principle (DIP) Single Responsibility Principle (SRP) বলছে - A class should have one, and only one, reason to change. এর মানে হচ্ছে , আমাদের একেকটি ক্লাসকে অন্তত একটি এবং সর্বোচ্চ একটি  কাজেই ব্যবহার করতে হবে। ধরা যাক , Bank management system প্রজেক্টে , একটি ক্লাস খোলা  হলো account, এখানে দুইটি মেথড আছে = registration, deposite ।  একটি ক্লাসেই টাস্ক পড়লো দুইটি। আদতে সমস্যা না থাকলেও এটি ভাল  ওওপি ডিজাইন না কারণ এটি কে ভঙ্গ করছে। দুইটি কাজ দুই ক্লাসে করলে   SRP মেইন্টেইন হবে। Open Closed Principle (OCP) বলছে - You should be able to  extend a classes behavior, without modi...