৮.১ কাস্টমাইজিং গিট – গিট কনফিগারেশন
এখন পর্যন্ত, আমরা গিট কীভাবে কাজ করে এবং কীভাবে এটি ব্যবহার করতে হয় তার মূল বিষয়গুলি কভার করেছি এবং আমরা সহজে এবং দক্ষতার সাথে এটি ব্যবহার করতে আপনাকে সাহায্য করার জন্য গিট প্রদান করে এমন অনেকগুলি টুলস এর সাথে পরিচয় করেছি। এই অধ্যায়ে, আমরা দেখব কিভাবে আপনি গিটকে আরও কাস্টমাইজড ফ্যাশনে অপারেট করতে পারেন, বেশ কিছু গুরুত্বপূর্ণ কনফিগারেশন সেটিংস এবং হুক সিস্টেম ইউজ করে। এই টুলগুলির সাহায্যে, আপনার কোম্পানি বা আপনার গ্রুপ যেভাবে প্রয়োজন ঠিক সেভাবে গিটকে কাজ করানো সহজ।
গিট কনফিগারেশন
আপনি সংক্ষেপে গ্রেটিং স্টার্টেড পড়েছেন, আপনি নির্দিষ্ট করে দিতে পারেন গিট কনফিগারেশন সেটিংসে `git config` কমান্ড দিয়ে। প্রথম জিনিসগুলির মধ্যে একটি হল আপনার নাম এবং ইমেল ঠিকানা সেট আপ করা৷
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
এখন আপনি আরও কিছু আকর্ষণীয় বিকল্প শিখবেন যার মধ্যে আপনি আপনার গিট ব্যবহার কাস্টমাইজ করতে পারেন।
প্রথমত, একটি দ্রুত পর্যালোচনাঃ গিট একটি কনফিগারেশন ফাইলের সিরিজ ব্যবহার করে আপনার প্রত্যাশিত নন-ডিফল্ট আচরণ নির্ধারণ করে। প্রথমে গিট এই মানগুলির জন্য প্রথমে যে স্থানটি সন্ধান করে তা হল সিস্টেমের সর্বত্র [path]/etc/gitconfig ফাইলে, যেটিতে সেটিংস রয়েছে যা সিস্টেমের প্রতিটি ব্যবহারকারী এবং তাদের সমস্ত রিপোসিটোরিতে প্রয়োগ হয়। আপনি যদি এই –system অপশনটি git config এ পাস করেন, তবে এটি এই নির্দিষ্ট ফাইল থেকে পড়ে এবং লিখতে পারে।
গিট এর পরের যে জায়গাটিতে অনুসন্ধান করে তাহলো ~/.gitconfig (অথবা ~/.config/git/config) ফাইলে, যা প্রতিটি ব্যবহারকারীর জন্য নির্দিষ্ট। আপনি –global অপশনটি পাস করে গিটকে দিয়ে এই ফাইলটি পড়তে এবং লিখতে পারেন।
অবশেষে, আপনি বর্তমানে যেকোনো রিপোজিটরি ব্যবহার করছেন না কোনো, গিট কনফিগারেশন মানগুলি সন্ধান করে কনফিগারেশন ফাইলে তার গিট ডিরেক্টরিতে (.git/config) । এই মানগুলি সেই একক রিপোসিটোরির জন্য নির্দিষ্ট এবং বর্ণনা করে যদি –local অপশনটিকে git config-এ পাস করা হয়। আপনি কোন লেভেলের সাথে কাজ করবেন তা যদি নির্দিষ্ট না করেন, তাহলে এটাই ডিফল্ট ভাবে ব্যবহার হবে।
এই “লেভেলে`” (সিস্টেম, গ্লোবাল, লোকাল) এর প্রত্যেকটি পূর্ববর্তী স্তরের মানগুলিকে প্রতিস্থাপন করে, তাই উদাহরণস্বরূপ ভাবে .git/config-এর মানগুলি [path]/etc/gitconfig-এ থাকা মানগুলিকে প্রতিস্থাপন করে।
নোট
গিটের কনফিগারেশন ফাইলগুলি প্লেইন-টেক্সট, তাই আপনি ফাইলের এই মানগুলি সেট করে ফাইলটি নিজে পরিবর্তন করতে পারেন এবং সঠিক সিনট্যাক্স দিতে পারেন। এটি সাধারণত git config কমান্ড দিয়ে চালানো সহজতর। |
বেসিক ক্লায়েন্ট কনফিগারেশন
কনফিগারেশন অপশনগুলো গিট দুটি বিভাগে স্বীকৃতি দিয়ে থাকে: ক্লায়েন্ট-সাইড এবং সার্ভার-সাইড। বেশিরভাগ অপশনগুলো ক্লায়েন্ট-সাইডে – যা আপনার ব্যক্তিগত কাজ অনুযায়ী কনফিগার করে নিতে পারবেন। আরও অনেক কনফিগারেশন রয়েছে কিন্তু এর মধ্যে খুব অল্প সংখ্যকই দৈনন্দিন কাজের ক্ষেত্রে ব্যবহৃত হয়। আমরা এখানে বেশি ব্যবহৃত এবং প্রয়োজনীয় অপশনগুলো নিয়ে আলোচনা করব। আপনি যদি আপনার ব্যবহৃত গিটে ভার্সন অনুযায়ী সব অপশন গুলোর লিস্ট দেখতে চান, তাহলে এই কমান্ডটি ব্যবহার করুনঃ
$ man git-config
এই কমান্ডটি ব্যবহার করলে আপনি সব অপশন গুলোর কিছুটা বিস্তারিত বিবরণ পাবেন । এই ব্যাপারে আরও বিস্তারিত জানতে এই রেফারেন্স দেখতে পারেন https://git-scm.com/docs/git-config[^]।
উন্নত ব্যবহারের ক্ষেত্রে আপনি উপরে উল্লিখিত ডকুমেন্টেশনে “কন্ডিশনাল ইনক্লুডস” দেখতে পারেন।
core.editor
গতানুগতিক ভাবে, শেল এনভায়রনমেন্ট ভেরিয়েবল `ভিজ্যুয়াল` বা `এডিটর` এর মাধ্যমে আপনি আপনার ডিফল্ট টেক্সট এডিটর হিসাবে যা সেট করেছেন তা গিট ব্যবহার করে অথবা আপনার কমিট এবং ট্যাগ মেসেজ ক্রিয়েট এবং এডিট এর জন্য vi এডিটর এর কাছে ফিরে আসে। সেই ডিফল্টটিকে অন্য কিছুতে পরিবর্তন করতে, আপনি core.editor সেটিং ব্যবহার করতে পারেন:
$ git config --global core.editor emacs
এখন, আপনার ডিফল্ট শেল এডিটর হিসাবে সেট যাই করা হোক না কেন, গিট মেসেজেস এডিট করার জন্য এমাক্সই চালাবে।
commit.template
আপনি যদি এটিকে আপনার সিস্টেমে একটি ফাইলের পাথে সেট করেন, আপনি কমিট দেওয়ার সময় গিট সেই ফাইলটিকে ডিফল্ট মেসেজ হিসাবে ব্যবহার করবে। একটি কাস্টম কমিট টেমপ্লেট তৈরির মানে হল যে আপনি একটি কমিট মেসেজ তৈরি করার সময় সঠিক ফরমেট এবং স্টাইলটি নিজেকে (বা অন্যদের) মনে করিয়ে দিতে এটি ব্যবহার করতে পারেন।
উদাহরণস্বরূপ, ~/.gitmessage.txt-এ একটি টেমপ্লেট ফাইল বিবেচনা করুন যা দেখতে এইরকম:
Subject line (try to keep under 50 characters)
Multi-line description of commit,
feel free to be detailed.
[Ticket: X]
লক্ষ্য করুন কিভাবে এই কমিট টেমপ্লেটটি কমিটরকে সাবজেক্ট লাইনটি ছোট রাখার কথা মনে করিয়ে দেয় (git log –oneline আউটপুটের জন্য), এর অধীনে আরও বিশদ যোগ করে, এবং যদি একটি ইস্যু বা বাগ ট্র্যাকার টিকিট নম্বর বিদ্যমান থাকে তবে তা উল্লেখ করে।
আপনি যখন git commit চালান তখন আপনার এডিটরে প্রদর্শিত ডিফল্ট মেসেজটি ব্যবহার করতে গিট দ্বারা, commit.template কনফিগারেশন মান সেট করুন:
$ git config --global commit.template ~/.gitmessage.txt
$ git commit
তারপর, যখন আপনি কমিট করেন তখন আপনার প্লেসহোল্ডের কমিট মেসেজের জন্য আপনার এডিটর এরকম কিছু খুলবে:
Subject line (try to keep under 50 characters)
Multi-line description of commit,
feel free to be detailed.
[Ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C
যদি আপনার টিমের একটি কমিট-মেসেজ নীতি থাকে, তাহলে আপনার সিস্টেমে সেই নীতির জন্য একটি টেমপ্লেট স্থাপন করা এবং ডিফল্টরূপে এটি ব্যবহার করার জন্য গিট কনফিগার করা সেই নীতিটি নিয়মিত অনুসরণ করার সুযোগ বাড়াতে সাহায্য করে।
core.pager
এই সেটিং নির্ধারণ করে যে কোন পেজার ব্যবহার করা হবে যখন গিট পেজ আউটপুট যেমন `log` এবং `diff` হবে। আপনি এটিকে `more` বা আপনার প্রিয় পেজারে সেট করতে পারেন (ডিফল্টরূপে, এটি `less`), অথবা আপনি এটি একটি ফাঁকা স্ট্রিংয়ে সেট করে এটি বন্ধ করতে পারেন:
$ git config --global core.pager ' '
আপনি যদি এটি চালান, গিট সমস্ত কমান্ডের সম্পূর্ণ আউটপুট পেইজ করবে, সেগুলি যতই দীর্ঘ হোক না কেন।
user.signingkey
আপনি যদি সাইনড এনোটেটেড ট্যাগ তৈরি করেন (যেমন সাইনিং ইউর ওয়ার্ক এ আলোচনা করা হয়েছে), আপনার GPG সাইনিং কিইকে কনফিগারেশন সেটিং হিসাবে সেট করা হলে জিনিসগুলা সহজতর হয়ে যায়। আপনার কিই আইডি এভাবে সেট করুন:
$ git config --global user.signingkey <gpg-key-id>
এখন, আপনি `git tag` কমান্ডের সাহায্যে প্রতিবার আপনার কিই নির্দিষ্ট না করেই ট্যাগ সাইন করতে পারেন:
$ git tag -s <tag-name>
core.excludesfile
আপনি আপনার প্রোজেক্টের `.gitignore` ফাইলে প্যাটার্ন রাখতে পারেন যাতে গিট সেগুলিকে আনট্র্যাকড ফাইল হিসেবে না দেখতে পারে বা আপনি যখন সেগুলিতে `git add` চালান তখন সেগুলিকে স্টেজ করার চেষ্টা করুন, যেমন ইগনরিং ফাইলস এ আলোচনা করা হয়েছে
কিন্তু কখনও কখনও আপনি যে সমস্ত রিপোসিটোরিসের সাথে কাজ করেন তার জন্য নির্দিষ্ট কিছু ফাইলগুলিকে উপেক্ষা করতে চান। আপনার কম্পিউটার যদি ম্যাক ওএস চালায়, তাহলে আপনি সম্ভবত `.DS_Store` ফাইলগুলির সাথে পরিচিত৷ আপনার পছন্দের এডিটর যদি হয় Emacs বা Vim, তাহলে আপনি ফাইলের নাম সম্পর্কে জানেন যেগুলো একটি `~` বা `.swp` দিয়ে শেষ হয়।
এই সেটিং আপনাকে এক ধরনের গ্লোবাল `.gitignore` ফাইল লিখতে দেয়। আপনি যদি এই বিষয়বস্তুগুলি দিয়ে একটি `~/.gitignore_global` ফাইল তৈরি করেন:
*~
.*.swp
.DS_Store
…এবং আপনি `git config –global core.excludesfile ~/.gitignore_global` চালান, গিট আপনাকে আর কখনো সেই ফাইলগুলি নিয়ে বিরক্ত করবে না।
help.autocorrect
আপনি যদি একটি কমান্ড ভুল টাইপ করেন, এটি আপনাকে এরকম কিছু দেখায়:
$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.
The most similar command is
checkout
গিট সহায়কভাবে আপনি কী বোঝাতে চেয়েছিলেন তা বোঝার চেষ্টা করে, পরন্তু গিট এটি করতে অস্বীকার করে। আপনি যদি `help.autocorrect` 1 এ সেট করেন, গিট আসলে আপনার জন্য এই কমান্ডটি চালাবে:
$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...
নোট করুন যে “`০.১ সেকেন্ডস`” বিজনেস। `help.autocorrect` আসলে একটি পূর্ণসংখ্যা যা সেকেন্ডের দশমাংশকে উপস্থাপন করে। সুতরাং আপনি যদি এটি ৫০ এ সেট করেন, স্বয়ংক্রিয়ভাবে সংশোধন করা কমান্ড কার্যকর করার আগে গিট আপনাকে আপনার মন পরিবর্তন করতে ৫ সেকেন্ড সময় দেবে।
গিটে কালার
গিট সম্পূর্ণরূপে কালারড টার্মিনাল আউটপুট সমর্থন করে, যা দ্রুত এবং সহজেই কমান্ড আউটপুটকে ভিসুয়ালি পার্সিং করতে সাহায্য করে। অনেকগুলি অপশন আছে যা আপনাকে আপনার সাছন্দ অনুসারে কালার সেট করতে সহায়তা করতে পারে।
color.ui
গিট স্বয়ংক্রিয়ভাবে এর বেশিরভাগ আউটপুট কলার করে, তবে আপনি যদি এই আচরণটি পছন্দ না করেন তবে একটি মাস্টার সুইচ রয়েছে। সমস্ত গিট এর কালারড টার্মিনাল আউটপুট বন্ধ করতে, এটি করুন:
$ git config --global color.ui false
ডিফল্ট সেটিং হল `auto`, যা সরাসরি টার্মিনালে যাওয়ার সময় আউটপুটকে কালার করে, কিন্তু আউটপুটটি পাইপ বা ফাইলে পুনঃনির্দেশিত হলে কালার-নিয়ন্ত্রণ কোডগুলি বাদ দেয়।
টার্মিনাল এবং পাইপের মধ্যে পার্থক্য উপেক্ষা করতে আপনি এটিকে `always` সেট করতে পারেন।
আপনি খুব কমই এটি চাইবেন; বেশিরভাগ পরিস্থিতিতে, আপনি যদি আপনার পুনঃনির্দেশিত আউটপুটে কালার কোড চান তবে আপনি এটির পরিবর্তে একটি `–color` ফ্ল্যাগ গিট কমান্ডে পাস করতে পারেন যাতে এটিকে কালার কোড ব্যবহার করতে বাধ্য করে। আপনি যা চান ডিফল্ট সেটিং প্রায় সবসময় তাই হয়।
color.*
আপনি যদি আরও নির্দিষ্ট হতে চান যে কোন কমান্ডগুলি কালার হবে এবং কীভাবে হবে, গিট ভেরব-স্পেসিফিক কালার সেটিংস প্রদান করে। এগুলির প্রত্যেকটিকে `true`, `false`, বা `always` সেট করা যেতে পারে:
color.branch
color.diff
color.interactive
color.status
উপরন্তু, এর প্রত্যেকটির সাবসেটিং রয়েছে যা আপনি আউটপুটের অংশগুলির জন্য নির্দিষ্ট কালার সেট কারার জন্য ব্যবহার করতে পারেন, যদি আপনি প্রতিটি কালারকে ওভাররাইড করতে চান। উদাহরণস্বরূপ, আপনার ডিফ আউটপুটে মেটা তথ্যকে নীল ফোরগ্রাউন্ড, কালো ব্যাকগ্রাউন্ড এবং বোল্ড টেক্সটে সেট করতে চান, আপনি চালাতে পারেন:
$ git config --global color.diff.meta "blue black bold"
আপনি নিম্নলিখিত মানগুলির যেকোন একটিতে কালার সেট করতে পারেন: `normal`, `black`, `red`, `green`, `yellow`, `blue`, `magenta`, `cyan`, বা `white`। আপনি যদি আগের উদাহরণে বোল্ডের মতো একটি এট্রিবিউট চান, আপনি `bold`, `dim`, `ul`(আন্ডারলাইন), `blink`, এবং `reverse` (ফোরগ্রাউন্ড এবং ব্যাকগ্রাউন্ড অদলবদল করা) থেকে বেছে নিতে পারেন।
এক্সট্রানাল মার্জ এন্ড ডিফ টুলস
যদিও গিটে ডিফ এর একটি ইন্টারনাল ইমপ্লিমেন্টেশন রয়েছে, যা আমরা এই বইটিতে দেখিয়েছি, আপনি যার পরিবর্তে একটি এক্সটার্নাল টুল সেটআপ করতে পারেন। ম্যানুয়ালি কনফ্লিক্টস রেসল্ভে করার পরিবর্তে আপনি একটি গ্রাফিক্যাল মার্জ-কনফ্লিক্ট-রেজোলিউশন টুল সেট আপ করতে পারেন। আমরা পারফোর্স ভিজ্যুয়াল মার্জ টুল (P4Merge) সেট আপ করবো, যার মাধ্যমে আপনার ডিফ এবং মার্জ রেজোলিউশন করা যাবে। কারণ এটি একটি চমৎকার গ্রাফিকাল টুল এবং এটি বিনামূল্যে পাওয়া যায়।
আপনি যদি এটি চেষ্টা করে দেখতে চান, P4Merge সমস্ত প্রধান প্ল্যাটফর্মে কাজ করে, তাই আপনার এটি করতে সক্ষম হওয়া উচিত। আমরা ম্যাকওএস, লিনাক্স সিস্টেমে এবং উইন্ডোজের জন্য কাজ করে এমন পথের নাম ব্যবহার করব, আপনাকে আপনার এনভায়রনমেন্টের এক্সিকিউটেবল পাথে `/usr/local/bin` পরিবর্তন করতে হবে।
শুরু করা, পারফোর্স থেকে P4Merge ডাউনলোড করুন এর পরে, আপনি আপনার কমান্ড চালানোর জন্য এক্সটার্নাল র্যাপার স্ক্রিপ্ট সেট আপ করবেন। আমরা এক্সিকিউটেবলের জন্য ম্যাকওএস পাথ ব্যবহার করব; অন্যান্য সিস্টেমে, এটি হবে যেখানে আপনার `p4merge` বাইনারি ইনস্টল করা আছে।
‘extMerge’ নামে একটি মার্জ র্যাপার স্ক্রিপ্ট সেট আপ করুন যা প্রদত্ত সমস্ত আর্গুমেন্ট সহ আপনার বাইনারি কল করে:
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*
সাতটি আর্গুমেন্ট প্রদান করা হয়েছে তা নিশ্চিত করতে ডিফ র্যাপার চেক করে এবং এর মধ্যে দুটি আপনার মার্জ স্ক্রিপ্টে পাস করে। ডিফল্ট ভাবে, গিট ডিফ প্রোগ্রামে নিম্নলিখিত আর্গুমেন্টগুলি পাস করে:
path old-file old-hex old-mode new-file new-hex new-mode
যেহেতু আপনি শুধুমাত্র `old-file` এবং `new-file` আর্গুমেন্ট চান, আপনি আপনার প্রয়োজনীয়গুলি র্যাপার স্ক্রিপ্টে পাস করে ব্যবহার করতে পারবেন।
$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
আপনাকে নিশ্চিত করতে হবে যে এই টুলসগুলো এক্সেকিউটাবল:
$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff
এখন আপনি আপনার কনফিগার ফাইল ব্যবহার করতে কাস্টম মার্জ রেজোলিউশন এবং ডিফ টুল সেট আপ করতে পারেন। এর জন্য বেশ কয়েকটি কাস্টম সেটিংস লাগবে: `merge.tool` দিয়ে গিট নির্ধারণ করবে কোন স্ট্রাটেজি সে ব্যাবহার করবে, এবং `mergetool.<tool>.cmd` দিয়ে নির্দিষ্ট করবে কোন কমান্ডটি চালাবে, `mergetool.<tool>.trustExitCode` দিয়ে গিট নির্ধারণ করে যে, প্রোগ্রামের এক্সিট কোড নির্দেশ করে সফল মার্জ রেজোলিউশন হইয়েছে কিনা; এবং `diff.external` দিয়ে গিট নির্ধারণ করে, কোন কমান্ড দিয়ে ডিফ চালানো যাবে। সুতরাং, আপনি হয় এই চারটি কনফিগার কমান্ড চালাতে পারেন:
$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd \
'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"'
$ git config --global mergetool.extMerge.trustExitCode false
$ git config --global diff.external extDiff
অথবা আপনি এই লাইনগুলি যোগ করে আপনার `~/.gitconfig` ফাইলটি এডিট করতে পারেন:
[merge]
tool = extMerge
[mergetool "extMerge"]
cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
trustExitCode = false
[diff]
external = extDiff
এই সব সেট করার পরে, আপনি যদি এই রকম ডিফ কমান্ড চালান:
$ git diff 32d1776b1^ 32d1776b1
কমান্ড লাইনে ডিফ আউটপুট পাওয়ার পরিবর্তে, গিট P4Merge ফায়ার করে, যা দেখতে কিছুটা এরকম:
আপনি যদি দুটি ব্রাঞ্চেস মার্জ করার চেষ্টা করেন এবং পরবর্তীতে মার্জ কনফ্লিক্টস দেখা দেয়, তাহলে আপনি `git mergetool` কমান্ডটি চালাতে পারেন; এটি P4Merge শুরু করে যাতে আপনি সেই GUI টুলের মাধ্যমে কনফ্লিক্ট রেসল্ভে করতে পারেন।
এই র্যাপার সেটআপ সম্পর্কে চমৎকার জিনিস হল যে আপনি সহজেই আপনার ডিফ পরিবর্তন করতে পারেন এবং টুলগুলোকে মার্জ করতে পারেন। উদাহরণস্বরূপ, আপনার `extDiff` এবং `extMerge` টুল চালানোর পরিবর্তে KDiff3 টুল চালালে, আপনাকে যা করতে হবে তা হল আপনার `extMerge` ফাইলটি এডিট করুন:
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
এখন, গিট ডিফ দেখার জন্য KDiff3 টুল ব্যবহার করবে এবং মার্জ কনফ্লিক্ট রেসল্ভে করবে।
গিট আপনার সিএমডি কনফিগারেশন সেট আপ না করেই অন্যান্য একাধিক মার্জ-রেজোলিউশন টুল ব্যবহার করার জন্য প্রিসেট আসে। এটি সমর্থন করে এমন টুলগুলির একটি তালিকা দেখতে পারেন:
$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
emerge
gvimdiff
gvimdiff2
opendiff
p4merge
vimdiff
vimdiff2
The following tools are valid, but not currently available:
araxis
bc3
codecompare
deltawalker
diffmerge
diffuse
ecmerge
kdiff3
meld
tkdiff
tortoisemerge
xxdiff
Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.
আপনি যদি ডিফের জন্য KDiff3 ব্যবহার করতে আগ্রহী না হন তবে শুধুমাত্র মার্জ রেজোলিউশনের জন্য এটি ব্যবহার করতে চান এবং kdiff3 কমান্ডটি আপনার পথে রয়েছে, তাহলে আপনি চালাতে পারেন:
$ git config --global merge.tool kdiff3
আপনি যদি `extMerge` এবং `extDiff` ফাইল সেট আপ করার পরিবর্তে এটি চালান, গিট মার্জ রেজোলিউশনের জন্য KDiff3 এবং ডিফের জন্য সাধারণ গিট ডিফ টুল ব্যবহার করবে।
ফরম্যাটিং এন্ড হোয়াইটস্পেস
ফরম্যাটিং এবং হোয়াইটস্পেস ইস্যুস হল কিছুটা হতাশাজনক এবং সূক্ষ্ম সমস্যা যা অনেক ডেভেলপার সমন্বয়ে কাজ করার সময় সম্মুখীন হয়, বিশেষ করে ক্রস-প্ল্যাটফর্মে। প্যাচ বা অন্যান্য সমন্বয় কাজের সময় সূক্ষ্ম হোয়াইটস্পেস পরিবর্তনগুলি প্রবর্তন করা খুব সহজ কারণ এডিটরস নীরবে তাদের পরিচয় করিয়ে দেয়, এবং যদি আপনার ফাইলগুলি কখনও উইন্ডোজ সিস্টেমকে টাচ করে তবে তাদের লাইনের শেষগুলি প্রতিস্থাপিত হতে পারে। এই ইস্যুগুলির সমাধানের জন্য গিটের কয়েকটি কনফিগারেশন অপশন রয়েছে।
core.autocrlf
আপনি যদি উইন্ডোজে প্রোগ্রামিং করেন এবং এমন লোকেদের সাথে কাজ করেন যারা অন্যান্য প্লাটফরমে কাজ করেন, আপনি সম্ভবত কোন এক সময় লাইন-এন্ডিং সমস্যায় পড়বেন। কারণ উইন্ডোজ তার ফাইলগুলিতে নতুন লাইনের জন্য একটি ক্যারেজ-রিটার্ন অক্ষর এবং একটি লাইনফিড অক্ষর উভয়ই ব্যবহার করে, যেখানে ম্যাকওএস এবং লিনাক্স সিস্টেম শুধুমাত্র লাইনফিড অক্ষর ব্যবহার করে। এটি ক্রস-প্ল্যাটফর্ম কাজের একটি সূক্ষ্ম কিন্তু অবিশ্বাস্যভাবে বিরক্তিকর সত্য; উইন্ডোজের অনেক এডিটর নীরবে বিদ্যমান LF-স্টাইলের লাইনের শেষগুলিকে CRLF দিয়ে প্রতিস্থাপন করে, অথবা ব্যবহারকারী এন্টার কিই চাপলে উভয় লাইনের-এন্ডিং অক্ষর যুক্ত করে।
আপনি যখন ইনডেক্সে একটি ফাইল যোগ করেন তখন গিট CRLF লাইনের শেষগুলিকে স্বয়ংক্রিয়ভাবে LF-তে রূপান্তর করতে পারে এবং এর বিপরীতে যখন এটি আপনার ফাইল সিস্টেমে কোড চেক করে।
আপনি `core.autocrlf` সেটিং দিয়ে এই কার্যকারিতা চালু করতে পারেন। আপনি `core.autocrlf` সেটিং দিয়ে আপনি যদি একটি উইন্ডোজ মেশিনে থাকেন তবে এটিকে `true` তে সেট করুন — আপনি কোড চেক করার সময় এটি LF দিয়ে শেষগুলিকে CRLF-এ রূপান্তরিত করে:
$ git config --global core.autocrlf true
আপনি যদি একটি লিনাক্স বা ম্যাকওএস সিস্টেমে থাকেন যা LF লাইনের শেষ ব্যবহার করে, তাহলে আপনি চান না যে আপনি ফাইলগুলি চেক করার সময় গিট স্বয়ংক্রিয়ভাবে তাদের রূপান্তর করুক; যদি CRLF এন্ডিং সহ একটি ফাইল ভুলবশত চালু হয়ে যায়, তাহলে আপনি গিট দিয়ে এটি ঠিক করতে পারেন। আপনি গিটকে কমিটের সময় CRLF কে LF তে রূপান্তর করতে বলতে পারেন কিন্তু অন্যভাবে `core.autocrlf` কে `input` সেট করে নয়:
$ git config --global core.autocrlf input
এই সেটআপটি আপনাকে উইন্ডোজ চেকআউটে CRLF শেষেরগুলিকে ছেড়ে দেবে, কিন্তু LF শেষ হবে ম্যাকওএস এবং লিনাক্স সিস্টেমে এবং রিপোসিটোরিতে।
আপনি যদি একজন উইন্ডোজ প্রোগ্রামার হন একটি উইন্ডোজ-অনলি প্রজেক্ট করছেন, তাহলে আপনি এই কার্যকারিতা বন্ধ করতে পারেন, কনফিগারের মান `false` সেট করার মাধ্যমে রিপোসিটোরিতে ক্যারেজ রিটার্ন রেকর্ড করে:
$ git config --global core.autocrlf false
core.whitespace
কিছু হোয়াইটস্পেস ইস্যুস সনাক্ত এবং সমাধান করতে গিট প্রিসেট আসে। এটি ছয়টি প্রাথমিক হোয়াইটস্পেস ইস্যুস সন্ধান করতে পারে –তিনটি ডিফল্টরূপে সক্ষম এবং বন্ধ করতে পারে, এবং তিনটি ডিফল্টরূপে বন্ধ করা থাকে তবে সক্রিয় করা যেতে পারে।
ডিফল্টরূপে চালু করা তিনটি হল `blank-at-eol`, যা একটি লাইনের শেষে স্পেস খোঁজে; `blank-at-eof`, যা একটি ফাইলের শেষে ফাঁকা লাইন লক্ষ্য করে; এবং `space-before-tab`, যা একটি লাইনের শুরুতে ট্যাবের আগে স্পেস খোঁজে।
যে তিনটি ডিফল্টরূপে বন্ধ থাকে কিন্তু চালু করা যায় তা হল `indent-with-non-tab`, যা ট্যাবের পরিবর্তে স্পেস দিয়ে শুরু হওয়া লাইনের সন্ধান করে (এবং `tabwidth` অপশন দ্বারা নিয়ন্ত্রিত হয়); `tab-in-indent`, যা একটি লাইনের ইন্ডেন্টেশন অংশে ট্যাবগুলির জন্য লক্ষ্য করে; এবং `cr-at-eol`, যা গিটকে বলে যে লাইনের শেষে ক্যারেজ রিটার্ন ঠিক আছে।
আপনি গিটকে বলতে পারেন যে, যেসকল মানগুলোকে চালু বা বন্ধ করতে পারেন `core.whitespace` সেট করে (যা কমা দিয়ে আলাদা করা)। আপনি একটি অপশনকে বন্ধ করতে পারেন, তার নামের সামনে একটি `-` লিখে, অথবা সেটিকে সম্পূর্ণরূপে সেটিং স্ট্রিংয়ের বাইরে রেখে ডিফল্ট মান ব্যবহার করতে পারেন। উদাহরণস্বরূপভাবে, আপনি যদি `space-before-tab` সেট হওয়া সত্ত্বেও বাকি সব চান, তাহলে আপনি এটি করতে পারেন (`trailing-space` এটি শর্ট-হ্যান্ড হিসেবে উভয়কেই কভার করে `blank-at-eol` এবং `blank-at-eof`)
$ git config --global core.whitespace \
trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol
অথবা আপনি শুধুমাত্র কাস্টমাইজিং অংশ নির্দিষ্ট করতে পারেন:
$ git config --global core.whitespace \
-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol
আপনি যখন একটি `git diff` কমান্ড চালান তখন গিট এই ইস্যুসগুলো সনাক্ত করে এবং সেগুলিকে কালার করে যাতে আপনি কমিট দেওয়ার আগে সেগুলি ঠিক করতে পারেন। আপনি যখন `git apply` এর সাথে প্যাচ প্রয়োগ করবেন তখন এটি মানগুলিও ব্যবহারের মাধ্যমে আপনাকে সাহায্য করবে। আপনি যখন প্যাচগুলি প্রয়োগ করছেন, আপনি গিটকে সতর্ক করতে বলতে পারেন যদি এটি নির্দিষ্ট হোয়াইটস্পেস ইস্যুগুলির সাথে প্যাচ প্রয়োগ করে:
$ git apply --whitespace=warn <patch>
অথবা আপনি প্যাচ প্রয়োগ করার আগে গিট স্বয়ংক্রিয়ভাবে ইস্যুটি সমাধান করার চেষ্টা করতে পারে:
$ git apply --whitespace=fix <patch>
এই অপশনগুলি ‘git rebase’ কমান্ডের ক্ষেত্রেও প্রযোজ্য। আপনি যদি হোয়াইটস্পেস ইস্যুগুলি কমিটেড করে থাকেন কিন্তু এখনও আপস্ট্রিমে না দিলে, তাহলে আপনি `git rebase –whitespace=fix` চালাতে পারেন যাতে গিট স্বয়ংক্রিয়ভাবে হোয়াইটস্পেস ইস্যুগুলি ঠিক করে দেয় যেভাবে গিট প্যাচগুলি পুনরায় লিখে।
সার্ভার কনফিগারেশন
গিটের সার্ভার সাইডের জন্য প্রায় অনেকগুলি কনফিগারেশন অপশন থাকে না, তবে কয়েকটি আকর্ষণীয় অপশন রয়েছে যা আপনি নোট করতে পারেন।
receive.fsckObjects
গিট নিশ্চিত করে যে একটি পুশের সময় প্রাপ্ত প্রতিটি অবজেক্ট এখনও তার SHA-1 চেকসামের সাথে মেলে এবং বৈধ অবজেক্টটির দিকে নির্দেশ করে। যাইহোক, ডিফল্টরূপে গিট এটি করে না; এটি একটি মোটামুটি ব্যয়বহুল অপারেশন, এবং অপারেশনটিকে ধীর করে দিতে পারে, বিশেষ করে বড় রিপোসিটোরিতে বা পুশের ক্ষেত্রে। আপনি যদি গিটকে প্রতিটি পুশের অবজেক্টটির কন্সিস্টেন্সি চেক করতে চান তবে আপনি `receive.fsckObjects` কে true সেট করে এটি করতে বাধ্য করতে পারেন:
$ git config --system receive.fsckObjects true
এখন, গিট প্রতিটি পুশ করবার আগে রিপোসিটোরির ইন্টিগ্রিটি চেক করে, যেন কোনও ধরনের ফল্টটি (বা মেলিসিয়াস) ক্লায়েন্ট ডাটা করাপ্টেড করতে না পারে।
receive.denyNonFastForwards
আপনি যদি রিবেস কমিট করেন যে আপনি ইতিমধ্যেই পুশ দিয়েছেন এবং তারপরে আবার পুশ করার চেষ্টা করেন, অথবা অন্যথায় রিমোট ব্রাঞ্চে একটি কমিট পুশ করার চেষ্টা করুন যাতে বর্তমানে যে রিমোট ব্রাঞ্চটি নির্দেশ করছে সেই ব্রাঞ্চে কমিটটি না থাকলে, আপনাকে প্রত্যাখ্যান করা হবে। এটি সাধারণত ভাল নীতি; কিন্তু রিবেসের ক্ষেত্রে, আপনি নির্ধারণ করতে পারেন যে আপনি কী করছেন তা আপনি জানেন এবং আপনার পুশ কমান্ডে `-f` ফ্ল্যাগ সহ রিমোট ব্রাঞ্চকে জোরপূর্বক ভাবে আপডেট করতে পারেন।
`receive.denyNonFastForwards` সেট করার মাধ্যমে গিট ফোর্স-পুশ প্রত্যাখ্যান করেঃ
$ git config --system receive.denyNonFastForwards true
অন্য যেভাবে আপনি এটি করতে পারেন তা হল সার্ভার-সাইড রিসিভ হুকের মাধ্যমে, যা আমরা একটু পরে কভার করব। এই পদ্ধতিটি আপনাকে আরও জটিল জিনিসগুলি করতে দেয় যেমন একটি নির্দিষ্ট উপসেটের ব্যবহারকারীদের নন-ফাস্ট-ফরওয়ার্ড অস্বীকার করা।
receive.denyDeletes
`denyNonFastForwards` নীতির একটি সমাধান হল ব্যবহারকারীর জন্য ব্রাঞ্চটি ডিলিট করে ফেলা এবং তারপরে নতুন রেফারেন্স সহ এটিকে ব্যাক আপ করা। এটি এড়াতে, ‘receive.denyDeletes‘ কে true সেট করুন:
$ git config --system receive.denyDeletes true
এটি ব্রাঞ্চ বা ট্যাগগুলিকে ডিলিট করতে দেই করে না — কোনও ব্যবহারকারী এটি করতে পারে না৷ রিমোট ব্রাঞ্চগুলি সরাতে, আপনাকে অবশ্যই সার্ভার থেকে রেফ ফাইলগুলি ম্যানুয়ালি সরিয়ে ফেলতে হবে। ACLs -এর মাধ্যমে প্রতি-ব্যবহারকারীর ভিত্তিতে এটি করার আরও আকর্ষণীয় উপায় রয়েছে, যা আপনি এক্সাম্পল গিট-এনফোর্স পলিসি এ শিখবেন।
