৭.১ গিট টুলস – রিভিশন সিলেকশন
এখন পর্যন্ত, আপনি আপনার সোর্স কোড নিয়ন্ত্রণের জন্য একটি গিট রিপোজিটরি পরিচালনা বা রক্ষণাবেক্ষণ এর জন্যে প্রয়োজনীয় প্রতিদিনের কাজ চালানোর মত অধিকাংশ কমান্ড এবং ওয়ার্কফ্লো শিখে ফেলেছেন। আপনি ফাইলগুলি ট্র্যাকিং এবং কমিট করার প্রাথমিক কাজগুলি সম্পন্ন করেছেন, এবং আপনি স্টেজিং এরিয়া এবং লাইটওয়েট টপিক ব্রাঞ্চিং এবং মার্জিং করার ক্ষমতা ব্যবহার করেছেন।
এখন আপনি গিট করতে পারে এমন অনেকগুলি শক্তিশালী জিনিস অন্বেষণ করবেন যেগুলো হয়ত আপনি প্রতিদিন এর জন্য ব্যবহার নাও করতে পারেন, তবে কোনও সময়ে আপনার প্রয়োজন হতে পারে।
রিভিশন নির্বাচন
গিট আপনাকে বিভিন্ন উপায়ে একটি সিঙ্গেল কমিট , কমিটের সেট বা কমিটের পরিসর উল্লেখ করতে দেয়। এই উপায়পগুলো অগত্যা স্পষ্ট নয় কিন্তু জেনে রাখা সহায়ক।
একক সংশোধন
আপনি স্পষ্টতই সিঙ্গেল কমিট এর পূর্ণ 40-অক্ষরের SHA-1 হ্যাশ দ্বারা, সেই সিঙ্গেল কমিট উল্লেখ করতে পারেন, তবে কমিটগুলি উল্লেখ করার জন্য আরও হিউম্যান ফ্রেন্ডলি উপায় রয়েছে।
এই সেকশনে একটি কমিট বিভিন্ন উপায়ে রেফার করার বিষয়ে আলোকপাত করা হবে।
সংক্ষিপ্ত SHA-1
আপনি যদি SHA-1 হ্যাশের প্রথম কয়েকটি অক্ষর প্রদান করেন তবে আপনি কোন কমিট এর কথা উল্লেখ করছেন তা নির্ধারণ করতে গিট যথেষ্ট স্মার্ট, যতক্ষণ না সেই আংশিক হ্যাশটি কমপক্ষে চারটি অক্ষর দীর্ঘ এবং স্পষ্ট হয়; অর্থাৎ, অবজেক্ট ডাটাবেজের অন্য কোনো অবজেক্টে একই prefix দিয়ে শুরু হওয়া অন্য কোন হ্যাশ থাকতে পারবে না।
উদাহরণস্বরূপ, একটি নির্দিষ্ট কমিট পরীক্ষা করার জন্য যেখানে আপনি জানেন যে আপনি নির্দিষ্ট কিছু কাজ যোগ করেছেন, আপনি প্রথমে সেই কমিট সনাক্ত করতে git log কমান্ডটি চালাতে পারেন:
$ git log
commit 734713bc047d87bf7eac9674765ae793478c50d3
Author: Scott Chacon <schacon@gmail.com>
Date: Fri Jan 2 18:32:33 2009 -0800
Fix refs handling, add gc auto, update tests
commit d921970aadf03b3cf0e71becdaab3147ba71cdef
Merge: 1c002dd... 35cfb2b...
Author: Scott Chacon <schacon@gmail.com>
Date: Thu Dec 11 15:08:43 2008 -0800
Merge commit 'phedders/rdocs'
commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
Author: Scott Chacon <schacon@gmail.com>
Date: Thu Dec 11 14:58:32 2008 -0800
Add some blame and merge stuff
এই ক্ষেত্রে, মনে করুন যে আপনি হ্যাশ 1c002dd দিয়ে শুরু হওয়া কমিট-টি সম্পর্কে জানতে আগ্রহী। আপনি git show এর নিম্নলিখিত যেকোন একটি কমান্ডের মাধ্যমে সেই কমিট-টি পরিদর্শন করতে পারেন ( ধরে নেয়া হয় , সংক্ষিপ্ততর সংস্করণ গুলো স্পষ্টতর):
$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b
$ git show 1c002dd4b536e7479f
$ git show 1c002d
গিট আপনার SHA-1 মানগুলির জন্য একটি সংক্ষিপ্ত, ইউনিক সারসংক্ষেপ বের করতে পারে। আপনি যদি –abbrev-commit , git log কমান্ডে পাস করেন, আউটপুটগুলি সংক্ষিপ্ততর হলেও সেগুলো হবে ইউনিক ; এটি সাধারণত সাতটি অক্ষর ব্যবহার করে তবে SHA-1 কে স্পষ্ট রাখার জন্য প্রয়োজনে সেগুলিকে দীর্ঘায়িত করতে পারে :
$ git log --abbrev-commit --pretty=oneline
ca82a6d Change the version number
085bb3b Remove unnecessary test code
a11bef0 Initial commit
সাধারণত, একটি প্রজেক্ট-এর মধ্যে ইউনিক হওয়ার জন্য আট থেকে দশটি অক্ষরই যথেষ্ট। উদাহরণস্বরূপ, ফেব্রুয়ারী 2019 পর্যন্ত, Linux কার্নেল ( যা মোটামুটি একটি বড় প্রজেক্ট ) এর অবজেক্ট ডাটাবেসে 875,000 এর বেশি কমিট এবং প্রায় 7 মিলিয়ন অবজেক্ট রয়েছে, যেখানে এমন কোন দুটি অবজেক্ট পাওয়া যাবে না যাদের SHA-1গুলি প্রথম 12টি অক্ষরে অভিন্ন।
নোট
SHA-1 সম্পর্কে একটি সংক্ষিপ্ত নোট
র্যান্ডম ঘটনার দ্বারা, অনেক লোক এক পর্যায়ে উদ্বিগ্ন হয়ে পড়ে যে, যখন তাদের রিপোজিটরিতে দুটি অবজেক্ট থাকবে যারা একই SHA-1 ভ্যালুতে হ্যাশ করবে। তখন কি করতে হবে ?
আপনি যদি এমন একটি অবজেক্ট এ কমিট করে থাকেন যা আপনার রিপোজিটরিতে আগের ভিন্ন অবজেক্টের মতো একই SHA-1 ভ্যালুতে হ্যাশ করে, গিট আপনার গিট ডাটাবেসে ইতিমধ্যেই পূর্ববর্তী অবজেক্টটি দেখতে পাবে, ধরে নিন এটি ইতিমধ্যেই লেখা ছিল এবং কেবল এটি পুনরায় ব্যবহার করুন। আপনি যদি কোনও সময়ে সেই অবজেক্টটি আবার পরীক্ষা করার চেষ্টা করেন, তাহলে আপনি সর্বদা প্রথম অবজেক্টটির ডেটা পাবেন।
যাইহোক, আপনার সচেতন হওয়া উচিত যে এই দৃশ্যটি কতটা হাস্যকরভাবে অসম্ভাব্য। SHA-1 ডাইজেস্ট হল 20 বাইট বা 160 বিট। একটি একক সংঘর্ষের ( collision ) 50% সম্ভাবনা নিশ্চিত করতে এলোমেলোভাবে হ্যাশ করা বস্তুর সংখ্যা প্রায় 280 ( সংঘর্ষের সম্ভাবনা নির্ধারণের সূত্র হল p = ( n ( n-1 )/2 ) * ( 1/2^160 ) )। 280 হল 1.2 x 1024 বা 1 মিলিয়ন বিলিয়ন বিলিয়ন। এটি পৃথিবীতে থাকা বালির দানার সংখ্যার 1,200 গুণ।
একটি SHA-1 সংঘর্ষ পেতে কী লাগবে সে সম্পর্কে আপনাকে ধারণা দেওয়ার জন্য এখানে একটি উদাহরণ দেওয়া হল। যদি পৃথিবীর সমস্ত 6.5 বিলিয়ন মানুষ প্রোগ্রামিং করত এবং প্রতি সেকেন্ডে প্রত্যেকে একটি কোড তৈরি করত যা পুরো লিনাক্স কার্নেল ইতিহাসের ( 6.5 মিলিয়ন গিট অবজেক্ট ) সমতুল্য এবং এটিকে একটি বিশাল গিট রিপোজিটরিতে পুশ করত, তবে এটি প্রায় 2 বছর সময় নেবে, যতক্ষণ না সেই রিপোজিটরিতে একটি একক SHA-1 অবজেক্টের সংঘর্ষের 50% সম্ভাবনা থাকার জন্য পর্যাপ্ত অবজেক্ট রয়েছে। এইভাবে, আপনার প্রোগ্রামিং দলের প্রত্যেক সদস্যকে একই রাতে অসম্পর্কিত ঘটনায় নেকড়েদের দ্বারা আক্রান্ত ও নিহত হওয়ার সম্ভাবনার চেয়ে একটি একক SHA-1 সংঘর্ষের সম্ভাবনা কম।
আপনি যদি এতে কয়েক হাজার ডলার মূল্যের কম্পিউটিং শক্তি উৎসর্গ করেন, তাহলে একই হ্যাশ দিয়ে দুটি ফাইল সংশ্লেষিত করা সম্ভব, যেমনটি 2017 সালের ফেব্রুয়ারিতে https://shattered.io/-এ প্রমাণিত হয়েছে। গিট SHA256 ব্যবহার করে ডিফল্ট হ্যাশিং অ্যালগরিদমের মাধ্যমে এগিয়ে যাচ্ছে, যা সংঘর্ষের আক্রমণ থেকে রক্ষা পাওয়ার ক্ষেত্রে অনেক বেশি স্থিতিস্থাপক, এবং এই আক্রমণ প্রশমিত করতে সহায়তা করার জন্য কোড রয়েছে ( যদিও এটি সম্পূর্ণরূপে নির্মূল করতে পারে না )।
ব্রাঞ্চের রেফারেন্স
একটি নির্দিষ্ট কমিট উল্লেখ করার একটি সহজ উপায় হল যদি এটি একটি ব্রাঞ্চের শীর্ষে কমিট হয়; সেই ক্ষেত্রে, আপনি যে কোনও গিট কমান্ডে ব্রাঞ্চের নামটি ব্যবহার করতে পারেন যা একটি কমিটের রেফারেন্স আশা করে। উদাহরণস্বরূপ, যদি আপনি একটি ব্রাঞ্চে শেষ কমিট অবজেক্টটি পরীক্ষা করতে চান তবে নিম্নলিখিত কমান্ডগুলোই সমতুল্য, ধরে নেই যে topic1 ব্রাঞ্চটি ca82a6d… কমিটটিকে নির্দেশ করছে।
$ git show ca82a6dff817ec66f44342007202690a93763949
$ git show topic1
আপনি যদি দেখতে চান যে কোন নির্দিষ্ট SHA-1 টি, একটি ব্রাঞ্চ নির্দেশ করে, অথবা আপনি যদি দেখতে চান যে এই উদাহরণগুলির মধ্যে কোনটিতে SHA-1 এর পরিপ্রেক্ষিতে কী ফুটে উঠেছে, আপনি rev-parse নামক একটি গিট প্লাম্বিং টুল ব্যবহার করতে পারেন। গিট প্লাম্বিং টুল সম্পর্কে আরও তথ্যের জন্য আপনি গিট ইন্টারনাল দেখতে পারেন; মূলত, নিম্ন-স্তরের ক্রিয়াকলাপের জন্য rev-parse কমান্ডটি বিদ্যমান এবং এটি প্রতিদিনের ক্রিয়াকলাপে ব্যবহার করার জন্য ডিজাইন করা হয়নি। যাইহোক, কখনও কখনও এটি সহায়ক হতে পারে যখন আপনি সত্যিই কী ঘটছে তা দেখতে চাইবেন। এখানে আপনি আপনার ব্রাঞ্চে rev-parse চালাতে পারেন।
RefLog সংক্ষিপ্ত নাম
আপনি কাজ করার সময় ব্যাকগ্রাউন্ডে গিট যে কাজগুলি করে তার মধ্যে একটি হল “reflog” রাখা — এটি আপনার HEAD এবং ব্রাঞ্চের রেফারেন্সগুলো গত কয়েক মাস ধরে কোথায় ছিল তার একটি লগ ।
আপনি git reflog ব্যবহার করে আপনার reflog দেখতে পারেন:
$ git reflog
734713b HEAD@{0}: commit: Fix refs handling, add gc auto, update tests
d921970 HEAD@{1}: merge phedders/rdocs: Merge made by the 'recursive' strategy.
1c002dd HEAD@{2}: commit: Add some blame and merge stuff
1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
95df984 HEAD@{4}: commit: # This is a combination of two commits.
1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
$ git show HEAD@{5}
নির্দিষ্ট কিছু সময় পূর্বে একটি ব্রাঞ্চ কোথায় ছিল তা দেখতে আপনি এই সিনট্যাক্সটি ব্যবহার করতে পারেন। উদাহরণস্বরূপ, গতকাল আপনার master ব্রাঞ্চ কোথায় ছিল তা দেখতে, আপনি টাইপ করতে পারেন:
$ git show master@{yesterday}
এটি আপনাকে দেখাবে যে গতকাল আপনার master ব্রাঞ্চের টিপ কোথায় ছিল। এই কৌশলটি শুধুমাত্র সেই ডেটার জন্য কাজ করে যা এখনও আপনার reflog-এ আছে, তাই আপনি কয়েক মাসের বেশি পুরানো কমিট দেখতে এটি ব্যবহার করতে পারবেন না।
git log আউটপুটের মতো ফর্ম্যাট করা reflog তথ্য দেখতে, আপনি git reflog -g চালাতে পারেন:
$ git log -g master
commit 734713bc047d87bf7eac9674765ae793478c50d3
Reflog: master@{0} (Scott Chacon <schacon@gmail.com>)
Reflog message: commit: Fix refs handling, add gc auto, update tests
Author: Scott Chacon <schacon@gmail.com>
Date: Fri Jan 2 18:32:33 2009 -0800
Fix refs handling, add gc auto, update tests
commit d921970aadf03b3cf0e71becdaab3147ba71cdef
Reflog: master@{1} (Scott Chacon <schacon@gmail.com>)
Reflog message: merge phedders/rdocs: Merge made by recursive.
Author: Scott Chacon <schacon@gmail.com>
Date: Thu Dec 11 15:08:43 2008 -0800
Merge commit 'phedders/rdocs'
এটা মনে রাখা গুরুত্বপূর্ণ যে reflog তথ্য শুধুমাত্র লোকাল — এটি শুধুমাত্র আপনি আপনার রিপোজিটরিতে যা করেছেন তার একটি লগ। রেফারেন্সগুলি অন্য কারোর রিপোজিটরির অনুলিপিতে একই রকম হবে না; এছাড়াও, আপনি প্রাথমিকভাবে একটি রিপোজিটরি ক্লোন করার ঠিক পরে, আপনার কাছে একটি ফাঁকা reflog থাকবে, কারণ আপনার রিপোজিটরিতে এখনও কোনো কার্যকলাপ ঘটেনি। git show HEAD@{2.months.ago} কমান্ডটি চালালে এটি আপনাকে ম্যাচিং কমিট দেখাবে শুধুমাত্র যদি আপনি কমপক্ষে দুই মাস আগে প্রজেক্টটি ক্লোন করেন — যদি আপনি এর চেয়ে সম্প্রতি এটি ক্লোন করেন তবে আপনি শুধুমাত্র আপনার প্রথম লোকাল কমিট দেখতে পাবেন।
টিপ
reflogকে শেল ইতিহাসের গিটের সংস্করণ হিসাবে ভাবুন
আপনার যদি ইউনিক্স বা লিনাক্স ব্যাকগ্রাউন্ড থাকে, তাহলে আপনি রিফ্লগকে শেল ইতিহাসের গিট-এর সংস্করণ হিসাবে ভাবতে পারেন, এটি জোর দেয় যে, যা আছে তা শুধুমাত্র আপনার এবং আপনার “সেশন” এর জন্য স্পষ্টভাবে প্রাসঙ্গিক, এবং একই মেশিনে কাজ করতে পারে এমন অন্য কারো সাথে এর কোনো সম্পর্ক নেই।
নোট
PowerShell এ ব্র্যাকেট এড়িয়ে চলুন PowerShell ব্যবহার করার সময়, { এবং } বন্ধনীগুলি বিশেষ অক্ষরের মতো এবং অবশ্যই এদের এড়িয়ে চলা উচিত৷ আপনি একটি ব্যাকটিক ` দিয়ে তাদের এড়িয়ে যেতে পারেন বা দুটি উদ্ধৃতি চিহ্ন “” এর মধ্যে কমিট রেফারেন্স রাখতে পারেন: $ git show HEAD@{0} # এটি কাজ করবে না $ git show HEAD@`{0`} # ঠিকাছে $ git show “HEAD@{0}” # ঠিকাছে |
পূর্বপুরুষের ( Ancestry ) রেফারেন্স
একটি কমিট নির্দিষ্ট করার অন্য প্রধান উপায় হল তার পূর্বপুরুষের মাধ্যমে। আপনি যদি একটি রেফারেন্সের শেষে একটি ^ ( ক্যারেট ) রাখেন, গিট এটিকে সেই কমিটের প্যারেন্ট হিসেবে বুঝে নেয়। ধরুন আপনি আপনার প্রজেক্টের ইতিহাস দেখতে চান:
$ git log --pretty=format:'%h %s' --graph
* 734713b Fix refs handling, add gc auto, update tests
* d921970 Merge commit 'phedders/rdocs'
|\
| * 35cfb2b Some rdoc changes
* | 1c002dd Add some blame and merge stuff
|/
* 1c36188 Ignore *.gem
* 9b29157 Add open3_detach to gemspec file list
তারপর, আপনি HEAD^ নির্দিষ্ট করে পূর্ববর্তী কমিট দেখতে পারেন, যার অর্থ “HEAD এর প্যারেন্ট”।
$ git show HEAD^
commit d921970aadf03b3cf0e71becdaab3147ba71cdef
Merge: 1c002dd... 35cfb2b...
Author: Scott Chacon <schacon@gmail.com>
Date: Thu Dec 11 15:08:43 2008 -0800
Merge commit 'phedders/rdocs'
নোট
উইন্ডোজ অপারেটিং সিস্টেম এ ক্যারেট ( ^ ) চিহ্ন এড়িয়ে চলা
উইন্ডোজ-এ cmd.exe, ^ একটি বিশেষ অক্ষর এবং এটিকে ভিন্নভাবে বিবেচনা করা হয়। আপনি হয় এটি দ্বিগুণ করতে পারেন বা দুটি উদ্ধৃতি চিহ্নের মধ্যে কমিট রেফারেন্স রাখতে পারেন:
$ git show HEAD^ # উইন্ডোজে কাজ করবে না
$ git show HEAD^^ # ঠিক আছে
$ git show “HEAD^” # ঠিক আছে
$ git show d921970^
commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
Author: Scott Chacon <schacon@gmail.com>
Date: Thu Dec 11 14:58:32 2008 -0800
Add some blame and merge stuff
$ git show d921970^2
commit 35cfb2b795a55793d7cc56a6cc2060b4bb732548
Author: Paul Hedderly <paul+git@mjr.org>
Date: Wed Dec 10 22:22:03 2008 +0000
Some rdoc changes
অন্যান্য প্রধান পূর্বপুরুষ স্পেসিফিকেশন হল ~ ( টিল্ড /tilde )। এটি প্রথম প্যারেন্টকেও বোঝায়, তাই HEAD~ এবং HEAD^ সমতুল্য৷ আপনি যখন একটি সংখ্যা নির্দিষ্ট করেন তখন পার্থক্যটি স্পষ্ট হয়ে ওঠে। HEAD~2 মানে “প্রথম প্যারেন্টের প্রথম প্যারেন্ট” বা “গ্র্যান্ডপ্যারেন্ট” —যতবার আপনি একটি সংখ্যা নির্দিষ্ট করে দেন ততবার এটি প্রথম প্যারেন্টকে অতিক্রম করে। উদাহরণস্বরূপ, পূর্বে তালিকাভুক্ত ইতিহাসে, HEAD~3 হবে:
$ git show HEAD~3
commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
Author: Tom Preston-Werner <tom@mojombo.com>
Date: Fri Nov 7 13:47:59 2008 -0500
Ignore *.gem
এটিকে HEAD~~~ ও লেখা যেতে পারে, যা আবার প্রথম প্যারেন্টের প্রথম প্যারেন্টের প্রথম প্যারেন্ট:
$ git show HEAD~~~
commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
Author: Tom Preston-Werner <tom@mojombo.com>
Date: Fri Nov 7 13:47:59 2008 -0500
Ignore *.gem
আপনি এই সিনট্যাক্সগুলিকেও একসাথে করতে পারেন — আপনি HEAD~3^2 ব্যবহার করে পূর্ববর্তী রেফারেন্সের দ্বিতীয় প্যারেন্ট পেতে পারেন ( অনুমান করে নেই যে ,এটি একটি মার্জ কমিট ছিল)।
কমিট রেঞ্জ
এখন যেহেতু আপনি স্বতন্ত্র কমিট নির্দিষ্ট করতে পারেন, আসুন দেখি কিভাবে কমিটের রেঞ্জ নির্দিষ্ট করতে হয়। এটি আপনার ব্রাঞ্চ পরিচালনার জন্য বিশেষভাবে উপযোগী — যদি আপনার অনেকগুলি ব্রাঞ্চ থাকে, তাহলে আপনি প্রশ্নগুলির উত্তর দিতে রেঞ্জ স্পেসিফিকেশন ব্যবহার করতে পারেন যেমন, “এই শাখায় কী কাজ আছে যেটা আমি এখনও আমার প্রধান শাখায় মার্জ করিনি?”
ডাবল ডট
সবচেয়ে সাধারণ রেঞ্জ স্পেসিফিকেশন হল ডাবল-ডট সিনট্যাক্স। এটি মূলত গিটকে এমন একটি কমিটের পরিসর সমাধান করতে বলে যাতে একটি কমিট থেকে পৌঁছানো যায় কিন্তু অন্য কমিট থেকে পৌঁছানো যায় না। মনে করুন যে, আপনার কাছে একটি কমিট ইতিহাস রয়েছে যা পরিসীমা নির্বাচনের জন্য উদাহরণ ইতিহাসের ( example history ) মতো দেখাচ্ছে।
মনে করুন যে, আপনি দেখতে চান আপনার experiment ব্রাঞ্চে কী আছে যা এখনও আপনার master ব্রাঞ্চে মার্জ করা হয়নি। master..experiment – এই কমান্ড এর সাহায্যে , আপনি গিটকে শুধুমাত্র সেই কমিটগুলির একটি লগ দেখানোর জন্য বলতে পারেন – যার মানে ” experiment শাখা থেকে পৌঁছানো যায় এমন সমস্ত কমিট যা master শাখা থেকে পৌঁছানো যায় না।” এই উদাহরণগুলির সংক্ষিপ্ততা এবং স্বচ্ছতার জন্য, ডায়াগ্রাম থেকে কমিট অবজেক্টের অক্ষরগুলি প্রকৃত লগ আউটপুটের জায়গায় ব্যবহার করা হয় যাতে তারা প্রদর্শন করবে:
$ git log master..experiment
D
C
অন্যদিকে, আপনি যদি উল্টোটা দেখতে চান — সকল কমিট যা master এর মধ্যে আছে কিন্তু experiment ব্রাঞ্চে নেই — সেক্ষেত্রে কমান্ডে , আপনি ব্রাঞ্চের নামগুলি উল্টাতে পারেন। experiment..master আপনাকে master ব্রাঞ্চের সবকিছু দেখায় যা experiment থেকে পৌঁছানো যায় না:
$ git log experiment..master
F
E
আপনি যদি experiment ব্রাঞ্চটিকে আপ টু ডেট রাখতে চান এবং আপনি যা মার্জ করতে চলেছেন তার পূর্বরূপ দেখতে চাইলে এটি কার্যকর। এই সিনট্যাক্সের আরেকটি ব্যবহার হল আপনি রিমোট ব্রাঞ্চে কী পুশ দিতে চলেছেন তা দেখা:
$ git log origin/master..HEAD
এই কমান্ডটি আপনাকে আপনার বর্তমান ব্রাঞ্চের এমন কোনো কমিট দেখায় যা আপনার origin রিমোটের master ব্রাঞ্চে নেই। আপনি যদি একটি git push কমান্ড চালান এবং আপনার বর্তমান ব্রাঞ্চ যদি origin/master কে ট্র্যাক করে, git log origin/master..HEAD কমান্ড দ্বারা তালিকাভুক্ত কমিটগুলি সার্ভারে স্থানান্তরিত হবে৷ গিটকে HEAD ধরে নিতে , আপনি সিনট্যাক্সের একপাশ ছেড়েও যেতে পারেন । উদাহরণস্বরূপ, আপনি git log origin/master.. টাইপ করে আগের উদাহরণের মতো একই ফলাফল পেতে পারেন । যদি একটি দিক অনুপস্থিত থাকে তাহলে গিট HEAD কে প্রতিস্থাপন করে দেয় ।
একাধিক পয়েন্ট
ডবল-ডট সিনট্যাক্স একটি শর্টহ্যান্ড হিসাবে উপযোগী, কিন্তু সম্ভবত আপনি আপনার রিভিশন নির্দেশ করতে দুটির বেশি ব্রাঞ্চ নির্দিষ্ট করতে চান, যেমন আপনি যদি দেখতে চান : বর্তমানে যে ব্রাঞ্চে আছেন সেই ব্রাঞ্চে নেই এমন কয়েকটি ব্রাঞ্চের মধ্যে কোন কমিটটি রয়েছে। গিট আপনাকে ^ বা –not ব্যবহার করে এটি করার অনুমতি দেয়। ^ বা –not এমন কোনো রেফারেন্সের আগে ব্যবহার করতে হবে যা থেকে আপনি পৌঁছানোযোগ্য কমিট দেখতে চান না। সুতরাং, নিম্নলিখিত তিনটি কমান্ড সমতুল্য:
$ git log refA..refB
$ git log ^refA refB
$ git log refB --not refA
এটি চমৎকার কারণ এই সিনট্যাক্সের সাহায্যে আপনি আপনার কমান্ডে দুটির বেশি রেফারেন্স নির্দিষ্ট করতে পারেন, যা আপনি ডাবল-ডট সিনট্যাক্সের সাথে করতে পারবেন না। উদাহরণস্বরূপ, আপনি যদি refA বা refB থেকে পৌঁছানো যায় তবে refC থেকে নয় এমন সমস্ত কমিট দেখতে চান, আপনি নিচের কমান্ডগুলোর যেকোন একটি ব্যবহার করতে পারেন:
$ git log refA refB ^refC
$ git log refA refB --not refC
এটি একটি খুব শক্তিশালী রিভিশন ক্যোয়ারী সিস্টেম তৈরি করে যা আপনাকে আপনার ব্রাঞ্চে কী আছে তা বের করতে সাহায্য করবে।
ট্রিপল ডট
শেষ বড় রেঞ্জ-সিলেকশান সিনট্যাক্স হল ট্রিপল-ডট সিনট্যাক্স, যা সমস্ত কমিট নির্দিষ্ট করে যা দুটি রেফারেন্সের যে কোনো একটির দ্বারা পৌঁছানো যায় কিন্তু উভয়ের দ্বারা নয়। পরিসর নির্বাচনের জন্য উদাহরণ ইতিহাসে “উদাহরণ কমিট ইতিহাস” এর দিকে ফিরে তাকান। আপনি যদি master বা experiment ব্রাঞ্চে কী আছে তা দেখতে চান তবে কোনো কমন রেফারেন্স নয়, আপনি নিচের কমান্ড চালাতে পারেন:
$ git log master...experiment
F
E
D
C
আবার, এটি আপনাকে সাধারন log আউটপুট দেয় কিন্তু আপনাকে শুধুমাত্র সেই চারটি কমিটের জন্য কমিট তথ্য দেখায়, যা প্রথাগত কমিট ডেট অর্ডারে উপস্থিত হয়।
এই ক্ষেত্রে log কমান্ডের সাথে ব্যবহার করার জন্য একটি সাধারণ সুইচ হল –left-right, যা আপনাকে দেখায় যে প্রতিটি কমিট রেঞ্জের কোন দিকে রয়েছে৷ এটি আউটপুটটিকে আরও উপযোগী করে তুলতে সাহায্য করে:
$ git log --left-right master...experiment
< F
< E
> D
> C
এই টুলগুলির সাহায্যে, আপনি আরও সহজে গিটকে জানাতে পারেন যে আপনি কী কী কমিট পরিদর্শন করতে চান।
