GitHub কী এবং VPS-এর জন্য Git ও GitHub-এর পার্থক্য

GitHub কী?

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

আপনার যখন একটি VPS (virtual private server) থাকে, তখন এই পার্থক্যটি গুরুত্বপূর্ণ হয়ে ওঠে। Git আপনার কনফিগারেশন ফাইল এবং ডিপ্লয় স্ক্রিপ্টের ইতিহাস রেকর্ড করে। আর GitHub হলো সেই জায়গা যেখানে সার্ভারের বাইরে সেই ইতিহাসের একটি কপি থাকে, পাশাপাশি এটি বিল্ড এবং রিভিউ চালানোর একটি প্ল্যাটফর্ম। এই নির্দেশিকাটি একটি খালি ফোল্ডার থেকে সার্ভারে ডিপ্লয় পর্যন্ত একটি উদাহরণ অনুসরণ করে এবং প্রতিটি নতুন শব্দকে প্রথমবার ব্যবহারের সময় সংজ্ঞায়িত করে।

Git নিজে যা করে

Git একটি version control system: এটি সময়ের সাথে সাথে একটি ডিরেক্টরির অবস্থা রেকর্ড করে রাখে, যাতে আপনি দেখতে পারেন কী পরিবর্তিত হয়েছে, কখন হয়েছে এবং কেন হয়েছে। এটি 2005 সালে Linux kernel-এর কাজের জন্য তৈরি করা হয়েছিল। এটি distributed বা বিতরণকৃত, যার অর্থ হলো একটি repository-এর প্রতিটি কপির কাছে পুরো ইতিহাস সংরক্ষিত থাকে। এর ডিজাইনে কোনো কেন্দ্রীয় সার্ভার নেই। কোনো সহকর্মীর ল্যাপটপও যেকোনো সার্ভারের মতোই একটি সম্পূর্ণ কপি।

এটি ইনস্টল করুন এবং আপনার পরিচয় সেট করুন। Git নাম এবং ইমেইল ঠিকানা ছাড়া কোনো commit রেকর্ড করতে অস্বীকার করে, কারণ এই দুটি তথ্য সরাসরি commit-এর ভেতরেই লেখা থাকে।

sudo apt update && sudo apt install -y git
git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Ubuntu 24.04-এ, git --version কমান্ডটি git version 2.43.0 প্রিন্ট করে। গত কয়েক বছরের যেকোনো release-এর ক্ষেত্রে নিচের সবকিছুর আচরণ একই রকম।

উদাহরণ: আপনার VPS ডিপ্লয় ফাইলগুলোর জন্য একটি রিপোজিটরি

একটি repository, যাকে সাধারণত "repo" বলা হয়, হলো এমন একটি ডিরেক্টরি যা Git পর্যবেক্ষণ করছে। আপনি যখন git init কমান্ডটি চালান, তখন এটি একটি রিপোজিটরিতে পরিণত হয় এবং এর ভেতরে একটি লুকানো .git ফোল্ডার তৈরি হয়। সেই ফোল্ডারটিই মূলত রিপোজিটরি। .git ডিলিট করে দিলে আপনি কেবল একটি সাধারণ ডিরেক্টরি পাবেন, যার কোনো ইতিহাস থাকবে না।

mkdir vps-deploy && cd vps-deploy
git init -b main
printf '.env\n*.key\n' > .gitignore

-b main কমান্ডটি প্রথম ব্রাঞ্চের নাম main হিসেবে নির্ধারণ করে। এটি ব্যবহার না করলে Git ডিফল্ট ব্রাঞ্চের নাম সম্পর্কে একটি দীর্ঘ পরামর্শ প্রদর্শন করে। .gitignore ফাইলে সেই পাথগুলোর তালিকা থাকে যা Git কখনোই ট্র্যাক করবে না। প্রথম দিনেই আপনার সিক্রেট ফাইলটির নাম এতে লিখে রাখুন, কারণ একবার কমিট করা কোনো ফাইল ডিলিট করার পরেও তার ইতিহাস থেকে যায় এবং সেটিকে সঠিকভাবে মুছে ফেলার অর্থ হলো পরবর্তী প্রতিটি কমিট পুনরায় লেখা।

কমিট: ইতিহাসের একক

এখন একটি স্ক্রিপ্ট যোগ করুন এবং তা রেকর্ড করুন।

printf '#!/bin/sh\nsudo systemctl restart caddy\n' > restart.sh
git add restart.sh .gitignore
git commit -m "Add restart script and gitignore"
git log --oneline

git add একটি পরিবর্তনকে staging area-তে নিয়ে যায়, যা পরবর্তী কমিটে কী কী থাকবে তার তালিকা। git commit সেই তালিকাকে একটি এন্ট্রি হিসেবে ইতিহাসে লিখে রাখে। একটি commit প্রতিটি ট্র্যাক করা ফাইলের স্ন্যাপশট, একটি মেসেজ, একজন লেখক, একটি টাইমস্ট্যাম্প এবং আগের কমিটের দিকে নির্দেশকারী একটি পয়েন্টার ধারণ করে। git log --oneline প্রতিটি কমিটের জন্য একটি করে লাইন প্রিন্ট করে, যার শুরুতে a1b2c3d-এর মতো একটি ছোট হ্যাশ থাকে। সেই হ্যাশটি হলো কমিটের নাম এবং প্রায় প্রতিটি Git কমান্ড এটি গ্রহণ করে।

git add ধাপটি বাদ দিন এবং git commit কমান্ডটি চালান, no changes added to commit (use "git add" and/or "git commit -a") এর উত্তর দেবে। কোনো কিছু নষ্ট হয়নি। Git আপনাকে জানাচ্ছে যে staging area খালি, তাই স্ন্যাপশট নেওয়ার মতো কিছু নেই। আপনি যখনই বিভ্রান্ত বোধ করবেন তখন git status কমান্ডটি চালাবেন: এটি বর্তমান ব্রাঞ্চ, staged পরিবর্তনসমূহ এবং Git যেসব ফাইল দেখতে পাচ্ছে কিন্তু ট্র্যাক করছে না, তাদের নাম দেখাবে।

ব্রাঞ্চ: ইতিহাসের একটি দ্বিতীয় ধারা

একটি branch হলো একটি কমিটের দিকে নির্দেশকারী চলমান পয়েন্টার। main একটি ব্রাঞ্চ, এবং Git-এর কাছে এটি কোনো বিশেষ কিছু নয়। একটি ব্রাঞ্চ তৈরি করতে কোনো খরচ হয় না, কারণ Git আপনার ফাইলগুলো কপি না করে কেবল একটি নতুন পয়েন্টার লেখে।

git switch -c add-backup
printf '#!/bin/sh\nrestic backup /srv\n' > backup.sh
git add backup.sh
git commit -m "Add nightly backup"
git switch main
ls

git switch main-এর পরে, তালিকা থেকে backup.sh হারিয়ে যায়। কোনো কিছুই মুছে ফেলা হয়নি। ফাইলটি add-backup ব্রাঞ্চে বিদ্যমান, এবং main-এ এটি কখনোই ছিল না, তাই আপনি যখন ব্রাঞ্চ পরিবর্তন করেছেন, Git আপনার ওয়ার্কিং ডিরেক্টরি থেকে এটি সরিয়ে ফেলেছে। এটি সবাইকে একবার অবাক করে। git switch add-backup এটি ফিরিয়ে আনে।

Remotes: যেখানে অবশেষে GitHub দৃশ্যমান হয়

এতক্ষণ পর্যন্ত সবকিছু একটি মাত্র মেশিনে চলেছে, যেখানে কোনো নেটওয়ার্কের প্রয়োজন ছিল না। একটি remote হলো একই রিপোজিটরির অন্য একটি কপির নামযুক্ত URL। GitHub আপনার জন্য এমন একটি কপি হোস্ট করে। প্রধান রিমোটের প্রচলিত নাম হলো origin।

GitHub ওয়েবসাইট ব্যবহার করে একটি খালি রিপোজিটরি তৈরি করুন, তারপর সেটির সাথে সংযোগ স্থাপন করুন। এখানে HTTPS-এর চেয়ে SSH ব্যবহার করা শ্রেয়: একটি SSH key হলো এমন একটি ফাইল যা আপনার নিয়ন্ত্রণে থাকে এবং এটি personal access token-এর মতো মেয়াদোত্তীর্ণ হয় না।

ssh-keygen -t ed25519 -C "vps-deploy"
cat ~/.ssh/id_ed25519.pub
ssh -T git@github.com

প্রিন্ট হওয়া পাবলিক কি-টি কপি করে আপনার GitHub অ্যাকাউন্টের SSH keys পেজে পেস্ট করুন, তারপর পরীক্ষাটি পুনরায় চালান। একটি কার্যকর কি Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.-এর উত্তর দেয়। GitHub আপনাকে কোনো shell দেয় না, তাই সেই প্রত্যাখ্যানটিই সফলতার লক্ষণ। git@github.com: Permission denied (publickey). মানে হলো আপনার কি-টি অফার করা হয়নি অথবা গৃহীত হয়নি, তাই নিশ্চিত হয়ে নিন যে আপনি .pub ফাইলটি পেস্ট করেছেন, এর পাশে থাকা প্রাইভেট কি-টি নয়।

git remote add origin git@github.com:yourname/vps-deploy.git
git push -u origin main

git push আপনার কমিটগুলোকে রিমোটে পাঠায়। -u রেকর্ড করে যে লোকাল main রিমোটের main-কে ট্র্যাক করছে, যাতে পরবর্তীতে শুধু একটি git push লিখলেই কাজ চলে। git clone <url> হলো নতুন মেশিনে এর বিপরীত প্রক্রিয়া: এটি পুরো রিপোজিটরি এবং এর ইতিহাস কপি করে আনে এবং আপনার জন্য origin সেট করে দেয়। একটি HTTPS রিমোটও কাজ করে এবং এটি যেকোনো ওয়েব পেজের মতোই একই প্রোটোকলে চলে, যা এমন নেটওয়ার্কে সহায়ক যেখানে আউটবাউন্ড পোর্ট 22 ব্লক করা থাকে। যদি এই বাক্যটি আরও বিস্তারিত বোঝার প্রয়োজন হয়, তবে একটি HTTP request আসলে কী দিয়ে গঠিত বিষয়টি এর কার্যপদ্ধতি ব্যাখ্যা করে।

Pull requests, issues এবং forks: এগুলো GitHub-এর অংশ, Git-এর নয়

উপরের সবকিছুই Git এবং এটি যেকোনো সার্ভারের সাথেই কাজ করে। নিচের তিনটি শব্দ মূলত GitHub-এর ফিচার। অন্যান্য হোস্টিং সার্ভিস এগুলো নকল করে, কিন্তু Git নিজে এগুলোর ব্যাপারে কিছুই জানে না।

একটি pull request (PR) হলো এক branch থেকে অন্য branch-এ কোড মার্জ করার একটি অনুরোধ, যা আলোচনার জন্য একটি পেজে সাজানো থাকে। আপনি add-backup পুশ করেন, main-এর বিপরীতে একটি PR খোলেন এবং সাইটটি প্রতিটি commit অনুযায়ী পার্থক্যগুলো দেখায়। মানুষ নির্দিষ্ট লাইনে মন্তব্য করতে পারে। স্বয়ংক্রিয় চেকগুলো branch-এর বিপরীতে pass বা fail রিপোর্ট করে। মার্জ বাটনে ক্লিক করলে GitHub তার নিজস্ব কপিতে মার্জ সম্পন্ন করে এবং তারপর main আপডেট করে। এই নামটির উৎপত্তি মূল কর্মপদ্ধতি থেকে, যেখানে আপনি একজন মেইনটেইনারকে আপনার branch তাদের branch-এ pull করার অনুরোধ করতেন।

একটি issue হলো কোনো বাগ বা কাজের জন্য একটি নম্বরযুক্ত থ্রেড। এটি GitHub-এর ডেটাবেসে থাকে, আপনার রিপোজিটরিতে নয়। কোনো হোস্টিং সার্ভিস বেছে নেওয়ার আগে এটি জেনে রাখা জরুরি: রিপোজিটরি ক্লোন করলে আপনি সব commit পাবেন, কিন্তু একটি issue-ও পাবেন না। issue-গুলো বের করতে হলে API কল করতে হয়।

একটি fork হলো অন্য কারো রিপোজিটরির আপনার নিজস্ব সার্ভার-সাইড কপি। এই কপির ওপর আপনার রাইট এক্সেস থাকে, আপনি সেখানে একটি branch পুশ করতে পারেন এবং আপনার কপি থেকে মূল রিপোজিটরিতে একটি pull request খুলতে পারেন। এভাবেই আপনি এমন কোনো প্রজেক্টে অবদান রাখতে পারেন যাদের মেইনটেইনাররা আপনাকে চেনেন না। একটি fork হলো এমন একটি ক্লোন যা GitHub-এ থাকে এবং মনে রাখে যে এটি কোথা থেকে এসেছে।

সফটওয়্যার এই তিনটি বিষয়কেই সেই একই API-এর মাধ্যমে পড়ে যা একজন মানুষ ব্যবহার করেন। একটি pull request review agent যা আপনি আপনার নিজের সার্ভারে চালান নতুন PR-এর জন্য নজর রাখে, diff পড়ে এবং লাইনে মন্তব্য পোস্ট করে। রিপোজিটরির রুটে একটি AGENTS.md ফাইল-এর মতো কনভেনশনগুলো বিদ্যমান কারণ একটি রিপোজিটরি এখন মানুষের পাশাপাশি বিভিন্ন টুলের মাধ্যমেও পড়া হয়।

একজন VPS মালিকের জন্য GitHub আসলে যা করে

সার্ভারের বাইরের স্টোরেজ দিয়ে শুরু করুন। আপনার deploy script এবং playbook-গুলো এমন কোথাও রাখুন যা সেই সার্ভার নয় যাকে তারা কনফিগার করছে। একটি নতুন image থেকে VPS পুনরায় তৈরি করুন, clone করুন এবং চালান। সেই repository-টিকে private রাখুন এবং সার্ভারকে একটি deploy key দিন: এটি এমন একটি SSH key যা আপনার পুরো account-এর পরিবর্তে শুধুমাত্র একটি repository-র সাথে নিবন্ধিত এবং read-only মোডে সেট করা থাকে। একটি read-only deploy key ফাঁস হলে শুধুমাত্র একটি repo ঝুঁকির মুখে পড়ে। কিন্তু একটি account key ফাঁস হলে আপনি যা কিছু push করতে পারেন তার সবকিছুই ঝুঁকির মুখে পড়ে।

sudo git clone git@github.com:yourname/vps-deploy.git /srv/vps-deploy
cd /srv/vps-deploy
git pull --ff-only

--ff-only একটি merge commit তৈরি করতে অস্বীকার করে। যে সার্ভার শুধুমাত্র পরিবর্তন গ্রহণ করে, সেখানে merge সবসময়ই একটি দুর্ঘটনা। তাই এই flag-টি একটি বিভ্রান্তিকর history-কে একটি সাধারণ error-এ পরিণত করে: fatal: Not possible to fast-forward, aborting. সার্ভারে এমন কিছু পরিবর্তিত হয়েছে যা হওয়া উচিত ছিল না। পুনরায় pull করার আগে সেটি খুঁজে বের করুন।

root হিসেবে clone করে অন্য user হিসেবে Git চালালে আপনি fatal: detected dubious ownership in repository at '/srv/vps-deploy' পাবেন। Git অন্য user-এর মালিকানাধীন repository পড়তে অস্বীকার করে, কারণ একটি ক্ষতিকারক .git/config Git-কে দিয়ে কমান্ড চালাতে পারে। safe.directory exception যোগ করার পরিবর্তে chown দিয়ে মালিকানা ঠিক করুন, কারণ exception শুধুমাত্র কারণটি দূর না করেই চেকটিকে বন্ধ করে দেয়।

GitHub Actions: build এবং deploy পাইপলাইন

Actions হলো GitHub-এর CI/CD (continuous integration এবং continuous delivery) সিস্টেম। .github/workflows/ ডিরেক্টরির অধীনে একটি YAML ফাইল কমিট করুন, এবং আপনার নির্দিষ্ট করা ইভেন্ট ঘটলে GitHub সেটি রান করবে।

name: check
on:
  push:
    branches: [main]
jobs:
  shellcheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: sudo apt-get update && sudo apt-get install -y shellcheck
      - run: shellcheck *.sh

এই ফাইলটি একটি workflow। একটি job একটি মেশিনে চলে। একটি step হলো একটি কমান্ড অথবা একটি পাবলিশ করা অ্যাকশন। uses: অন্য কোনো রিপোজিটরি থেকে একটি অ্যাকশন নিয়ে আসে এবং @v7 সেটির মেজর ভার্সন পিন করে রাখে (আগস্ট 2026 অনুযায়ী actions/checkout-এর জন্য v7 বর্তমান ভার্সন)। সবসময় ভার্সন পিন করে রাখুন, কারণ পিন না করা অ্যাকশন মানে হলো এমন কোড যা আপনি পড়েননি এবং সেটি আপনার সিক্রেটগুলোতে অ্যাক্সেস পাচ্ছে।

runs-on: ubuntu-latest GitHub-এর কাছে একটি নতুন ভার্চুয়াল মেশিনের অনুরোধ করে, যা জব শেষ হওয়ার সাথে সাথে মুছে ফেলা হয়। পাবলিক রিপোজিটরিতে স্ট্যান্ডার্ড রানারগুলো ফ্রি এবং আগস্ট 2026 অনুযায়ী ফ্রি প্ল্যানে প্রাইভেট রিপোজিটরির জন্য প্রতি মাসে 2,000 মিনিট অন্তর্ভুক্ত থাকে। এই হিসাবের ওপর ভিত্তি করে বাজেট তৈরির আগে বর্তমান প্রাইসিং পেজটি যাচাই করে নিন।

সিক্রেটগুলো রিপোজিটরি সেটিংসে জমা থাকে এবং ${{ secrets.DEPLOY_KEY }} হিসেবে পড়া হয়। কোনো ফর্ক (fork) থেকে আসা পুল রিকোয়েস্টের মাধ্যমে ট্রিগার হওয়া ওয়ার্কফ্লো শুধুমাত্র রিড-অনলি টোকেন পায় এবং সিক্রেটগুলোতে কোনো অ্যাক্সেস পায় না। কারণ তা না হলে, অপরিচিত কেউ এমন একটি PR খুলতে পারত যার একমাত্র কাজ হতো সেই সিক্রেটগুলো প্রিন্ট করা।

আপনার নিজস্ব VPS-এ Actions runner চালানো

runs-on: self-hosted ব্যবহার করলে জবটি আপনার মালিকানাধীন একটি মেশিনে পাঠানো হয়। রিপোজিটরির রানার সেটিংস পেজ থেকে আপনি একটি ডাউনলোড লাইন, রিপোজিটরির ওয়েব অ্যাড্রেস এবং এক ঘণ্টা মেয়াদের একটি রেজিস্ট্রেশন টোকেন পাবেন। শেষ দুটি তথ্য REPO_URL এবং RUNNER_TOKEN-এ ইনপুট দিন, এরপর সেটআপের জন্য মাত্র তিনটি কমান্ড প্রয়োজন।

./config.sh --url "$REPO_URL" --token "$RUNNER_TOKEN"
sudo ./svc.sh install
sudo ./svc.sh start
./svc.sh status

svc.sh status কমান্ডটি সার্ভিসটিকে active হিসেবে দেখাবে এবং সাম্প্রতিক লগ লাইনগুলো প্রদর্শন করবে। রানারটি GitHub-এর সাথে একটি outbound HTTPS সংযোগ তৈরি করে কাজের জন্য অপেক্ষা করে, তাই এর জন্য কোনো inbound port খোলার প্রয়োজন নেই। svc.sh install কমান্ডটি systemd unit তৈরি করে, যা অনেকেই এড়িয়ে যান: এটি ছাড়া আপনার SSH সেশন বন্ধ হওয়ার সাথে সাথে রানারটিও বন্ধ হয়ে যাবে এবং পরবর্তী সব জব কোনো কারণ ছাড়াই কিউতে আটকে থাকবে। VPS-এ self-hosted runner সেটআপের পূর্ণাঙ্গ নির্দেশিকা-তে একটি দীর্ঘমেয়াদী রানারের জন্য প্রয়োজনীয় হার্ডেনিং এবং ক্লিনআপের ধাপগুলো বিস্তারিত আলোচনা করা হয়েছে।

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

একটি সতর্কবার্তা অবশ্যই মনে রাখবেন। GitHub-এর নিজস্ব ডকুমেন্টেশনে শুধুমাত্র প্রাইভেট রিপোজিটরির জন্য self-hosted runner ব্যবহারের পরামর্শ দেওয়া হয়েছে। কারণ পাবলিক রিপোজিটরির ফর্কগুলো পুল রিকোয়েস্ট খোলার মাধ্যমে আপনার রানারে বিপজ্জনক কোড চালাতে পারে। রানারটি ওই ব্রাঞ্চের workflow ফাইলে যা লেখা থাকে, ঠিক তাই কার্যকর করে। প্রাইভেট রিপোজিটরিতে যেখানে আপনি নিয়ন্ত্রণ করেন কারা পুশ করতে পারবে, সেখানে ঝুঁকি কম। কিন্তু পাবলিক রিপোজিটরির ক্ষেত্রে, যেকোনো self-hosted runner-কে এমন একটি মেশিন হিসেবে বিবেচনা করুন যেখানে অপরিচিত ব্যক্তিরা কোড চালাতে সক্ষম।

আপনার কি আদৌ GitHub প্রয়োজন?

না। Git হলো স্ট্যান্ডার্ড, আর GitHub হলো একটি সুবিধা মাত্র। Forgejo এবং Gitea হলো self-hosted forge; একটি forge হলো এমন একটি Git host যার সাথে issues এবং pull requests যুক্ত থাকে। উভয়ই একটি মাত্র Go binary হিসেবে রিলিজ হয় এবং ছোট একটি VPS-এ চলতে পারে। Forgejo হলো Gitea-এর 2022 সালের একটি fork, যা বর্তমানে Codeberg পরিচালনা করে। একটি repository স্থানান্তর করা মাত্র একটি কমান্ডের কাজ, কারণ এর wire protocol একই।

git remote -v
git remote set-url origin git@git.example.com:you/vps-deploy.git
git push origin main

প্রতিটি commit স্থানান্তর করা যায়, কারণ প্রতিটি clone-এ ইতিমধ্যে সম্পূর্ণ history থাকে। যা স্থানান্তর হয় না তা হলো GitHub-এর তৈরি করা উপরের স্তরটি: issues এবং pull request thread। CI-ও স্থানান্তর হয় না। Forgejo-এর নিজস্ব Actions implementation রয়েছে যা .forgejo/workflows/ থেকে একই ধরনের YAML পড়ে। এর ডকুমেন্টেশনে সীমাবদ্ধতাগুলো স্পষ্টভাবে বলা আছে যে, GitHub Actions এবং Forgejo Actions এক নয় এবং সবকিছু তাৎক্ষণিকভাবে কাজ নাও করতে পারে। এর জন্য নিজস্ব runner-ও প্রয়োজন। এই ধাপটিকে একটি copy হিসেবে নয়, বরং একটি port হিসেবে পরিকল্পনা করুন।

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

প্রথমে কী নষ্ট হয় এবং এরর মেসেজ কী বলে

একটি push প্রত্যাখ্যাত হয়েছে। আপনি এটি দেখতে পাবেন:

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:yourname/vps-deploy.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

আপনার শেষ pull-এর পর নতুন কিছু push করা হয়েছে, যা প্রায়শই ওয়েব এডিটরে আপনার করা কোনো পরিবর্তন হতে পারে। তাদের commit-এর ওপর আপনার commit-গুলো পুনরায় প্রয়োগ করতে git pull --rebase চালান, তারপর আবার push করুন। শেয়ার করা branch-এ git push --force ব্যবহার করা এড়িয়ে চলুন, কারণ এটি সার্ভার থেকে অন্য commit-গুলো মুছে ফেলে।

fatal: refusing to merge unrelated histories। আপনি স্থানীয়ভাবে git init চালিয়েছেন এবং GitHub-কে একটি README সহ রিপোজিটরি তৈরি করতে দিয়েছেন। এই দুটি ইতিহাসের মধ্যে কোনো সাধারণ commit নেই, তাই Git নিজে থেকে কিছু অনুমান করবে না। এর সঠিক সমাধান হলো GitHub-এর কপিটি একটি নতুন ফোল্ডারে clone করা এবং আপনার ফাইলগুলো সেখানে সরিয়ে নেওয়া।

error: src refspec main does not match any। আপনার দেওয়া নামের branch-টি এখানে নেই। সাধারণত রিপোজিটরিতে এখন পর্যন্ত কোনো commit থাকে না, অথবা আপনার branch-এর নাম master। git branch --show-current এটি সমাধান করবে।

একটি গোপন তথ্য commit-এ চলে গেছে। এখনই credential পরিবর্তন করুন (rotate করুন)। push করার মুহূর্ত থেকেই এটিকে পাবলিক হিসেবে গণ্য করুন, কারণ fork, mirror এবং ক্যাশ করা ভিউতে এমন কপি থাকে যা আপনার মুছে ফেলার কোনো উপায় নেই।

FAQ

GitHub এবং Git কি একই জিনিস?

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

আমার VPS-এ Git ব্যবহার করার জন্য কি GitHub অ্যাকাউন্টের প্রয়োজন আছে?

না। git init, git commit এবং git log কোনো রিমোট কনফিগারেশন ছাড়াই সার্ভারে কাজ করে, যা /etc ফাইলের পরিবর্তন ট্র্যাক করা বা স্ক্রিপ্ট ডেপ্লয় করার জন্য যথেষ্ট। সার্ভারের বাইরেও হিস্ট্রির একটি কপি রাখতে চাইলে অথবা অন্য কোনো মেশিন থেকে তা ক্লোন করতে চাইলে অ্যাকাউন্টের প্রয়োজন হয়। Forgejo বা Gitea-এর মতো সেলফ-হোস্টেড প্ল্যাটফর্মগুলো আপনার নিজস্ব হার্ডওয়্যারে একই চাহিদা পূরণ করে। এছাড়া, কোনো ফোর্জ সফটওয়্যার ছাড়াই অন্য একটি মেশিনে থাকা বেয়ার রিপোজিটরিতে সরাসরি SSH রিমোট ব্যবহার করেও কাজ করা সম্ভব।

পুল রিকোয়েস্ট (pull request) কী?

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

আমার নিজের VPS-এ কি GitHub Actions রানার চালানো উচিত?

প্রাইভেট রিপোজিটরির ক্ষেত্রে, সাধারণত হ্যাঁ। এতে কাজটি আপনার নিজস্ব হার্ডওয়্যারে সম্পন্ন হয়, কোনো মিনিট গুনতে হয় না, বিল্ড ক্যাশ দ্রুত থাকে এবং ডেপ্লয়মেন্টের জন্য ইন্টারনেটে কোনো ইনবাউন্ড SSH কি (key) উন্মুক্ত রাখার প্রয়োজন হয় না, কারণ রানার নিজেই GitHub-এর সাথে আউটবাউন্ড কানেকশন তৈরি করে কাজ গ্রহণ করে। পাবলিক রিপোজিটরির ক্ষেত্রে GitHub এটি না করার পরামর্শ দেয়: কারণ যে কেউ আপনার রিপোজিটরি ফোর্ক করে এমন একটি পুল রিকোয়েস্ট ওপেন করতে পারে যার ওয়ার্কফ্লো আপনার মেশিনে কোড রান করবে।

আমি কি পরবর্তীতে আমার রিপোজিটরিগুলো GitHub থেকে সরিয়ে নিতে পারব?

কোড সরানো খুব সহজ। প্রতিটি ক্লোন রিপোজিটরিতে সম্পূর্ণ হিস্ট্রি থাকে, তাই git remote set-url origin <new url> এবং এরপর একটি পুশ কমান্ডের মাধ্যমে কমিটে থাকা সবকিছু স্থানান্তর করা যায়। যা থেকে যায় তা হলো GitHub-এর নিজস্ব লেয়ার: ইস্যু, পুল রিকোয়েস্টের আলোচনা এবং অ্যাকশন হিস্ট্রি তাদের ডেটাবেসে থাকে, আপনার .git ফোল্ডারে নয়। মাইগ্রেশন টুল ব্যবহার করে API-এর মাধ্যমে ইস্যুগুলো কপি করা যায় এবং নতুন হোস্টের CI-এর জন্য সাধারণত ওয়ার্কফ্লো ফাইলগুলো এডিট করতে হয়। এই বিষয়টি মাথায় রেখে ইস্যু থ্রেডের পরিবর্তে রিপোজিটরির ভেতরেই মূল ডকুমেন্টেশন রাখা বুদ্ধিমানের কাজ।