আমরা এখানে জানবো: কিভাবে গিটহাবে একটা স্ট্যাটিক ডেমো সাইট তৈরি করা যায়।

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

যা যা জানা থাকা লাগবে

অন্তত একটা HTML ফাইল বানানো জানা লাগবে। এছাড়া, যখন যা জানার দরকার পড়বে, একটু ঢু মেরে সেটা জেনে নিলেই চলবে।

কিভাবে কী করতে হয়?

প্রথম ধাপ: গিটহাবে কোড ডিপ্লয়

কাজটা খুবই সহজ।

ধরে নিচ্ছি আপনার একটা স্ট্যাটিক সাইট আগে থেকেই বানানো আছে যেখানে একটা index.html আছে। (যেমন আমরা একটা স্ট্যাটিক সাইট বানিয়ে রেখেছি)

এই ডিরেক্টরিটিকে এবারে একটা গিট রিপো বানিয়ে ফেলি। গিট কিভাবে ব্যবহার করতে হয়, জানা না থাকলে চট করে একটা ঢু মেরে শিখে ফেলা যাক:

এবারে git bash-এ কমান্ড লিখি:

git init
git add -A
git commit -m "Initial Commit"

এবারে গিটহাবে প্রোজেক্টটা তুলে দিতে হলে গিটহাবে গিয়ে একটা ফাঁকা রিপো তৈরি করে নিই: New Repository-তে গিয়ে শুধু একটা নাম দেই, আর কিচ্ছু দেয়া লাগবে না। এবারে Create Repository-তে ক্লিক করলে আপনাকে ইন্সট্রাকশন দিবে কী করা লাগবে। সেখান থেকে এই লাইনটা লেখা যাক গিট ব্যাশ-এ:

git remote add origin https://github.com/{username}/{repository-path}.git

বুঝতেই পারছেন, এখানে {username} আর {repository-path} আপনার পাথ আর ইউযারনেম দিয়ে পূরণ করবেন। এতে গিটহাবের ঐ রিপোযিটোরিটা আমরা রিমোট হিসেবে যোগ হয়ে যাবে। ব্যাস, এবার আপনার কোডগুলো গিটহাবে তুলে দিন:

git push origin master

শেষ ধাপ: গিট পেজ তৈরি করা

পদ্ধতি ১ : মাস্টার ব্রাঞ্চকেই ব্যবহার করা

যেহেতু আমরা আমাদের master ব্রাঞ্চে যা যা আছে, সেটাকেই Demo আকারে দেখাতে চাচ্ছি, আমাদের জন্য কাজটা খুব সহজ। গিটহাবে আপনার রেপোযিটোরি’র Settings পাতায় যান (ইউআরএলটা এরকম হবে: https://github.com/{username}/{repository-name}/settings)

এবারে নিচের দিকে Github Pages ব্লকের Source অংশের None লেখা ড্রপডাউন থেকে বাছাই করে দিন master branch। তারপর Save বোতাম চাপুন। কাজ শেষ।

আপনার Demo সাইটটা আপনার master ব্রাঞ্চের তথ্য (index.html) নিয়ে তৈরি হয়ে গেছে। দেখা যাবে এরকম একটা পাথে:

https://{username}.github.io/{repository-name}/

কাজ শেষ।

পদ্ধতি ২ : ব্রাঞ্চ করে নেয়া

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

এই ব্রাঞ্চটা দিয়ে গিটহাবে Git Pages কাজ করে, আর ব্রাঞ্চের নামটাও নির্ধারিত gh-pages। সুতরাং চট করে গিট ব্যাশে লিখে ফেলুন:

git checkout -b gh-pages

হলো কী – gh-pages নামে একটা গিট ব্রাঞ্চ তৈরি হয়ে গেলো আর আমরা সেই ব্রাঞ্চে চলেও এলাম। যদি গিট ব্রাঞ্চ আমরা বুঝে থাকি, তাহলে জানি, master ব্রাঞ্চে যা আছে এই নতুন ব্রাঞ্চেও এখন তা তা আছে। অর্থাৎ আমাদের index.html ফাইলটাও এখানে আছে। এই ব্রাঞ্চে আপনি যেমন যেমন চাচ্ছেন, তেমন তেমন ইচ্ছেমতো পরিবর্তন করে নিন, আপনার ডেমো সাইটটা। তারপর গিট অ্যাড আর গিট কমিট করে গিট পুশ করে দিন নতুন ব্রাঞ্চটা:

git push origin gh-pages

এটা স্বয়ংক্রীয়ভাবেই নিম্নোক্ত পাথে আপনার ডেমো সাইটটা তৈরি করে দিবে:

https://{username}.github.io/{repository-name}/

বাড়তি তথ্য

• ডেমো সাইটের জন্য gh-pages ব্রাঞ্চটা যে বাধ্যতামূলক (ম্যান্ডেটরি) না, সেটা আশা করি বুঝে ফেলেছেন। সেক্ষেত্রে যে ব্রাঞ্চ থেকেই ডেমো দেখান না কেন, তা Settings পাতায় বাছাই করে দিলেই কাজ শেষ।
• আপনি যদি চান নিজস্ব ডোমেইন থেকেও ডেমো পাতাটি দেখা যাক, যেমন: example.com লিখে এন্টার করলেও যেন এই সাইটটা দেখা যাকে, তাহলে সেটাও করতে পারবেন: Custom domain অংশে http://example.com/ লিখে দিতে হবে। কিন্তু শর্ত হচ্ছে ঐ ডোমেইনের CNAME রেকর্ডে বলে দিতে হবে যে, এই হোস্টটা ব্রাউজ করতে হবে।
• আপনি যদি Jekyll^ কিংবা অন্য কোনো স্ট্যাটিক সাইট জেনারেটরে অভ্যস্থ হন, তাহলে নিশ্চিন্তে আপনি সেসব সাইটও গিটহাব পেজেস-এ ডিপ্লয় করতে পারেন। এছাড়া গিটহাবেই Automatic Page Generator রয়েছে, সেটা দিয়েও আপনি Markdown সিনট্যাক্সে আপনার স্ট্যাটিক সাইট বানিয়ে নিতে পারেন।

উপসংহার

সুতরাং আশা করি এখন থেকে আপনার করা HTML, CSS, JavaScript-এর স্ট্যাটিক কাজগুলোর একটা ডেমো আমরা অনায়াসে দেখতে পারবো ইনশাল্লাহ।

আমাদের স্ট্যাটিক সাইটের ডেমোটা দেখা যাক:

https://mayeenulislam.github.io/tuts-nano-github-pages/

The post গিটহাবে স্ট্যাটিক ডেমো সাইট বানানোর কৌশল appeared first on Tuts by Mayeenul Islam.

• গিট ব্যবহারের একেবারে প্রাথমিক জ্ঞান : পর্ব ১, এবং
• গিট ব্যবহারের একেবারে প্রাথমিক জ্ঞান : পর্ব ২

এবারে আমরা জানি গিট কাকে বলে, কত প্রকার, কী কী 🙂 । তাই আজকে আমরা আলোচনা করছি গিট ব্রাঞ্চিং নিয়ে।

অন্যান্য ভার্ষন নিয়ন্ত্রণ সফ্‌টওয়্যারের সাথে গিট-এর পার্থক্য করতে গেলে অনেককেই বলতে শুনি যে, গিটে ব্রাঞ্চিং যথেষ্ট cheap। এই cheap কথাটার মানে যেমন স্বল্প খরচসাপেক্ষ, তেমনি এর দ্বারা বোঝায় এটা যথেষ্ট সহজ, দ্রুত এবং ঝামেলাহীনও। স্বস্তা, কারণ খুব অল্প রিসোর্স ব্যবহার করেই গিট ব্রাঞ্চিং করা যায় অগণিত।

কী এই গিট ব্রাঞ্চিং? ব্রাঞ্চ শব্দটা শুনলেই ব্যাংকের ব্রাঞ্চের কথা মনে হয় না? ঠিকই আছে। ব্রাঞ্চিং সেরকমইতো। এবারে একটা ঘটনা দেখা যাক:

আমি মূল রাস্তা ধরে হাঁটছি। আমার সাথে ২জন বন্ধু আছেন।

আমি মূল রাস্তা ধরে আরো এক মাইল এগোলাম, এবারে আমার সাথে আরো ২জন বন্ধু যোগ দিলেন। অর্থাৎ মোট বন্ধুর সংখ্যা ৪জন।

এবারে আমি রাস্তা বদল করলাম। ডানের গলিতে ঢুকে গেলাম। এই গলিতে আমি আরো ২জন বন্ধু জুটিয়ে নিলাম। মোট বন্ধু: [আগের] ৪জন + [নতুন] ২জন = ৬জন।

আরো এক মাইল এগোলাম, আরো ৪জন বন্ধু জুটিয়ে নিলাম, মোট বন্ধু হলেন ৬+৪=১০জন।

এমন সময় হঠাৎ, পথে আপনার সাথে দেখা। আপনি জিজ্ঞেস করলেন, আপনি এই রাস্তায় কেন? আপনার মূল রাস্তা কোথায়? আমি বললাম, সেটাতো ফেলে এসেছি। আপনি বললেন, বাহ, দারুণ! ১০জন বন্ধু নিয়ে পথ চলছেন! মূল রাস্তাতে আপনার কয় জন বন্ধু ছিলেন? বললাম, ৪জন। কেন, ১০জন নয় কেন? কারণ, বাকি ৬জন যে আমি ডানের গলিতে পেয়েছি।

হ্যা, ব্রাঞ্চিং-এর ক্ষেত্রে এই ব্যাপারটাই ঘটে। যতক্ষণ পর্যন্ত আপনি মূল রাস্তা ধরে হাঁটছেন, ততক্ষণ পর্যন্ত যা ঘটেছে, গলিপথে বা শাখা পথে ঢোকার সময় শাখা পথ কিন্তু ততটুকুর খবরই জানে। আর গলিপথে ঢুকে আপনি কতটুকু এগিয়েছেন, কী করেছেন, মূল পথ কিন্তু তার খবর জানে না।

স্বস্তাশ্রেণীর একটা উদাহরণ হয়ে গেল, তবু এটা বুঝলে ব্রাঞ্চিং-এর কিছুটা ধারণা পাওয়া যাবে। …কথা না বাড়িয়ে এবারে হাত নোংরা করা যাক…

গিট ব্রাঞ্চ তৈরি করা

নিজের কম্পিউটারে একটা ডিরেক্টরি (ফোল্ডার) তৈরি করি test নামে। এই ডিরেক্টরিতে ১টা ফাইল তৈরি করি index.html এবং সেই ফাইলে কিছু একটা লিখে দিই। যা ইচ্ছা লিখতে না চাইলে নিচের মতো লিখে একটা ভ্যালিড HTML ফাইল বানিয়ে নেয়া যেতে পারে:

<!DOCTYPE html>
<html lang="en">
   <head>
      <meta charset="UTF-8">
      <title>Testing Git Branching</title>
   </head>
   <body>
      <h1>Testing Git Branching</h1>
   </body>
</html>

ব্রাউযারে index.html ফাইলটা খুললে দেখা যাবে, সাদা দৃশ্যপটে কালো লেখা স্পষ্ট দেখা যাচ্ছে। এবারে সেই ডিরেক্টরি-পাথে git bash চালু করি (মাউসের ডান বোতামে git bash here চেপে – বিস্তারিত)। যেহেতু এটা শ্রেফ একটা ডিরেক্টরি, তাই একে আগে গিট রেপোযিটোরিতে রূপান্তর করি: ব্যাশ-এ লিখি: git init। ব্যস, আমাদের ১টা ফাইলসমৃদ্ধ ডিরেক্টরিটা একটা গিট রেপোযিটোরিতে বদলে গেলো। আমরা এবারে আমাদের প্রথম commit করি, মানে আক্ষরিক অর্থে ভার্ষন নিয়ন্ত্রণ শুরু করি…। (দেখুন পর্দাদৃশ্য ১)

ভালো করে খেয়াল করে দেখুন, ঠিক প্রথম লাইনটার পরে পরের লাইনগুলোতে কোনো বিশেষ কিছু আপনার চোখে পড়ছে কিনা… ‘(master)‘ কথাটা যোগ হয়েছে প্রথম লাইনের পরে, এবং সেটা প্রতিবারই আপনার সাথে সাথে চলছে।

কী এই master?

কমান্ড: git branch

কমান্ড দিই:

$ git branch

অর্থাৎ, আমরা গিটকে বললাম, গিট তোমার ব্রাঞ্চের খবর জানাও। এবারে সে আমাদের দেখাবে:

* master

আবারো সেই master। মানে সে জানালো, তোমার ব্রাঞ্চ বা শাখা হচ্ছে master। ঠিকইতো আছে, এখনও তো আমি মূল রাস্তায় আছি। তো আমাকে যদি কেউ জিজ্ঞেস করে, কোন রাস্তায়? আমি বলবো, মূল রাস্তায় (master) – এর বাইরে তো কিছু বলার প্রশ্নই উঠে না, তাই না?

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

কমান্ড: git branch <branch-name>

ব্যাশে লিখলাম:

$ git branch style

সে আমাদের কিছু না বললেও আসলে style নামে একটা ব্রাঞ্চ তৈরি করা শেষ। আপনার নামের ডানদিকে, এখনও দেখুন (master) কথাটাই আছে, তার মানে আমরা এখনও master ব্রাঞ্চেই রয়েছি। কিন্তু আমাদেরতো নতুন খোলা style ব্রাঞ্চে কাজ করার কথা। আসুন তবে নতুন পথ ধরি…

গিট ব্রাঞ্চ অদলবদল

কমান্ড: git checkout <branch-name>

ব্যাশে লিখি:

$ git checkout style

টিপ্‌স:
ব্রাঞ্চ তৈরি আর বদল করার জন্য দুটো কমান্ড শিখেছি। শর্টকাটে একটা কমান্ড দিয়েও কাজটা করা যায়, লিখতে হবে:
git checkout -b <branch-name>

সে বলছে, হ্যা, style ব্রাঞ্চে বদলে নিয়েছি। আমরা কিন্তু এবারে নতুন রাস্তায় উঠে গেছি। নতুন রাস্তাকে যদি জিজ্ঞেস করি, তোমার কাছে কয়টা ফাইল আছে? বলবে, ১টা (index.html)। তোমার কাছে কয়টা commit রেকর্ড আছে? বলবে, ১টা। আমরা যে আসলেই master ব্রাঞ্চ থেকে বদলে style ব্রাঞ্চে চলে এসেছি, সেটা আমরা এবারে নিজের নামের ডানদিকে দেখতেও পাচ্ছি, (master) নামটা বদলে ‘(style)‘ হয়ে গেছে। তবু আমরা একটু যাচাই করে দেখলাম:

$ git branch
  master
* style

আশা করি বুঝে গেছি যে, ঐ স্টারটা (asterisk – *) আসলে আমাদের দেখায় আমার সক্রীয় ব্রাঞ্চ কোনটা।

এবারে আমাদের ডিরেক্টরিতে (ফোল্ডারে) একটা ফাইল তৈরি করলাম, style.css এবং তাতে লিখলাম:

body{
   background-color: black;
   color: white;
}

আর index.html ফাইলটা খুলে স্টাইলশিটটা লিংক করে দিলাম, <title> ট্যাগের ঠিক নিচেই লিখলাম:

<link rel="stylesheet" href="style.css">

ব্যস, আমাদের সাইটে একটা দারুণ স্টাইলিং করা হয়ে গেল 🙂 ।

এবারে ব্যাশে git status জানতে চাইলে দেখাবে index.html পরিবর্তন হয়েছে, আর style.css নতুন যোগ হয়েছে, তাই untracked। আমরা সব পরিবর্তনকে স্টেজ করে তারপর আরেকটা কমিট করি (ধরা যাক, কমিট বার্তা দিয়েছি: “styles added”)। এবারে গিটের লগ (কমান্ড: git log) পরখ করলে দেখা যাবে দুটো কমিট হয়েছে:

• একটা কমিট হয়েছিল master ব্রাঞ্চে থাকা অবস্থায় (বার্তা: “Initial Commit”)
• আরেকটা কমিট এইমাত্র করলাম, style ব্রাঞ্চে থাকা অবস্থায় (বার্তা: “styles added”)

আমরা যা শিখেছিলাম, সব মিলে গেল। মূল রাস্তা পর্যন্ত যা যা হয়েছিল, সব শাখা রাস্তায় এসেছে। আর শাখা রাস্তায়ও নতুন বন্ধু জুটিয়ে নিয়েছি (নতুন ফাইল কিংবা নতুন লাইন কিংবা পরিবর্তিত লাইন)। ব্রাউযারে index.html ফাইলটা খুললে দেখা যাবে, কালো দৃশ্যপটে সাদা লেখা স্পষ্ট দেখা যাচ্ছে।

আসল মজাটা এখনও শুরু হয়নি। আসল মজাটা দেখা যাবে, যদি আমরা এখন আবার master ব্রাঞ্চে ফিরে যাই। ব্যাশ খুলে লিখলাম:

$ git checkout master

master ব্রাঞ্চে নিয়ে চলো। সে বরাবরের মতোই বলবে:

Switched to branch 'master'

হ্যা, master ব্রাঞ্চে, মানে মূল রাস্তায় ফিরে এসেছি। এবারে ডিরেক্টরিটা (ফোল্ডার) খুলে একটু দেখুন তো…

অ্যাবরাক্যাডাবরা! ছুহ মন্তর ছুহ, যাদু মন্তর ছুহ!

আমাদের style.css হাওয়ায় মিলিয়ে গেছে। শুধু তা-ই নয়, index.html ফাইলটা খুলে দেখুন, স্টাইলশিটটা লিংক করেছিলেন যে লাইন লিখে, সেই লাইনটিও নেই। কী মনে করে ব্রাউযার খুলে দেখলেন, কালো রঙের ব্যাকগ্রাউন্ডও হাওয়া। মাথায় হাত: হায়, হায়! আমার এতো কষ্টের কোড সব মুছে ফেললো গিট!

না বৎস, ধৈর্য্যই ধর্ম্ম!

গিট একেবারে ঠিক কাজটিই করেছে। আপনি গিটকে জিজ্ঞেস করেছেন, গিট তোমার মূল রাস্তার খবর বলো। সে বলছে, ১টা ফাইল, আর ১০ লাইনের কোড। বাকি যা যা যোগ করেছিলেন এই রেপোযিটোরিতে, সব করেছেন নতুন রাস্তায় গিয়ে। পরে যে রাস্তা যোগ হয়েছে, আগের রাস্তা তার খবর কী করে রাখবে? তাই সে আসলে নতুন রাস্তার খবর জানে না। …শান্ত হোন, আপনার কোড হারিয়ে যায়নি। আপনার কোড এখনও নতুন রাস্তায় আছে ঠিকই। আবারও যদি নতুন রাস্তায় ঘুরতে যান, ঠিকই সবকিছু ঠিকঠাক পাবেন, সেখানকার বন্ধুদেরও পাবেন। ব্যাশে লিখুন:

$ git checkout style

দেখুন তো সব ফিরে এসেছে কিনা? …এবার একটু প্রাণ খুলে হাসুন 😀 ।

আমি যখন প্রথম ব্যাপারটা লক্ষ করেছিলাম, আমি ব্যাশটাকে একপাশে এমনভাবে সরিয়ে রেখেছিলাম, যাতে মনিটরের আরেক পাশে ডিরেক্টরিটাও দেখতে পারি। তারপর ব্রাঞ্চ থেকে ব্রাঞ্চে একটু চেকআউট করে এই মজার দৃশ্য দেখেছিলাম মন ভরে। দারুণ লেগেছিল ব্যাপারটা আমার কাছে। 🙂

ব্যস, ব্রাঞ্চিং শেখা শেষ।

গিট ব্রাঞ্চ মিশিয়ে নেয়া

এবারে যদি আপনার style ব্রাঞ্চে করা স্টাইলগুলো দেখে আপনার মন পরিবর্তন করেন, চিন্তা করেন যে, নাহ্‌! ভালোইতো লাগছে কালো ব্যাকগ্রাউন্ডটা (নতুন রাস্তার বন্ধুরা তো ভালো মানুষই)। এক কাজ করি না কেন, মুল প্রজেক্টেই নিয়ে আসি না কেন (মূল রাস্তায়ই নিয়ে আসি বন্ধুদের)? যেই ভাবা, সেই কাজ। আপনি এবারে আপনার style ব্রাঞ্চটিকে master ব্রাঞ্চের সাথে মিলিয়ে নিবেন (merge করবেন)।

কমান্ড: git merge <branch-name>

গাছের একটা ডাল কাটবেন, তো সেটা কি ডালে বসে কাটবেন, নাকি গাছের কান্ডে বসে কাটবেন? …তো সেজন্যই আগে কান্ডে ফিরে আসুন (মানে যে ব্রাঞ্চের মধ্যে অন্য ব্রাঞ্চটাকে মিলিয়ে নিতে চলেছেন)। আর তারপর ডালটার বিহিত করুন (master ব্রাঞ্চে style ব্রাঞ্চটা মার্জ্‌ করুন):

$ git checkout master
$ git merge style

এতে সে দেখাবে: এই হয়েছে, সেই হয়েছে, তোমার দুটো ব্রাঞ্চ মার্জ করে ফেলেছি। অর্থাৎ style ব্রাঞ্চে যা যা করেছিলে, এখন তা হুবহু master ব্রাঞ্চেও যোগ/বিয়োগ করে মিলিয়ে নিয়েছি। তোমার সবকিছু রেডি। ব্যাশে লক্ষ করুন, আপনি এখন master ব্রাঞ্চে আছেন। ডিরেক্টরিতে লক্ষ করুন, style.css ফাইলটা দেখা যাচ্ছে। এই অবস্থায় আপনি ব্রাউযার রিলোড করে দেখুন, আপনার ওয়েবসাইট কালো ব্যাকগ্রাউন্ডে সাদা লেখা দেখাচ্ছে।

গিট ব্রাঞ্চ রিমোটে তোলা

যদি আপনি আপনার রেপোযিটরিটা সার্ভারে কোথাও ব্যাকআপ রাখেন, হতে পারে সেটা github, gitlab, bitbucket, meat ইত্যাদি আপনার নিজস্ব git সার্ভার কিংবা শ্রেফ কোনো শেয়ার্ড রেপোযিটরি। আমরা বোধহয় আলাদা করে গিট রিমোট যোগ করা দেখিনি। খুবই মামুলি কাজ, আমরা এবারে সেটা করে নিই। ধরা যাক, আমাদের গিটহাবে একটা রেপোযিটরি আছে test নামে, তার পাথটা নিলাম, তারপর ব্যাশে লিখলাম:

$ git remote add origin https://github.com/mayeenulislam/test.git

ব্যস, তাতেই হয়ে গেল। origin নামে আমাদের একটা রিমোট যোগ হয়ে গেল, অর্থাৎ একটা সার্ভার কানেক্ট করে ফেললাম আমরা আমাদের এই রেপোযিটরিতে। এবারে আমরা চাচ্ছি, আমাদের style ব্রাঞ্চটা [মার্জ করি বা না করি], সেটা সার্ভারেও তুলে দিতে।

কমান্ড: git push <remote-name> <branch-name>

ব্যাশে লিখতে হবে, সেই পুরোন জানা কমান্ডটি, ধাক্কা দিয়ে তুলে দাও:

$ git push origin master
$ git push origin style

প্রথমে আমরা master ব্রাঞ্চটাকে ধাক্কা দিয়ে তুলে তারপর style ব্রাঞ্চটাকে ধাক্কা দিয়ে তুলে দিচ্ছি। (ইউযারনেম, পাসওয়ার্ড চাইলে দিয়ে দিতে হবে)

ব্রাঞ্চগুলোকে একবার পরখ করে দেখে নেয়া যেতে পারে:

$ git branch --all
* master
  style
  remotes/origin/master
  remotes/origin/style

গিট ব্রাঞ্চ মুছে ফেলা

যেহেতু আমাদের style ব্রাঞ্চের কাজটা আমরা মূল ব্রাঞ্চে (master) মিশিয়ে নিয়েছি, আর ঐ ব্রাঞ্চ নিয়ে কাজ করারও ইচ্ছে নেই, তাই এখন আমরা চাইলে ব্রাঞ্চটা মুছে ফেলতে পারি। নতুন রাস্তার বন্ধুরা যদি আমার রাস্তায় চলে আসে, নাইবা থাকলো সে নতুন রাস্তা। 🙂

কমান্ড: git branch -d <branch-name>

মুছে ফেলার কাজটা খুব সোজা, কান্ডে থাকা অবস্থায় কিন্তু ডাল কাটতে হবে, অর্থাৎ master ব্রাঞ্চে থাকা অবস্থায় শাখা মুছে ফেলার কমান্ড দিতে হবে:

সতর্ক থাকুন:
ব্রাঞ্চ ডিলিট করার জন্য -d লেখাটা নিরাপদ। এতে সে মার্জ করতে না পারলেও কারণ দেখাবে। আর যদি আমরা -d না লিখে -D লিখতাম, তাহলে কিন্তু সে জোর করে ব্রাঞ্চটা ডিলিট করে দিত।

$ git branch -d style

অর্থাৎ, গিট, style ব্রাঞ্চটাকে মুছে ফেলো তো। এতে সে লোকাল রেপোযিটরি থেকে style ব্রাঞ্চটা মুছে ফেলবে। পরখ করে দেখে নিতে পারেন:

$ git branch --all
* master
  remotes/origin/master
  remotes/origin/style

আমরা যেহেতু style ব্রাঞ্চটাকে master ব্রাঞ্চে মার্জ করেই ফেলেছি, সেটাকে তাহলে আর সার্ভারে তুলে দেখানোর কোনো মানেই ছিল না। ভুয়া একটা কাজ করেছি। কিন্তু তবু শিখে রাখলাম, মার্জ করি বা না করি, উভয় অবস্থায়ই ব্রাঞ্চকে রিমোটে তুলে রাখা যায়। কিন্তু এইমাত্র আমরা লোকাল style ব্রাঞ্চটাকে মুছে ফেলেছি। সার্ভারেরটা কিন্তু এখনও আছে। সেটা কিভাবে মুছবো?

সার্ভারের style ব্রাঞ্চটা মুছে ফেলা খুব সোজা। শুধু লোকালের style ব্রাঞ্চটা সার্ভারে একটু কেরামতি করি তুলে দিলেই হলো।

কমান্ড: git push <remote-name> :<branch-name>

তাহলে আমাদের origin রিমোট থেকে style ব্রাঞ্চটি মুছে ফেলতে লিখতে হবে:

$ git push origin :style

ব্রাঞ্চের নামের আগে কোলন (:) খেয়াল করবেন কিন্তু। এটা হচ্ছে true‘র প্রতীক।

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

এজন্য, যে এডিটর/আইডিই আপনি ব্যবহার করছেন, তাতে গিট ইন্টেগ্রেড করা গেলে খুব কাজের হয়। আর যদি তা না করা যায়, তাহলে প্রতিবার কাজে নামার আগে ব্যাশ খুলে ব্রাঞ্চটা দেখে নেয়ার অভ্যাস করতে পারেন।

আমার অভিজ্ঞতা:
যারা আমার মতো LESS বা Sass দিয়ে সিএসএস করেন, তারা কোনো না কোনো কম্পাইলার ব্যবহার করে থাকেন। এই কম্পাইলারগুলো যদি সেটআপ করা থাকে যে স্বয়ংক্রীয়ভাবে কম্পাইল হবে, তাহলে এগুলো ফাইলের modified টাইমস্ট্যাম্পের দিকে খেয়াল রাখে। যদি এধরণের কম্পাইলার সক্রীয় থাকে আর আপনি কম্পাইল করে একটা মিনিফাইড সিএসএস ফাইল তৈরি করে থাকেন, তাহলে ব্রাঞ্চ থেকে ব্রাঞ্চে অদলবদল হবার সময় সে মনে করে ফাইলটা বদলেছে, সাথে সাথে সে একটা কম্পাইল্‌ড সংস্করণ তৈরি করে। এটা ব্রাঞ্চ থেকে ব্রাঞ্চে দৌঁড়াদৌঁড়ির সময় খুবই বিশ্রী রকমের ঝামেলা তৈরি করে। এই ঝামেলা এড়াতে আমি ব্রাঞ্চ বদলের আগে কম্পাইলারটা সাময়িক বন্ধ করে নিই। …আপনাদের কাছে ভালো কোনো সমাধান থাকলে, তা মন্তব্য করে জানালে খুব উপকার হবে।

পরিশেষ

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

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

আরো গভীরে জানা যাক:

1. Git Branching – Branch Management – Git^ – Scott Chacon-এর বই
2. Git: Delete a branch (local or remote)^ – Tobias Kraze
3. Branching and merging best practices in Git^ – StackOverflow

প্রচ্ছদের ছবি: chloepettersson.com থেকে নেয়া ছবি ও অন্যান্য গিট ব্রাঞ্চিং মডেলের মন্তাজ।

হালনাগাদ: ৩১ জানুয়ারি ২০১৭

The post গিট দিয়ে ভার্ষন নিয়ন্ত্রণ – git branch appeared first on Tuts by Mayeenul Islam.

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

আমরা গত পর্বে বলেছিলাম মাত্র ৬টা কমান্ড দিয়ে শিখে নিব, গিট কিভাবে ব্যবহার করতে হয়। …এখুনি হাত নোংরা করার দরকার নেই, একটু ভালো করে বুঝে নিতে হবে আগে। গিট রেপোযিটরি (কিংবা রেপোজিটোরি) কী? গিট কমিট কী (কমিটি নয় কিন্তু, কিংবা কম্মিট বলারও দরকার নেই)? স্টেজ করা কী? …বুঝে বুঝে এগোলে কনসেপ্ট পরিষ্কার হবে, নতুন কিছু গ্রহণ করাও সহজ হবে।

ধাপে ধাপে গিট

গিট রেপোযিটরি: ধরা যাক, আমার একটা ওয়েবসাইট বানাতে হবে, যেখানে দুটো ফাইল থাকবে: (১) index.html আর (২) style.css। ওযেবসাইটের নাম “mywebsite”। এখন কী করবো? … খুব সহজ, mywebsite নামের একটা ফোল্ডার তৈরি করে তার ভিতরে ফাইল দুটো রাখবো। তাহলে আমরা যদি বলি ঐ mywebsite ফোল্ডারটা হলো আমাদের প্রজেক্ট ফোল্ডার, ইউনিক্সের ভাষায় যাকে বলে ডিরেক্টরি, আর গিটের ভাষায় যাকে বলে রেপোযিটরি (repository)। ব্যস রেপোযিটরি বুঝে ফেললাম আমরা – রেপোযিটরি হলো আমাদের প্রজেক্টের সকল ফাইল একত্র করে রাখার একটা স্থান। তাহলে দেখা যাচ্ছে, একটা ফোল্ডার আর রেপোযিটরির মধ্যে কোনো পার্থক্য নেই। …আসলে তা কিন্তু সত্যি নয় – পার্থক্য আছে।

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

ক্লাউড তৈরি করে নেয়া

গিট নিয়ে কাজ করার জন্য আমাদেরকে বিনামূল্যে নিজেদের প্রজেক্ট আপলোড করার সুযোগ করে দিয়েছে github.com নামের ওয়েবসাইটটি (এরকম আরো অনেক গিট সাইট আছে)। আমরা তাই সেখানেই আমাদের রিমোট রেপোযিটরিটা রাখবো। এজন্য আমাদেরকে গিটহাবে বিনামূল্যে একটা অ্যাকাউন্ট খুলে নিতে হবে। নিজের ইমেইল ঠিকানা আর পাসওয়ার্ড দিয়ে গিটহাবে ঢুকে একটা নতুন রেপোযিটরি তৈরি করে ফেলা যাক। সময়ে সময়ে গিটহাবে নতুন পরিবর্তন হচ্ছে, আপাতত নামের পাশের যোগ চিহ্নে (+) ক্লিক করে New Repository চেপে নতুন রেপো তৈরি করে নিতে হবে। আমরা আপাতত git-tutorial নামে একটা রেপো তৈরি করে নিলাম, এবং নিচে README ফাইল যাতে যুক্ত হয় সেজন্য টিকচিহ্ন দিয়ে দিলাম। পাবলিক রেপো তৈরি করবো, কারণ প্রাইভেট রেপো তৈরি করতে খরচা করতে হবে। আমরা কাজ না বুঝে এখনই পয়সা ঢালতে রাজি না।

ব্যস আপনার প্রথম গিট রেপোযিটরি আপনার জন্য তৈরি। আমরা এখন এই রেপোযিটরিটাকে আমাদের পিসিতে clone করবো। ক্লোন করা মানে হলো হুবহু আরেকটা রূপ দেয়া – পৃথিবীতে প্রথম (১৯৯৬ খ্রি.) সফল ক্লোন করা ভেড়ার নাম ডলি, সে ছিল অন্য একটা ভেড়ার অবিকল আরেকটা সত্তা। আমাদের ক্ষেত্রেও বিষয়টা তা-ই। আমাদের সার্ভারে বা ক্লাউডে যা আছে, আমরা সেটাকে লোকাল পিসিতে অবিকল নামিয়ে আনবো। এজন্য আমাদেরকে এই রেপো’র path-টা নিতে হবে। এটা রেপোযিটরির ডানদিকে পাওয়া যাবে, সেখান থেকে কপি করে নিতে হবে।

টিপ্‌স: যেখানেই থাকি না কেন git bash প্রথমে user-এর ফোল্ডারে খোলে। তারপর ডস কমান্ড লিখে লিখে নিজের কাঙ্ক্ষিত ফোল্ডারে যেতে হয়। কিন্তু আমরা গত পর্বে ‘ধর্তব্য ধাপ ২’-তে যে কাজটা করেছিলাম, তা আমাদের কাজকে আরো সহজ করে দিয়েছে। যেখানেই আছেন, খালি জায়গায় মাউসের ডান বোতাম ক্লিক করুন, লেখা দেখবেন: Git Bash Here। ক্লিক করুন, আর গিট ব্যাশ সরাসরি ঐ পাথেই খুলবে। যারা Windows XP SP2 ব্যবহার করছেন, তারা এটা না পেলে Windows Explorer মোডে বামদিকে যে ফোল্ডার ট্রি আসে, সেখানে ফোল্ডারের উপরে মাউসের ডান বোতামে এই কমান্ডটি পাবেন।

একটা Notepad খুলে লেখাটা পেস্ট করলে দেখা যাবে সেটা আসলে আমার ঐ রেপোযিটরির URL-ই, শুধু শেষে একটা .git [ডট গিট] যুক্ত আছে।

এবারে আমাদের পিসিতে Start মেনু থেকে Git Bash চালু করি। ধরা যাক আমরা ক্লোন করে ডেস্কটপে (desktop) রাখবো, তাই আমাদেরকে কমান্ড লিখে আগে ডেস্কটপে যেতে হবে – এটা গিটের অংশ না। যারা ডস মোডে কাজ করেছেন, তারা এটাতে খুব বেশি অভ্যস্থ। আর এগুলো গোণায়ই ধরা যায় না। আমরা নিচের মতো করে লিখলেই ডেস্কটপে চলে যেতে পারি- বলছি change directory to desktop:

cd desktop

এন্টার চাপতেই আমরা ডেস্কটপে চলে এলাম। সত্যি এসেছি কিনা তা যাচাই করা যায় pwd কমান্ডটি লিখে এন্টার চাপলে।

কোড ১: ক্লোন করে নেয়া

যাহোক এবারে আমাদের রেপোযিটরি পাথ ব্যবহার করে আমরা সার্ভারে থাকা গিট রেপোযিটরিটিকে আমাদের ডেস্কটপে নিয়ে আসবো। এজন্য আমাদেরকে লিখতে হবে:

git clone https://github.com/mayeenulislam/git-tutorial.git

টিপ্‌স: গিট ব্যাশে কোনো কিছু কপি-পেস্ট করা একটু সমস্যার। এজন্য ব্যাশের বাম দিকের উপরের টাইটেল বারের আইকনে ক্লিক করে বের হওয়া মেনুর Edit সাব মেনু থেকে সুবিধাগুলো ব্যবহার করা যাবে।

এছাড়া গিটের নতুন সংস্করণের সাথে পাওয়া গিট ব্যাশে Insert কী চাপলেও লেখা পেস্ট হবে।

লক্ষ করুন, আমরা ওখান থেকে যে লিংকটা কপি করেছিলাম, তা এখানে পেস্ট করেছি। পেস্ট করতে কষ্ট হলে নোটপ্যাডে পেস্ট করে দেখে দেখে টাইপ করে নিন। এবারে এন্টার চাপলে সার্ভার থেকে গিট রেপোযিটরিটি আমাদের পিসিতে হুবহু নেমে যাবে। …কোথায় নামবে? যেখানে আমরা সর্বশেষ ছিলাম (pwd লিখে চেক করে দেখেছিলাম)। …ক্লোন হবার সময় ব্যাশ আমাদের দেখিয়েছে Cloning into 'git-tutorial'..., তার মানে ডেস্কটপে আমাদের রেপোযিটরিটা git-tutorial নামে তৈরি হয়েছে। আমরা ডেস্কটপে সেই ফোল্ডারটা দেখেও নিতে পারি। সুতরাং আমরা এখন ঐ ফোল্ডার বা রেপোযিটরিতে ব্যাশ ব্যবহার করে ঢুকতে চাইলে লিখবো:

cd git-tutorial

আমরা এখন আমাদের সদ্য নামানো রেপোযিটরির ভিতরে আছি।

কোড ২: গিট, তোমার খবর কী?

এবারে আমরা জানতে চাচ্ছি, এই রেপোযিটরির খবর কী। গিটের হালচাল জানতে হলে বহুল ব্যবহৃত কমান্ডটি হলো:

git status

উত্তরে গিট আমাদেরকে বলবে: হ্যা, হ্যা, খবর খুব ভালো। তোমার গিট রেপোযিটরিটা সার্ভারের ওরিজিনাল রেপোযিটরির সাথে এক্কেবারে সাম্প্রতিক (up-to-date), কমিট করার কিচ্ছুই নেই, পুরোপুরি সাফ-সুতরো। 🙂

    On branch master
    Your branch is up-to-date with 'origin/master'.
    
    nothing to commit, working directory clean

আমরা কিন্তু দুটো কমান্ড ইতোমধ্যেই শিখে ফেলেছি। আর এটাও লক্ষ করেছি কিনা যে, গিটের অধিকাংশ কমান্ড শুরু হয় git লেখাটা দিয়েই। 🙂

তথ্যকণিকা: এই যে রেপো’র ভিতরে গিয়ে git status লেখার সাথে সাথেই সে আপনাকে তথ্য দেখানো শুরু করলো, তার কারণ এটা একটা গিট রেপোযিটরি। আমরা যখন গিটহাবে রেপো বানানোর সময় README ফাইল যোগ করতে বলে দিয়েছিলাম, তখনই সে এটাকে একটা গিট রেপো বানিয়ে দিয়েছে। যদি আমাদের প্রজেক্টটি গিট রেপো বানানো না থাকতো, কিংবা একটা সাধারণ ফোল্ডারের ভিতর ঢুকে আমরা স্ট্যাটাস জানতে চাইতাম, তখন কিন্তু গিট আমাদেরকে কিচ্ছু বলতে পারতো না। আর তখনই আমাদেরকে আমাদের ফোল্ডারকে আগে গিট রেপো বানানো লাগতো। যেকোনো ফোল্ডারকে গিট রেপো বানানোর জন্য আপনাকে গিট ব্যাশে সেই ফোল্ডারে ঢুকে কোড লিখতে হবে git init — গিটকে ইনিশিয়েট করো – চালু করো। আর তখনই আমাদের শিখে আসা .git ফোল্ডারটি ঐ ফোল্ডারে তৈরি হয়ে নিজের কাজ শুরু করবে।

আমরা এবারে আসল ভার্সন কন্ট্রোল বা ভার্সন নিয়ন্ত্রণ করে দেখবো… আমাদের রেপোযিটরির ভিতরে একটা index.html ফাইল আছে। সেটা যদি আমরা টেক্সট এডিটরে খুলি, তাহলে নিচের মতো HTML কোড দেখা যাবে:

    <html>
        <head><title>Test - nanodesigns</title></head>
        <body>
            <p>This is a test file for git-tutorial repository.</p>
        </body>
    </html>

ধরা যাক এটাই আমাদের ওয়েবসাইট, দারুণ সুন্দর একটা ওয়েবসাইট। আমরা করলাম কি, প্যারাগ্রাফ ট্যাগের শেষের ফুলস্টপটাই (.) শুধু ফেলে দিলাম। তারপর আবার ফাইলটা সেভ করলাম। তারমানে কি? আমাদের ফাইলে একটা পরিবর্তন করা হয়েছে। পরিবর্তনের পরিমাণ হিসেবে খুবই নগন্য (হা হা হা, এটা কোনো পরিবর্তন হলো নাকি?), কিন্তু তবু পরিবর্তন তো…। এবারে ব্যাশে ফিরে আসুন, আপনি আমাদের রেপো’র ভিতরে রয়েছেন, এবারে আবার গিটের হালচাল জানতে চান:

git status

এবারে গিট লাল রং দিয়ে আমাদের test.html ফাইলটাকে দেখিয়ে বলবে: এহ্‌হে, মডিফাই করা ফাইল পাওয়া গেছে, যা এখনও মঞ্চে তোলা হয়নি (not staged)। ঠিকইতো, আমরা ফাইলটাতে পরিবর্তন করেছি, কিন্তু গিটের সাথে তো কোনো খেলাধুলা করিনি এপর্যন্ত।

কোড ৩: মঞ্চে তোলো

তাই এবারে গিটকে বলতে হবে, গিট, হ্যা, ফাইলে পরিবর্তন যা তুমি দেখতে পাচ্ছো, তা ঠিকই আছে। এই পরিবর্তনকে এবার মঞ্চে নিয়ে এসো:

git add test.html

আমরা গিটকে শুধুমাত্র test.html ফাইলটাকে মঞ্চে নিয়ে আসতে বললাম add বলার পরে ফাইলের নামটা লিখে। ধরা যাক, একবারে অনেকগুলো ফাইলে আমরা পরিবর্তন করলাম, তখন কি আমরা প্রত্যেকটা ফাইলের নাম ধরে ধরে এভাবে যোগ করে নিব? না তখন সব ফাইলকে এক কমান্ডে staged করে নেয়ার কমান্ড হলো git add . (গিট অ্যাড ডট্‌) কিংবা git add -A, অর্থাৎ, গিট, সব (All) ফাইলকে যোগ করে নাও। এবারে আবারও git status জানতে চাইলে সবুজ রঙে গিট আমাদের ফাইলটা দেখাবে: হ্যা, তোমার পরিবর্তনটা মঞ্চে নিয়ে এসেছি (staged), এবারে তা কমিট করার অপেক্ষায়। এবারে আমরা আমাদের পরিবর্তনটার একটা ছবি তুলে রাখবো।

কোড ৪: ছবি তোলো

…এই যে মঞ্চে তোলা বা যোগ করে নেয়া, একে বলা হয় stage করা। এর পরের ধাপটাই ছবি তুলে রাখা (snapshot)। তাহলে বুঝা গেল, staged না হলে, মঞ্চে আনা না হলে মডেলের snapshot নেয়া যায় না।

unstaged ফাইলকে staged করা হয়েছে, পর্দার পেছনের মডেলকে মঞ্চে আনা হয়েছে, এবারে আমাদের দরকার ছবিটা তুলে রাখা, আর একে গিট-এর ভাষায় বলে কমিট করা (commit)। আমরা গত পর্বে দেখেছিলাম, গিট আসলে ফাইল সংরক্ষণ করে না, ছবি তুলে রাখার মতোই ফাইলের অবস্থার রেকর্ড রাখে। কমিট করার মাধ্যমে আমরা আসলে গিটকে বলি: গিট বাবাজি, করো…। কী করবে? গিটের তো একটাই কাজ, ভার্সন নিয়ন্ত্রণ। সে তখন স্টেজ করা ফাইলগুলোর একটা রেকর্ড রেখে দিবে। এজন্য আমরা টাইপ করবো:

git commit -m "My first commit to learn git with nanodesigns"

এই কোডে আমরা বললাম, গিট, কমিট করো। [যাতে পরে চিনে নিতে পারি, তাই] কমিটটাকে একটা বার্তা (-m) দিয়ে সংরক্ষণ করে রাখো। বুঝতেই পারছেন, পাশে ডাবল কোটের ভিতরে আমরা বার্তাটাই রেখেছি। …এবারে আবার git status টাইপ করে এন্টার চাপলে দেখাবে, কমিট করার নতুন কিছুই নেই, প্রজেক্ট ফোল্ডার ফকফকা পরিষ্কার।

সম্পূর্ণ লোকালি গিট: বারবার একই কথা, গিট দিয়ে লোকালি কাজ করা যায়, ইন্টারনেটের দরকারই নেই। কিন্তু আমরা তো শুরুই করলাম github.com দিয়ে? ক্যামনে কী?। ডেস্কটপে একটা ফোল্ডার খুলুন, নাম দিন ‘test’। ভিতরে একটা টেক্সট ফাইল খুলুন, নাম দিন ‘test.txt’। ঐ ফোল্ডার পাথে git bash খুলুন। লিখুন git init। ব্যস, গিট রেপো তৈরি। এবারে git add -A আর git commit -m "Test"। আমরা সবই পারি…

হাত নোংরা করি…

এবারে পটাপট কয়েকবার অনুশীলন করা যাক—

1. HTML ফাইলটা খুলে কিছু পরিবর্তন করে ফেলুন।
2. এবারে ব্যাশ খুলে লিখুন git status,
3. স্ট্যাটাস দেখা হয়ে গেলে লিখুন git add test.html কিংবা git add -A, ব্যস হয়ে গেল মঞ্চে তোলা বা স্টেজ করা
4. এবারে আরেকটা কমিট করতে লিখুন git commit -m "Another commit"
5. আবার git status চেপে অবস্থা দেখুন
6. ফাইলটা আরো খানিকটা বদলে তারপর
   • স্টেজ করুন, তারপর
   • আরেকটা কমিট করুন।

…সহজ না? ব্যস, আপনার গিট শেখা শেষ। আপনি গিট শিখে গেছেন।

আপনি বলবেন: এক মিনিট; কোড শেখার কথা ছিল ৬টা, শেখা হলো ৪টা, বাকি দুটোর কী হবে? আসলে বাকি দুটো না হলেও আপনি লোকালি গিট ব্যবহার করে এভাবে ভার্সনের পর ভার্সন সংরক্ষণ করতে পারবেন। গিটের পুরো কাজটাই হয় লোকালি, একারণে গিট অনেক দ্রুত। এবং সত্যি কথা হলো, ‘তথ্যকণিকা’ সাথে নিয়ে কোড ২, ৩, আর ৪ দিয়েই আপনি লোকালি ভার্সন নিয়ন্ত্রণ করতে পারবেন (সহায়তার দরকার হলে ডানের বাক্সটা দেখুন)। …তবে যেহেতু আমরা সার্ভার থেকে জিনিসপত্তর নামিয়ে নিয়েছিলাম, তাই সার্ভারে আবার সেটা তুলে দেয়ার বিষয় থাকতেই পারে। এজন্য দরকার হবে এই দুটো কমান্ড-

কোড ৫: ধাক্কা মেরে তুলে দাও

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

git push origin master

অর্থাৎ, গিট, মূল যেখান থেকে একে পেয়েছো, সেখানে একে ধাক্কা (push) দিয়ে তুলে দাও। আমরা যখন ক্লোন করে রেখেছিলাম, তখনই সে তার খাতায় জানিয়ে রেখেছিল, তার মূল অস্তিত্ব যে সার্ভারে, সেখানে তার জন্ম হয়েছিল। তাই এখন যখন আমি origin master-এ তুলে দিতে বলেছি, সে বুঝে গেছে, কোন অরিজিনাল মাস্টারে তাকে তুলতে বলেছি।

গিট তখন আমার গিটহাবের ব্যবহারকারী নাম আর পাসওয়ার্ড জানতে চাইলো, আমি লিখলাম, তারপর এন্টার চাপতেই সে আমার লোকাল পিসিতে করা পরিবর্তনটা সার্ভারে তুলে নিয়ে সার্ভারের রেপোটাকেও সাম্প্রতিক করে নিলো। আমরা সেটা যাচাইও করে নিলাম গিটের হালহকিকত জিজ্ঞেস করে।

কোড ৬: টান দিয়ে নামিয়ে নাও

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

git pull

ব্যস, আপনার বন্ধুর/সহকর্মীর করা কাজ এবারে আপনার রেপোতেও আপডেট হয়ে গেল, এবারে আপনি নিশ্চিন্তে এগিয়ে যাওয়া কাজের উপর কাজ করে আরো এগিয়ে নিতে পারেন কাজকে। তারপর আবার push করে দিলেই আপনার বন্ধুও ওখান থেকে pull করে আপনার আপডেটগুলো পেয়ে যাবেন।

ব্যস, গিট আমাদের আয়ত্বে এসে গেছে। এবারে একে এগিয়ে নিতে হবে আরো অনেকদূর। আজ যে পথচলা শুরু হলো, এটা তো শুরু মাত্র। আমাদের জানার শেষ নেই। merge করা, merge conflict দূর করা, branch নিয়ে কাজ করা, প্রাইভেট রেপোতে কাজ করা, fetch করা, ফেচ করা তথ্যের সাথে পার্থক্য দেখা, অন্যের রেপোতে কাজ করা… কত রকম কাজ এখনও বাকি…। তাই এপর্যায়ে বোধহয় একটা উপযুক্ত সময় হয়েছে Scott Chacon-এর গিট পরিচিতিমূলক বক্তৃতাটা দেখে নেয়ার (এই ভিডিওটার লিংক দিয়ে বন্ধু নাজমুস সাকিব সর্বপ্রথম আমার গিট শেখার সূচনা করে, অবশ্য প্রথম হিসেবে একটু কঠিনই লাগছিল, কিন্তু এবারে আপনাদের আর কঠিন লাগবে না):

মঈনুল ইসলাম
mayeenulislam.github.io

আরো তথ্য

• Understanding git for real by exploring the .git directory – Pierre de Wulf (Medium.com) – .git ফোল্ডারটি ঘুরে ঘুরে দেখা যেতে পারে, medium-এ প্রকাশিত এই টিউটোরিয়াল দেখে নিলে।

হালানাগাদ: ৬ আগস্ট ২০১৭

The post গিট ব্যবহারের একেবারে প্রাথমিক জ্ঞান : পর্ব ২ appeared first on Tuts by Mayeenul Islam.

গিট (Git) হলো হাল আমলের সবচেয়ে প্রসিদ্ধ এবং জনপ্রিয় ভার্সন নিয়ন্ত্রণ সফ্‌টওয়্যার। …ভার্সন কন্ট্রোল বা ভার্সন নিয়ন্ত্রণ কী – আমরা সেটা দেখবো। আমরা যেহেতু একেবারে প্রাথমিক আলোচনা করছি, তাই অনেক বিষয়ই জানা থাকলেও একটু না একটু আলোচনা করতেই হবে, ধারণা পরিষ্কার হবে, আমরা বিষয়টা বুঝবোও সহজে। মনে রাখতে হবে, এপৃথিবীর সবকিছুর মূলে রয়েছে কিছু কনসেপ্ট বা ধারণা। ধারণাটা বুঝে ফেললে বাকি সব পানিভাত। Git নামটা বুঝার আগে আমি GitHub নামটা শুনেছিলাম, এবং এই দুটোর মধ্যে কোনো পার্থক্য করতে পারতাম না প্রথম প্রথম। আপনাদের মনেও যদি এই প্রশ্নটা থাকে, তাও আমরা পরিষ্কার করবো ইনশাল্লাহ। তবে শর্ত হলো দুটো –

1. যদি জানতে হয়, শিখতে হয়, পুরো লেখাটা দুই পর্বেরই শেষ পর্যন্ত পড়তে হবে।
2. আমার প্রতি বিশ্বাস রাখুন, খুব সহজে, সংক্ষেপে গিট বুঝাতে চলেছি, এবং আমার মতো মোটা মাথায় যদি ঢুকতে পারে, আপনাদের জন্য তো চিন্তারই কারণ নেই।

সংক্ষেপে বলো – সহজে বলো

গিট সম্পর্কে জানতে হলে কি আপনার এইসব ফিরিস্তি পড়তে হবে বসে বসে? …মোট্টেই না।

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

• গিট-এর উপর Scott Chacon-এর সম্পূর্ণ বই – Pro Git – বিনামূল্যে ডাউনলোড করুন
• অনলাইনে বসে হাতে-কলমে গিট শিখুন – Try Git থেকে
• অ্যাটলাশিয়ান-এর গিট টিউটোরিয়াল
• গিট পরিচিতি – হাসিন হায়দার – shell ব্যবহার করে গিট ব্যবহারের উপর বাংলায় ভিডিও টিউটোরিয়াল

ভার্সন নিয়ন্ত্রণ কী

গিট বুঝতে গেলে একটু বুঝে নেয়া দরকার, ভার্সন নিয়ন্ত্রণ বিষয়টা কী। সহজে বলতে গেলে নিচের টেক্সট ফাইলটি (Readme.txt) দেখা যাক:

	20140919~15:03:40	This is a readme file
	20140919~15:04:27	A readme file that is changed from its original state
	20140919~15:04:55	A readme file that is changed from its original state. And something appended after the first paragraph.

এই টেক্সট ফাইলটিকে আমরা একটা ছোট্ট উদাহরণ হিসেবে নিয়েছি। এখানে আপনারা ভালো করে লক্ষ করলে দেখবেন তিনটা আলাদা আলাদা সময়ের উল্লেখ আছে, যদিও তারিখটা একই আছে। তিনটা আলাদা সময়ে ফাইলটাতে তিনটা আলাদা পরিবর্তন হয়েছে। প্রথম সময়ে (15:03:40) যে লেখাটা ছিল, পরের সময়েই (15:04:27) সেই লেখাটা প্রায় পুরোপুরি বদলে ফেলা হয়েছে (মানে বাদ দিয়ে, যোগ করা হয়েছে)। আবার তার পরের সময়ে (15:04:55) দ্বিতীয় লেখাটা না ছুঁয়ে তার সাথে নতুন কিছু যোগ করা হয়েছে। মনে রাখতে হবে, এই তিনটা পরিবর্তনই কিন্তু একই ফাইলে হয়েছে, শুধু পার্থক্য হলো, এগুলো বিভিন্ন সময়ে হয়েছে। এখন আমরা এই তিনটা সময়কে যদি এই ফাইলটার তিনটা আলাদা আলাদা অবস্থা ধরে নিই, তাহলে তা-ই কিন্তু ভার্সন (version)।

আমাদের ফাইলটি এখন খুললে আমরা কোন অবস্থায় পাবো, মানে কোন ভার্সনে পাবো? অবশ্যই সর্বশেষ ভার্সনে, মানে 15:04:55 সময়ে আপডেট করা ভার্সনটি। কিন্তু ধরা যাক, কোনো কারণে আমাদের প্রথম বাক্যটার (A readme file that is…) জায়গায় দরকার একেবারে প্রথমে যে বাক্যটা লিখেছিলাম, সেই বাক্যটা (মানে: This is a readme file বাক্যটা)। এখন তাহলে কোথায় পাবো সেটা? …কোত্থাও পাওয়া যাবে না, কারণ ফাইলটার পুরোন সেই লেখাটা এখন আর ফাইলে নেই – ঐ লেখাটা মুছেইতো সর্বশেষ অবস্থা পেলাম। …এজন্যই দরকার পড়ে ভার্সন কন্ট্রোল বা ভার্সন নিয়ন্ত্রণের, যেখানে আমাদের পুরোন কাজগুলো কখন কেমন ছিল, তার একটা রূপ আমরা পরেও দরকার পড়লে পাই। আবার এমনও হতে পারে, ফাইলের সব লেখা মুছে কেউ সব উল্টাপাল্টা করে ফেললো, তখন ফাইলের বিভিন্ন ভার্সন থাকলে আমরা পুরোন ভার্সনটাতে ফাইলটাকে ফিরিয়ে নিয়ে গিয়ে বিপদ থেকে উদ্ধার পাবো সহজে। এই কালানুগ কিংবা অবস্থানুগ পরিবর্তনের চিত্রটাই হলো ভার্সন, আর উপরে বর্ণিত কারণগুলোর জন্যই মূলত আমাদের ভার্সন নিয়ন্ত্রণের দরকার পড়ে।

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

ভার্সন নিয়ন্ত্রণের পুরোন পদ্ধতি ফেলে এখন যখন গিট

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

আপনি যে ফাইলে কাজ করেছেন, সেই ফাইলটা ছাড়াও এখন আরো তিনটা ফাইল আপনার হয়ে গেছে। যদি একেকটা ফাইলের আকার 1kb করে হয়, তাহলে আপনার ডিস্কে এখন 4kb (মূল ফাইল + তিনটা ভার্সন) জায়গা জোড়া হয়ে গেছে। বিষয়টা বড় ফাইলের ক্ষেত্রে হলে কী হবে আশা করি আর বুঝিয়ে বলা লাগবে না। আর এখানেই গিট-এর কৃতিত্ব। গিট এই পদ্ধতিতে ভার্সন নিয়ন্ত্রণ করে না।

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

একটু পরিচিতি…

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

গিট নিয়ে কাজ করতে দেখলেই আমরা দেখি অনেক অনেক কোড লেখালেখি, আসলে এটাই হলো গিট নিয়ে কাজ করার সহজতর পন্থা (আমি কি ‘সহজতর পন্থা’ বলিনি?)। কিন্তু এছাড়াও গিট ব্যবহারের অনেক GUI বা Graphical User Interface বা দেখে-দেখে-ক্লিক-করে-করে-কাজ-করার প্রোগ্রাম রয়েছে, কিন্তু সেগুলো এখনও হয়তো অতটা সম্পূর্ণ না এবং অনেক ক্ষেত্রে সেগুলোতে সীমাবদ্ধতা আছে, তাই কোডাররা কোড লিখে কাজ করাকেই বেশি পছন্দ করেন। এবং GUI পদ্ধতিতে কাজ করলে একটা সমস্যা হলো একজন এই ইন্টারফেস পছন্দ করেন তো আরেকজন অন্য ইন্টারফেস পছন্দ করেন, তখন আপনার জন্য নিজের অবস্থান তৈরি করাটা কষ্টকর হয়ে উঠতে পারে। কিন্তু যে যেই ইন্টারফেসেই স্বচ্ছন্দবোধ করুন না কেন, যদি তাঁর গিট কোড জানা থাকে, তাহলে যেকোনো পরিবেশ-পরিস্থিতিতেই স্বাভাবিকভাবে, স্বচ্ছন্দে কোড করতে পারবেন তিনি। তাই আমরা আসলে ঐসব ইন্টারফেসভিত্তিক গিট না শিখে খুব সহজে কোড লিখে গিট শিখে নিব।

গিট ব্যাশ – কোড লিখে ভার্সন নিয়ন্ত্রণ

ইংরেজিতে Git Bash লেখা বলে অনেকে একে ‘গিট বাশ’ বলেন, কিন্তু আসলে উচ্চারণটা ‘গিট ব্যাশ’ হবে। গিট ব্যাশ হলো কমান্ড লাইনে, মানে কোড লিখে গিট ব্যবহার করার পদ্ধতি। এটা গিট ইন্সটল করার সময়ই ইন্সটল করে নেয়া যায়, অথবা উইন্ডোজের সাথে থাকা ডস মোডের কমান্ড প্রম্পট (ম্যাক-এর ক্ষেত্রে টার্মিনাল) ব্যবহার করেও কোড করা যায়। আমরা যেহেতু কোড মোডে কাজ করবো, তাই আমরা গিট ব্যাশ ইন্সটল করে নিবো গিট ইন্সটল করার সময়ই।

গিট ইন্সটল করা

মাইক্রোসফ্‌ট অফিস ব্যবহার করতে হলে যেমন তা ইন্সটল করে নিতে হয়, গিট ব্যবহার করার জন্যও তা ইন্সটল করে নিতে হয় – তবে গিট সফ্‌টওয়্যারটা যথেষ্ট হালকা। এজন্য আমাদেরকে নিচের URL থেকে গিট-এর সাম্প্রতিক সংস্করণটি ডাউনলোড করে নিতে হবে:

git-scm.com/downloads

ধর্তব্য ধাপ ১: ডাউনলোড করা ইন্সটলারটি চালু করলে Next চেপে চেপে এগোলে নিচের মতো একটি পর্দা আসবে। এখানে আপনাকে, গিট কোথায় ইনস্টল হবে, তা দেখিয়ে দিতে হবে। C:\ ড্রাইভে ইন্সটল করতেই হবে – এরকম কোনো বাধ্যবাধকতা নেই।

ধর্তব্য ধাপ ২: Next চাপলে আরেকটি পর্দা আসবে, যেখানে আপনাকে গিট-এর কম্পোনেন্ট মানে দরকারি অংশগুলো বাছাই করে নিতে হবে। এখানে আপনি Windows Explorer Integration অংশে Git Bash here এবং Git GUI here পছন্দ করে নিন – আমরা ব্যাশ নিয়ে কাজ করলেও GUI-টা পাশাপাশি থাকবে, এবং ঠিকমতো ইন্সটল হলে মাউসের রাইট বাটনের সাথে এই দুটো অপশন যোগ হয়ে যাবে। Next চাপুন।

ধর্তব্য ধাপ ৩: PATH বাছাই পাতায় Use Git from Git Bash only বাছাই করে Next চাপুন।

ধর্তব্য ধাপ ৪: Line ending conversions-এ Checkout Windows-style, commit Unix-style line endings বাছাই করে Next চাপুন।

ব্যস, গিট ইন্সটল হয়ে গেল।

এবারে গিটকে নিজের, সম্পূর্ণ আপন করে নেয়ার পালা। Start » Git » Git Bash-এ ক্লিক করুন। ব্যস, উইন্ডোজের ডস মোডের মতো একটা কমান্ড কনসোল খুলবে, এখানেই আমরা কাজ শুরু করবো। গিটকে আপন করে নেবার জন্য দুটো কাজ করতে হবে:

• গিটকে নিজের নামটা বলে দেয়া
• গিটকে নিজের ইমেইল ঠিকানাটা দিয়ে দেয়া

ধরা যাক আমার নাম Someone আর ইমেইল ঠিকানা হলো someone@example.com, তাহলে যা লিখতে হবে-

git config --global user.name "Someone"
git config --global user.email "someone@example.com"

ব্যস গিট এবার আপনার, শ্রেফ আপনার জন্য প্রস্তুত। এই কাজটা বারবার করতে হবে না, ব্যস এই একবারই।

গিট ব্যবহারের প্রাথমিক জ্ঞানের আজকের আলোচনা এই পর্যন্তই। এখানে আমরা গিট সম্পর্কে প্রায় সম্পূর্ণ অন্তর্নিহীত ধারণা পেয়ে গেলাম। আগামী পর্বে আমরা গিট ব্যবহার করে ভার্সন নিয়ন্ত্রণ করা শিখে নিব মাত্র ৬টা কমান্ড দিয়ে, ইনশাল্লাহ।

আগামী পর্বে সমাপ্য…

পরের পর্ব »

– মঈনুল ইসলাম
mayeenulislam.github.io

The post গিট ব্যবহারের একেবারে প্রাথমিক জ্ঞান : পর্ব ১ appeared first on Tuts by Mayeenul Islam.