পুশ করা — এটি কী, git push কীভাবে কাজ করে এবং কখন প্রয়োজন

Git-এ পুশ কী

Git push হল একটি কমান্ড যা লোকাল রিপোজিটরি থেকে রিমোট রিপোজিটরিতে কমিট স্থানান্তর করে। commit-এর বিপরীতে, যা শুধুমাত্র ডেভেলপারের লোকাল মেশিনে পরিবর্তন সংরক্ষণ করে, পুশ সেই পরিবর্তনগুলি পুরো টিমের জন্য প্রকাশ করে। Push একটি Pull Request তৈরি এবং ডিপ্লয়মেন্টের আগে একটি বাধ্যতামূলক পদক্ষেপ।

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

# origin remote, main ব্রাঞ্চে পুশ করুন
git push origin main

# বর্তমান ব্রাঞ্চটি upstream সহ remote-এ পুশ করুন
git push -u origin feature/new-dashboard

# মিলে যাওয়া নাম সহ সমস্ত ব্রাঞ্চ পুশ করুন
git push --all origin

# লিজ সহ ফোর্স পুশ (নিরাপদ ফোর্স পুশ)
git push --force-with-lease

পুশ করার পরে, রিমোট রিপোজিটরি রেফগুলি (ব্রাঞ্চ রেফারেন্স) আপডেট করে যাতে তারা নতুন কমিটগুলিকে নির্দেশ করে। অন্যান্য ডেভেলপাররা git pull বা git fetch-এর মাধ্যমে এই পরিবর্তনগুলি পেতে পারেন। কমিটের এই বিনিময় সহযোগিতামূলক ডেভেলপমেন্টের ভিত্তি তৈরি করে।

git push কীভাবে কাজ করে

git push কমান্ড লোকাল এবং রিমোট ব্রাঞ্চের তুলনা করে এবং শুধুমাত্র অনুপস্থিত কমিটগুলি স্থানান্তর করে। Git সমস্ত ফাইল পুনরায় পাঠায় না — এটি শুধুমাত্র ডেল্টা স্থানান্তর করে, যা বড় রিপোজিটরির জন্যও পুশকে দ্রুত করে তোলে। Git প্রোটোকল স্মার্ট ট্রান্সফার ব্যবহার করে, যা প্রেরিত ডেটার পরিমাণ কমিয়ে আনে।

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

রিমোট রিপোজিটরি বোঝা সঠিক পুশের চাবিকাঠি। সাধারণত, origin হল ডিফল্ট রিমোট রিপোজিটরির নাম। git remote -v কমান্ড রিমোট রিপোজিটরি এবং তাদের URL-এর তালিকা দেখায়। আপনি একাধিক রিমোট যোগ করতে পারেন (যেমন, মূল রিপোজিটরির জন্য origin এবং ফর্কের জন্য upstream)।

কখন পরিবর্তন পুশ করবেন

মূল নিয়ম: কাজের প্রতিটি যৌক্তিকভাবে সম্পন্ন পর্যায়ের পরে পুশ করুন। যদি একজন ডেভেলপার কোনো কাজ বা তার অংশ শেষ করে থাকেন — তাহলে পুশ করার সময় এসেছে। তবে, অসম্পূর্ণ কাজ যা বিল্ড ভাঙে তা পুশ করা সুপারিশ করা হয় না। বিল্ড না ভাঙা যেকোনো ব্রাঞ্চে পুশ করার জন্য ন্যূনতম প্রয়োজনীয়তা।

টিম ডেভেলপমেন্টে নিম্নলিখিত ছন্দ অনুসরণ করা হয়: সকালে — সহকর্মীদের পরিবর্তন পেতে git pull, দিনে — কয়েকটি কমিট এবং এক বা দুটি পুশ, সন্ধ্যায় — সমস্ত সম্পন্ন কাজের চূড়ান্ত পুশ। ডেভেলপার যত বেশি পুশ করেন, মার্জ দ্বন্দ্বের ঝুঁকি তত কম এবং কাজের অগ্রগতি তত স্বচ্ছ হয়।

• কাজ শেষ করার পরে — কমিট করুন এবং ফিচার ব্রাঞ্চে চূড়ান্ত সমাধান পুশ করুন
• চলে যাওয়ার আগে — অসম্পূর্ণ কাজ ফিচার ব্রাঞ্চে পুশ করুন (main-এ নয়!)
• PR তৈরি করার আগে — নিশ্চিত করুন যে সমস্ত কমিট পুশ করা হয়েছে এবং পর্যালোচনার জন্য উপলব্ধ
• রিবেস করার পরে --force-with-lease দিয়ে আপনার ফিচার ব্রাঞ্চে পুশ করুন

নিরাপদ পুশের নিয়ম

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

দ্বিতীয় নিয়ম: পুশ করার আগে রিমোট ব্রাঞ্চের সাথে সিঙ্ক্রোনাইজ করুন। মার্জ করার সময় মার্জ কমিট এড়াতে git pull --rebase চালান। এটি ইতিহাসকে সরল এবং রৈখিক করে। যদি পুশ প্রত্যাখ্যান করা হয় — তাহলে খালি ফোর্স পুশ ব্যবহার করবেন না, বরং প্রথমে খুঁজে বের করুন রিমোট ব্রাঞ্চে কোন কমিটগুলি এসেছে।

তৃতীয় নিয়ম: প্রি-পুশ হুক সেট আপ করুন যা পাঠানোর আগে স্বয়ংক্রিয়ভাবে টেস্ট এবং লিন্টার চালায়। যদি টেস্ট ব্যর্থ হয় — পুশ ব্লক হয়ে যায়। এই ধরনের হুক Husky বা Git হুক (pre-push ফাইল .git/hooks-এ) এর মাধ্যমে কনফিগার করা হয়।

চতুর্থ নিয়ম: বড় বাইনারি ফাইল পুশ করবেন না। Git বাইনারি আর্টিফ্যাক্ট সংরক্ষণের জন্য ডিজাইন করা হয়নি — এগুলি রিপোজিটরিকে স্ফীত করে এবং অপারেশন ধীর করে দেয়। বড় ফাইলের জন্য, Git LFS (Large File Storage) ব্যবহার করুন। যদি কোনো বাইনারি ইতিমধ্যে পুশ করা হয়ে থাকে এবং ইতিহাসে থাকে, তবে এটি git filter-branch-এর মাধ্যমে সরানো উচিত।

পুশ ব্যর্থ হলে কী করবেন

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

# পুশ প্রত্যাখ্যান — প্রথমে fetch এবং rebase করুন
git fetch origin
git rebase origin/main
# দ্বন্দ্ব সমাধান করুন, তারপর:
git push --force-with-lease

# অথবা কেবল রিমোট পরিবর্তনগুলি মার্জ করুন
git pull origin main
git push

দ্বিতীয় কারণ — ব্রাঞ্চে লেখার অনুমতির অভাব। যদি main ব্রাঞ্চ ব্রাঞ্চ প্রোটেকশন নিয়ম দ্বারা সুরক্ষিত থাকে, তাহলে সরাসরি পুশ নিষিদ্ধ। সমাধান: ফিচার ব্রাঞ্চে পুশ করুন এবং একটি Pull Request তৈরি করুন। সুরক্ষা সেটিংস সাধারণত GitHub সেটিংস বা GitLab সুরক্ষিত ব্রাঞ্চের মাধ্যমে পরিচালিত হয়।

তৃতীয় কারণ — প্রমাণীকরণ সমস্যা। পুরানো ক্রেডেনশিয়াল, SSH-তে স্যুইচ করা বা ব্যক্তিগত অ্যাক্সেস টোকেন পরিবর্তন। সমাধান: রিমোট URL (git remote -v) পরীক্ষা করুন এবং ক্রেডেনশিয়াল আপডেট করুন। 2021 সাল থেকে, GitHub HTTPS-এর জন্য পাসওয়ার্ড প্রমাণীকরণ বন্ধ করে দিয়েছে — ব্যক্তিগত টোকেন বা SSH কী ব্যবহার করুন।