সংশোধন সংখ্যাটির জন্য গিট সমতুল্য কী?


244

আমরা কাজে এসভিএন ব্যবহার করি তবে আমার ব্যক্তিগত প্রকল্পগুলির জন্য আমি গিট ব্যবহার করার সিদ্ধান্ত নিয়েছি। তাই আমি গতকাল গিট ইনস্টল করেছি এবং আমি আশ্চর্য হয়েছি যে গিতের সংশোধন সংখ্যা সমান ।

ধরা যাক আমরা 3.0.০.৮ সংস্করণে কাজ করি এবং প্রতিটি বাগ ফিক্সের নিজস্ব পুনর্বিবেচনা নম্বর রয়েছে আমরা যখন এই বাগ ফিক্সটি নিয়ে কথা বলি তখন আমরা ব্যবহার করতে পারি। সুতরাং আমি যদি গিট-তে কোডটি ৩.০.৮ এ ট্যাগ করি তবে আমি কোন পুনর্বিবেচনা নম্বর বা আরও কিছু বিস্তারিত ধরণের সনাক্তকরণ হিসাবে ব্যবহার করতে পারি? আমি হ্যাশটি মানুষের পক্ষে তেমন ব্যবহারকারীর মতো নয় find



সম্ভাব্য সমাধানগুলির একটির জন্য একটি নিবন্ধ আছে । এটি কিছুটা ভারী লাগলেও "গিট লগ" আউটপুটে একত্রিত হতে পারে এবং "গিট পুশ / টান / আনতে" ব্যতীত অতিরিক্ত কোনও কমান্ডের প্রয়োজন হয় না।
দিমিত্রি পাভলঙ্কো

দুর্ভাগ্যক্রমে @ দিমিত্রিপাভেলঙ্কোর লিঙ্কযুক্ত নিবন্ধটি একটি মৃত ডোমেনে রয়েছে: gitsvn.x10.mx। বিষয়টির কোনও ইঙ্গিত না দিয়ে, এটি অন্য কোথাও খুঁজে পাওয়া কারও পক্ষে কঠিন হবে।
মাইকেল ডোনোহু

নোট: আর Git সঙ্গে প্রয়োজন abbrev বর্ণনা: দেখুন stackoverflow.com/a/41308073/6309
VonC

1
না, লরেন্স গনসালভস, এটি "গিট কমিট গণনা কীভাবে পাবেন?" এর সদৃশ নয়? - এটি সংস্করণ সংখ্যা সম্পর্কে, এবং
কমিটের

উত্তর:


149

আপনার জন্য ভাল বা খারাপ সংবাদ, হ্যাশটি হ'ল সংশোধন নম্বর। এসভিএন থেকে গিটে স্যুইচ করার সময় আমারও এ নিয়ে সমস্যা হয়েছিল।

নির্দিষ্ট সংস্করণটির জন্য "রিলিজ" হিসাবে একটি নির্দিষ্ট সংশোধন ট্যাগ করার জন্য আপনি গিটের মধ্যে "ট্যাগিং" ব্যবহার করতে পারেন, যাতে এটি পুনর্বিবেচনার উল্লেখ করা সহজ করে তোলে। এই ব্লগ পোস্টটি দেখুন

মূল বিষয়টি বুঝতে হবে যে গিটটিতে পুনর্বিবেচনা সংখ্যা থাকতে পারে না - বিকেন্দ্রীভূত প্রকৃতি সম্পর্কে চিন্তা করুন। যদি ব্যবহারকারী ও ও বি উভয়ই তাদের স্থানীয় ভাণ্ডারগুলিতে প্রতিশ্রুতিবদ্ধ হয় তবে কীভাবে গিট যুক্তিসঙ্গতভাবে একটি অনুক্রমিক সংশোধন নম্বর নির্ধারণ করতে পারে? একে অপরের পরিবর্তনগুলি ধাক্কা / টানানোর আগে A এর বি সম্পর্কে কোনও জ্ঞান নেই।

দেখার আরেকটি বিষয় হ'ল বাগ ফিক্স শাখাগুলির সরলিকৃত শাখা প্রশাখা:

একটি রিলিজ দিয়ে শুরু করুন: 3.0.8। তারপরে, মুক্তির পরে, এটি করুন:

git branch bugfixes308

এটি বাগফিক্সগুলির জন্য একটি শাখা তৈরি করবে। শাখা চেকআউট:

git checkout bugfixes308

এখন আপনি যে কোনও বাগফিক্স পরিবর্তন চান make

git commit -a

তাদের প্রতিশ্রুতিবদ্ধ এবং মাস্টার শাখায় ফিরে যেতে:

git checkout master

তারপরে অন্য শাখা থেকে এই পরিবর্তনগুলি টানুন:

git merge bugfixes308

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


11
আমি বুঝতে পেরেছি যে হ্যাশটি পুনর্বিবেচনার নম্বর তবে আমি আশা করি এটি ছিল না :-))) খুব সুন্দর ব্যাখ্যা দেওয়ার জন্য এবং এটি মোকাবেলায় এখনই পরামর্শের জন্য আপনাকে ধন্যবাদ thank
রাদেক

3
আপনাকে স্বাগতম. আমি প্রথমে এসভিএন থেকে এটি
তুললে

4
এছাড়াও, আমি এটি পোস্ট করার পরে বেশ কিছুক্ষণ হয়ে গেছে, তবে মনে রাখবেন যে আপনি "গিট চেকআউট-বি নিউ_ ব্র্যাঞ্চ_নাম" ও "লাইভ ব্রাঞ্চ ফু" করতে "ও গিট চেকআউট ফু" করতে পারেন one
মকদাদ

1
আমি কি সঠিক করেছি যে হ্যাশগুলি "সত্য" হ্যাশগুলি, এবং এমনকি দূরবর্তীভাবে ক্রমিক নয়? সুতরাং, গুরুত্বপূর্ণ বিষয়, যদি বাগ ডাটাবেসটি বলে fixed in 547cc3e..c4b2ebaএবং আপনার যদি অন্য কিছু সংশোধন হয়, তবে আপনার কোডটি ঠিক আছে কিনা তা আপনার ধারণা নেই ?! নিশ্চয় গিট-সেন্ট্রালের গিটগুলির কি এর সমাধান হতে পারে?!?!
অলি

3
এসভিএন-তে, যে কোনও বাগটি আর -৪২-এ স্থির করা হয়েছে তা আপনি আসলে শাখাগুলি ব্যবহার করার সাথে সাথে এটি আর -৩৩ এ স্থির হয়েছে কিনা তা আপনাকে জানায় না।
ম্যাথিউ ময়

186

আধুনিক গিট (আমার ক্ষেত্রে 1.8.3.4) এবং শাখাগুলি ব্যবহার না করে আপনি এটি করতে পারেন:

$ git rev-list --count HEAD
68

22
ব্যবহার বিবেচনা করুনgit rev-list --count --first-parent HEAD
ফ্লিম

8
এই তথ্যটি (68 নম্বর) দেওয়া, কোডটি পুনরায় অর্জনের জন্য সংশোধনটি নির্ধারণ করার কোনও উপায় আছে? ধরুন, "রিভিশন 68" একটি পরীক্ষার পরিবেশে প্রকাশিত হয়েছে, বিকাশ অব্যাহত রয়েছে এবং পরে কোনও বিকাশকারীকে উত্স নিয়ন্ত্রণ থেকে "পুনর্বিবেচনা 68" পুনরায় অর্জন করতে হবে। তিনি কীভাবে নির্দিষ্ট সংস্করণটিকে ক্লোন করতে লক্ষ্য করবেন? বা আমি গিট সম্পর্কে এমন কিছু মিস করছি যা এটি অপ্রয়োজনীয় করে তোলে?
ডেভিড

9
মনে রাখবেন যে এই সমাধানটি বিভিন্ন বিকাশকারীদের জন্য বিভিন্ন ফলাফল অর্জন করবে। এছাড়াও, "গণনা" থেকে প্রতিশ্রুতিতে পিছনের দিকে গণনা করা বিভিন্ন বিকাশকারীদের জন্য বিভিন্ন কমিট উপার্জন করতে পারে !! এটি গিটের বিতরণ প্রকৃতির কারণে এবং একই একই সময়ের মধ্যে বিভিন্ন সংগ্রহস্থলে ঘটতে থাকে git rev-list --count HEADতবে শেষ ধাক্কা এবং টান কখন তৈরি হয়েছিল তার উপর নির্ভর করে এটি গণনা করা যায় না ।
জেসন

2
@ জেসন, --first-parentআপনার উদ্বেগের সমাধান করার বিষয়ে ডেভিডের মন্তব্য কি? বিরল প্রান্তের ক্ষেত্রে একটি আপাত-সহজ সমাধানটি এড়াতে আমি ঘৃণা করব কারণ যদি একইরকম-সহজ কাজ বা আরও শক্তিশালী করার উপায় থাকে।
মার্কহু

4
@ মার্কহু, --first-parentসাহায্য করে। যতক্ষণ না কোনও রিবেসিং না করা হয় এবং একই শাখা সর্বদা প্রকাশের জন্য ব্যবহৃত হয় (এবং অবশ্যই এই প্রকাশের নম্বর গণনা করা হচ্ছে), আমি মনে করি এটি ব্যবহার করা যেতে পারে। যদিও, আমি এখনও অনিশ্চিত এটি সর্বদা স্বতন্ত্রভাবে মুক্তিটি যে প্রতিশ্রুতিবদ্ধ তা চিহ্নিত করবে। এখানে অনেক কিছুই ভুল হতে পারে ... তবে এই মুহুর্তে আমি এমন কোনও বিষয় ভাবতে পারি না যা অবশ্যই এটির জন্য ভেঙে পড়বে (আমার উপরের "যতক্ষণ" বিবৃতি দেওয়া হয়েছে)। git describeপদ্ধতি অন্য উত্তর উল্লেখিত যেতে উপায়। আপনি মানব পাঠযোগ্য কিছু চাইলে একটি ট্যাগ তৈরি করুন।
জেসন

104

git describeকমান্ড একটি সামান্য আরো পাঠযোগ্য নামের যে একটি নির্দিষ্ট কমিট বোঝায় সৃষ্টি করে। উদাহরণস্বরূপ, ডকুমেন্টেশন থেকে:

Git.git বর্তমান গাছের মতো কিছু দিয়ে আমি পেয়েছি:

[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721

উদাহরণস্বরূপ আমার "প্যারেন্ট" শাখার বর্তমান প্রধানটি v1.0.4 এর উপর ভিত্তি করে রয়েছে, তবে যেহেতু এটির উপরে কয়েকটি কমিট রয়েছে, বর্ণনাটি অতিরিক্ত কমিটের সংখ্যা ("14") যোগ করেছে এবং কমিটের সংক্ষিপ্ত সংখ্যার নাম যুক্ত করেছে নিজেই ("2414721") শেষে।

যতক্ষণ আপনি নির্দিষ্ট প্রকাশগুলি ট্যাগ করার জন্য সংজ্ঞাবদ্ধভাবে নামযুক্ত ট্যাগ ব্যবহার করেন, এটিকে মোটামুটি কোনও এসভিএন "রিভিশন নম্বর" এর সমতুল্য হিসাবে বিবেচনা করা যেতে পারে।


7
আমি কেবল উল্লেখ করতে চাই যে এটি কেবল তখনই কাজ করে যদি আপনার gitভান্ডারটিতে ইতিমধ্যে ট্যাগ থাকে; যদি এটি না ঘটে তবে আপনি "মারাত্মক: কোনও নাম খুঁজে পাওয়া যায়নি, কোনও কিছুই বর্ণনা করতে পারে না" এর সাথে গিটের ব্যর্থতার বর্ণনা পেতে পারে " - স্ট্যাক ওভারফ্লো ; এর অর্থ হ'ল আপনাকে নিজেরাই ট্যাগ সেট আপ করতে হবে।
sdaau

14
@ এসডাউ: আপনি যদি এটি কোনও স্ক্রিপ্ট বা অন্য কিছুতে git describeব্যবহার করে থাকেন এবং কখনও ব্যর্থ হতে না চান তবে git describe --alwaysবিকল্পটি ব্যবহার করুন ।
গ্রেগ হিউগিল

git describeউত্স আউটপুট ব্যবহার করা যেতে পারে কি কোনওভাবে, উত্স প্রতিশ্রুতি? ম্যানুয়ালি সংক্ষিপ্তভাবে লগতে কমিট করার অর্থ, আমি বলতে চাইছি।
Lii

@ লিঃ: "উত্স প্রতিশ্রুতি" বলতে কী বোঝ? নিকটতম ট্যাগ ( v1.0.4) এবং অতি সাম্প্রতিক কমিট আইডি ( 2414721) উভয়ই ইতিমধ্যে গিট বর্ণনার আউটপুটের অংশ।
গ্রেগ হিউগিল

@ গ্রেগ হিউগিল: হ্যাঁ, ধন্যবাদ, যখন আমি প্রশ্ন জিজ্ঞাসা করেছি তখন বুঝতে পারি না যে "সংক্ষিপ্ত অবজেক্টের নাম" একটি মান যা প্রতিশ্রুতি সনাক্ত করতে ব্যবহার করা যেতে পারে। উজ্জ্বল!
Lii

67

অন্যান্য পোস্টারগুলি সঠিক, কোনও "সংশোধন নম্বর" নেই।

আমি মনে করি সবচেয়ে ভাল উপায় "রিলিজ" এর জন্য ট্যাগ ব্যবহার করা!

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

"হেড" এর "বর্তমান সংশোধন" এটি ব্যবহার করে অনুকরণযুক্ত দেখান:

git rev-list HEAD | wc -l

তবে ক্লায়েন্ট যদি আমাকে বলেন যে "সংশোধন" 1302-তে একটি বাগ আছে?

এর জন্য আমি আমার। / .Gitconfig এর [ওরফে] বিভাগে নিম্নলিখিতগুলি যুক্ত করেছি:

show-rev-number = !sh -c 'git rev-list --reverse HEAD | nl | awk \"{ if(\\$1 == "$0") { print \\$2 }}\"'

ব্যবহার git show-rev-number 1302তারপর প্রিন্ট হবে হ্যাশ "সংস্করণ" জন্য :)

কিছুক্ষণ আগে আমি সেই "কৌশল" সম্পর্কে একটি ব্লগ পোস্ট তৈরি করেছি (জার্মান ভাষায়)


@ রাডেক - "কখনও কখনও 'কোড পরিবর্তন = কমিট' কিছু ঠিক করা" কী তা জানতে হবে - তারপরে git bisect(লিঙ্ক) হ'ল কে কখন দ্বারা পরিবর্তন হয়েছিল তা চিহ্নিত করার উপযুক্ত সরঞ্জাম।
মাইকেল 25

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

1
আমি আপনার সমাধান পছন্দ। দয়া করে লক্ষ্য করুন যে আপনি এটিকে সহজ করতে পারেন: show-rev-number =! Sh -c 'গিট রেভ-তালিকা - বিপরীত হেড | awk NR == $ 0 '
অ্যাভনার

@ ওনার আপনাকে ধন্যবাদ! আমি আমার জীবনে প্রচুর
অদ্ভুত

3
আমাকে ব্যবহার করতে হয়েছিলgit rev-list --reverse HEAD | awk "{ print NR }" | tail -n 1
গেরি

27

গিটের সাবভিশন হিসাবে সংশোধন সংখ্যাগুলির একই ধারণা নেই। পরিবর্তে প্রতিশ্রুতি দিয়ে তৈরি প্রতিটি প্রদত্ত স্ন্যাপশট একটি SHA1 চেকসাম দ্বারা ট্যাগ করা হয়। কেন? একটি বিতরণ সংস্করণ নিয়ন্ত্রণ সিস্টেমে চলমান রেভনো নিয়ে বেশ কয়েকটি সমস্যা রয়েছে:

প্রথমত, যেহেতু বিকাশ একেবারেই রৈখিক নয়, তাই সংখ্যার সংযুক্তি একটি সমস্যার সমাধান হিসাবে সমস্যা হিসাবে এটি একটি প্রোগ্রামার হিসাবে আপনার প্রয়োজন মেটাবে in কোনও সংখ্যা যুক্ত করে এটি সংশোধন করার চেষ্টা করা যখন সমস্যাটি আপনার প্রত্যাশা মতো আচরণ করে না তখন দ্রুত সমস্যা হতে পারে।

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

তৃতীয়ত, গিট-ইন, কিছুটা এখন অচল ওপেনসিএম সিস্টেম দ্বারা নেতৃত্ব দেওয়া, একটি প্রতিশ্রুতি (কমিট কী) এর পরিচয় তার নামের (এসএএএড আইডি) এর সমতুল্য । এই নামকরণ = পরিচয় ধারণাটি খুব শক্ত। আপনি যখন কোনও কমিটের নাম হাতে নিয়ে বসেন এটি কমিটকে অবিস্মরণীয় পদ্ধতিতে চিহ্নিত করে। এর ফলে আপনি কমান্ড দিয়ে দুর্নীতির জন্য আপনার সমস্ত প্রতিশ্রুতি প্রথম প্রারম্ভিকটিতে ফিরে যেতে পারবেনgit fsck

এখন থেকে যেহেতু আমাদের কাছে সংশোধনীগুলির একটি ডিএজি (নির্দেশিত অ্যাসাইক্লিক গ্রাফ) রয়েছে এবং এগুলি বর্তমান গাছ গঠন করে, তাই আপনার সমস্যা সমাধানের জন্য আমাদের কিছু সরঞ্জামের প্রয়োজন : আমরা কীভাবে বিভিন্ন সংস্করণকে বৈষম্য করব। প্রথমত, আপনি যদি 1516 বিডির প্রদত্ত উপসর্গটি বলে থাকেন তবে হ্যাশের কিছু অংশ বাদ দিতে পারেন, আপনার প্রতিশ্রুতি স্বতন্ত্রভাবে চিহ্নিত করে। তবে এটি বরং স্বীকৃত। পরিবর্তে, কৌশলটি হ'ল ট্যাগ এবং শাখা ব্যবহার করা। আপনি প্রদত্ত প্রতিশ্রুতি SHA1-id এর সাথে সংযুক্ত একটি "হলুদ স্টিক এটি নোট" এর মতো একটি ট্যাগ বা শাখা। ট্যাগগুলি হ'ল সংক্ষেপে বোঝানো হয় যেখানে একটি শাখা যখন চলবে তখন তার শিরোনামে নতুন কমিট করা হয়। কোনও ট্যাগ বা শাখার চারপাশে প্রতিশ্রুতিবদ্ধতার উল্লেখ করার উপায় রয়েছে, গিট-রেভ-পার্সের ম্যান পৃষ্ঠাটি দেখুন।

সাধারণত, আপনার যদি কোনও কোডের নির্দিষ্ট অংশে কাজ করা দরকার হয় তবে সেই টুকরাটির পরিবর্তন চলছে এবং সে হিসাবে কথার নামের সাথে একটি শাখা হওয়া উচিত। প্রচুর শাখা তৈরি করা (প্রতিটি প্রোগ্রামার প্রতি ২০-৩০ টি অপ্রত্যাশিত নয়, অন্যদের পক্ষে কাজ করার জন্য কিছু 4-5 প্রকাশিত হয়) কার্যকর গিটের কৌশল। প্রতিটি অংশের কাজটি তার নিজস্ব শাখা হিসাবে শুরু হওয়া উচিত এবং তারপরে এটি পরীক্ষিত হলে মেশানো উচিত। অপ্রকাশিত শাখাগুলি পুরোপুরি আবার লেখা যেতে পারে এবং ইতিহাস ধ্বংস করার এই অংশটি গিটারের শক্তি is

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


18

আপনি যদি আগ্রহী হন তবে আমি এখানে বিন্যাসের আওতায় গিট ইনফস থেকে স্বয়ংক্রিয়ভাবে সংস্করণ নম্বরগুলি পরিচালনা করেছিলাম

<major>.<minor>.<patch>-b<build>

যেখানে বিল্ডটি মোট কমিটের সংখ্যা number আপনি মধ্যে আকর্ষণীয় কোড দেখতে পাবেন Makefile। সংস্করণ সংখ্যার বিভিন্ন অংশ অ্যাক্সেস করার জন্য এখানে প্রাসঙ্গিক অংশটি দেওয়া হয়েছে:

LAST_TAG_COMMIT = $(shell git rev-list --tags --max-count=1)
LAST_TAG = $(shell git describe --tags $(LAST_TAG_COMMIT) )
TAG_PREFIX = "latex-tutorial-v"

VERSION  = $(shell head VERSION)
# OR try to guess directly from the last git tag
#VERSION    = $(shell  git describe --tags $(LAST_TAG_COMMIT) | sed "s/^$(TAG_PREFIX)//")
MAJOR      = $(shell echo $(VERSION) | sed "s/^\([0-9]*\).*/\1/")
MINOR      = $(shell echo $(VERSION) | sed "s/[0-9]*\.\([0-9]*\).*/\1/")
PATCH      = $(shell echo $(VERSION) | sed "s/[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/")
# total number of commits       
BUILD      = $(shell git log --oneline | wc -l | sed -e "s/[ \t]*//g")

#REVISION   = $(shell git rev-list $(LAST_TAG).. --count)
#ROOTDIR    = $(shell git rev-parse --show-toplevel)
NEXT_MAJOR_VERSION = $(shell expr $(MAJOR) + 1).0.0-b$(BUILD)
NEXT_MINOR_VERSION = $(MAJOR).$(shell expr $(MINOR) + 1).0-b$(BUILD)
NEXT_PATCH_VERSION = $(MAJOR).$(MINOR).$(shell expr $(PATCH) + 1)-b$(BUILD)

9

একটি বাশ ফাংশন:

git_rev ()
{
    d=`date +%Y%m%d`
    c=`git rev-list --full-history --all --abbrev-commit | wc -l | sed -e 's/^ *//'`
    h=`git rev-list --full-history --all --abbrev-commit | head -1`
    echo ${c}:${h}:${d}
}

ফলাফল কিছু

$ git_rev
2:0f8e14e:20130220

এটাই

commit_count:last_abbrev_commit:date_YYmmdd

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

8

কমিট এর SHA1 এ হ্যাশ একটি Subversion সংস্করণ নম্বরে সমতুল্য।


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

1
@ কোডইনচাওস: আমি জানি আপনি কী পাচ্ছেন, তবে হ্যাশ কোডের প্রথম 6 বা 8 টি অক্ষর দিয়ে সাধারণত গিট কমিটগুলি বোঝানো সম্ভব।
ক্রিস পিটম্যান

5
@ রাডেক: এগুলি অনন্যরূপে গ্যারান্টিযুক্ত নয় (যদিও আপনি যদি সংঘর্ষের সন্ধান পান তবে আপনি কিছুটা নামী কীর্তি অর্জন করতে পারেন)।
স্লেটারিবার্টফাস্ট

8
মতে @Radek en.wikipedia.org/wiki/Collision_attack , হ্যাশ 4 অক্ষর সঙ্গে আপনি একটি 16bit আইডি থাকা, যার মানে সঙ্গে 256 (= 2 ^ (16/2) ) করে একটি রেপো তে নেই 50 দু'টি কমিটের একই চার-চর-উপসর্গ হওয়ার% সম্ভাবনা রয়েছে (এবং 5৫৫3636 কমিটের সাথে এটি নিশ্চিত হওয়া যায়, তারপরে ৪-চর আইডির পরিসর শেষ হয়ে যায়)। আপনি যখন একটি চর যোগ করেন, আপনার কাছে 20 বিট আইডি থাকে, যার অর্থ 50% প্রান্তিক 1024 টি কমিট হয়। তবে এটি যেহেতু একটি পরিসংখ্যানগত প্যারামিটার, তাই এর আগে এমন ধরণের সংঘর্ষ ঘটবে না এমন কিছুই গ্যারান্টি দেয় না।
Rudi

2
যেহেতু হ্যাশ সামগ্রীগুলির উপর ভিত্তি করে তৈরি করা হয়েছে, এখনও দুটি সম্ভাবনার একই হ্যাশ উপসর্গ আছে কিনা তা নিশ্চিত হওয়ার সম্ভাবনা রয়েছে। 65536 এ প্রতিশ্রুতি দেয় এটি খুব সম্ভবত যে দুজনের একই চার-চর-উপসর্গ থাকবে তবে এটি এখনও নিশ্চিত নয়। একটি সরাইয়া হিসাবে, পূর্ণ হ্যাশ এখনো একটি সংঘর্ষের মধ্যে পড়ে না, কিন্তু Git তে এটি :) কাজ করছে stackoverflow.com/questions/3475648/...
goodeye

6

অন্যের সমাধানের ভিত্তিতে আমি আমার মেকফিলটিতে এটি করেছি did দ্রষ্টব্য এটি কেবল আপনার কোডকে একটি পুনর্বিবেচনা নম্বর দেয় না, এটি হ্যাশকে সংযোজন করে যা আপনাকে পুনরায় প্রকাশের সুযোগ দেয়।

# Set the source control revision similar to subversion to use in 'c'
# files as a define.
# You must build in the master branch otherwise the build branch will
# be prepended to the revision and/or "dirty" appended. This is to
# clearly ID developer builds.
REPO_REVISION_:=$(shell git rev-list HEAD --count)
BUILD_BRANCH:=$(shell git rev-parse --abbrev-ref HEAD)
BUILD_REV_ID:=$(shell git rev-parse HEAD)
BUILD_REV_ID_SHORT:=$(shell git describe --long --tags --dirty --always)
ifeq ($(BUILD_BRANCH), master)
REPO_REVISION:=$(REPO_REVISION_)_g$(BUILD_REV_ID_SHORT)
else
REPO_REVISION:=$(BUILD_BRANCH)_$(REPO_REVISION_)_r$(BUILD_REV_ID_SHORT)
endif
export REPO_REVISION
export BUILD_BRANCH
export BUILD_REV_ID

3
git-describeত্রুটিগুলি এড়ানোর জন্য এটি ব্যবহার করার নিরাপদতম উপায়টি মনে হয় , git describe --always --dirty --long --tagsযা আমি ভাবতে পারি সব ক্ষেত্রেই কাজ করে।
মার্কহু

5

গিট হ্যাশটি বিল্ড নম্বর হিসাবে ব্যবহার করতে সমস্যা হ'ল এটি একঘেয়েভাবে বাড়ছে না। ওএসজিআই বিল্ড নম্বরটির জন্য টাইম স্ট্যাম্প ব্যবহার করার পরামর্শ দেয়। দেখে মনে হচ্ছে শাখায় করা কমিটের সংখ্যাটি সাবস্ট্রেশন বা পারফোর পরিবর্তন নম্বরের জায়গায় ব্যবহার করা যেতে পারে।


5

আমি গিট থেকে সংস্করণ তথ্য পুনরুদ্ধার এবং ট্যাগিংকে সহজ করার জন্য কিছু পাওয়ারশেল ইউটিলিটি লিখেছি

ফাংশন: গেট-লাস্ট ভার্সন, গেট-রিভিশন, গেট-নেক্সটমাজারভিশন, গেট-নেক্সটমাইনর ভার্সন, ট্যাগনেক্সটমাজার ভার্সন, ট্যাগনেক্সটমাইনর সংস্করণ:

# Returns the last version by analysing existing tags,
# assumes an initial tag is present, and
# assumes tags are named v{major}.{minor}.[{revision}]
#
function Get-LastVersion(){
  $lastTagCommit = git rev-list --tags --max-count=1
  $lastTag = git describe --tags $lastTagCommit
  $tagPrefix = "v"
  $versionString = $lastTag -replace "$tagPrefix", ""
  Write-Host -NoNewline "last tagged commit "
  Write-Host -NoNewline -ForegroundColor "yellow" $lastTag
  Write-Host -NoNewline " revision "
  Write-Host -ForegroundColor "yellow" "$lastTagCommit"
  [reflection.assembly]::LoadWithPartialName("System.Version")

  $version = New-Object System.Version($versionString)
  return $version;
}

# Returns current revision by counting the number of commits to HEAD
function Get-Revision(){
   $lastTagCommit = git rev-list HEAD
   $revs  = git rev-list $lastTagCommit |  Measure-Object -Line
   return $revs.Lines
}

# Returns the next major version {major}.{minor}.{revision}
function Get-NextMajorVersion(){
    $version = Get-LastVersion;
    [reflection.assembly]::LoadWithPartialName("System.Version")
    [int] $major = $version.Major+1;
    $rev = Get-Revision
    $nextMajor = New-Object System.Version($major, 0, $rev);
    return $nextMajor;
}

# Returns the next minor version {major}.{minor}.{revision}
function Get-NextMinorVersion(){
    $version = Get-LastVersion;
    [reflection.assembly]::LoadWithPartialName("System.Version")
    [int] $minor = $version.Minor+1;
    $rev = Get-Revision
    $next = New-Object System.Version($version.Major, $minor, $rev);
    return $next;
}

# Creates a tag with the next minor version
function TagNextMinorVersion($tagMessage){
    $version = Get-NextMinorVersion;
    $tagName = "v{0}" -f "$version".Trim();
    Write-Host -NoNewline "Tagging next minor version to ";
    Write-Host -ForegroundColor DarkYellow "$tagName";
    git tag -a $tagName -m $tagMessage
}

# Creates a tag with the next major version (minor version starts again at 0)
function TagNextMajorVersion($tagMessage){
    $version = Get-NextMajorVersion;
    $tagName = "v{0}" -f "$version".Trim();
    Write-Host -NoNewline "Tagging next majo version to ";
    Write-Host -ForegroundColor DarkYellow "$tagName";
    git tag -a $tagName -m $tagMessage
}

4

প্রতিটি প্রতিশ্রুতিবদ্ধ একটি অনন্য হ্যাশ আছে। গিট ছাড়া কোনও সংশোধন নম্বর নেই। আপনি যদি আরও ব্যবহারকারীবান্ধবতা চান তবে আপনাকে নিজের প্রতিশ্রুতিবদ্ধ ট্যাগ করতে হবে।


3

আমি কেবল আরেকটি সম্ভাব্য পদ্ধতির নোট করতে চাই - এবং তা হ'ল git গিট-নোট (1) ব্যবহার করে , যা ভি ১.6..6 ( স্বরে টোটাল - গিট ) (আমি gitসংস্করণটি 1.7.9.5 ব্যবহার করছি )।

মূলত, আমি git svnলিনিয়ার ইতিহাস (কোনও স্ট্যান্ডার্ড বিন্যাস, কোনও শাখা, কোনও ট্যাগ নেই) সহ একটি এসভিএন সংগ্রহস্থল ক্লোন করতাম এবং আমি ক্লোন করা gitসংগ্রহস্থলে পুনর্বিবেচনার সংখ্যার তুলনা করতে চেয়েছিলাম । এই গিট ক্লোনটিতে ডিফল্টরূপে ট্যাগ নেই, তাই আমি ব্যবহার করতে পারি না git describe। এখানে কৌশলটি সম্ভবত কেবল রৈখিক ইতিহাসের জন্য কাজ করবে - নিশ্চিত নয় যে এটি মার্জ ইত্যাদির সাথে কীভাবে চালু হবে; তবে এখানে মূল কৌশলটি:

  • git rev-listসমস্ত প্রতিশ্রুতিবদ্ধ ইতিহাসের তালিকা জিজ্ঞাসা করুন
    • যেহেতু rev-list"বিপরীত কালানুক্রমিক ক্রমে" ডিফল্টরূপে হয় তাই আমরা --reverseপ্রাচীনতম অনুসারে বাছাই করা কমিটের তালিকা পেতে তার স্যুইচটি ব্যবহার করব
  • bashশেল থেকে ব্যবহার করুন
    • রিভিশন কাউন্টার হিসাবে প্রতিটি প্রতিশ্রুতিতে একটি কাউন্টার ভেরিয়েবল বাড়ান,
    • প্রতিটি কমিটের জন্য একটি "অস্থায়ী" গিট নোট তৈরি করুন এবং যুক্ত করুন
  • তারপর, ব্যবহার করে লগ ব্রাউজ git logসঙ্গে --notes, যা একটি কমিট এর নোট, যা এই ক্ষেত্রে "সংস্করণ সংখ্যা" হবে ডাম্প হবে
  • হয়ে গেলে অস্থায়ী নোটগুলি মুছুনgit status ( এনবি: এই নোটগুলি প্রতিশ্রুতিবদ্ধ কিনা তা আমি নিশ্চিত নই; সেগুলি সত্যই প্রদর্শিত হয় না )

প্রথমে নোটের gitডিফল্ট অবস্থান রয়েছে তা নোট করুন - তবে আপনি নোটগুলির জন্য একটি ref(উত্সাহ) নির্দিষ্ট করতে পারেন - যা সেগুলি নীচে একটি পৃথক ডিরেক্টরিতে সঞ্চয় করবে .git; উদাহরণস্বরূপ, একটি gitরেপো ফোল্ডারে থাকাকালীন , আপনি git notes get-refযে ডিরেক্টরিটি হবে তা দেখতে কল করতে পারেন:

$ git notes get-ref
refs/notes/commits
$ git notes --ref=whatever get-ref
refs/notes/whatever

লক্ষণীয় বিষয়টি হ'ল আপনি যদি notes addএকটি দিয়ে থাকেন তবে আপনাকে --refঅবশ্যই পরে সেই রেফারেন্সটি ব্যবহার করতে হবে - অন্যথায় আপনি " অবজেক্ট XXX এর জন্য কোনও নোট পাওয়া যায়নি ... " এর মতো ত্রুটি পেতে পারেন ।

এই উদাহরণস্বরূপ, আমি refনোটগুলিকে "লিনেরিভ" (লিনিয়ার রিভিশনের জন্য) কল করতে বেছে নিয়েছি - এর অর্থ এটিও নয় যে পদ্ধতিটি ইতিমধ্যে বিদ্যমান নোটগুলির সাথে হস্তক্ষেপ করবে। আমি --git-dirস্যুইচটিও ব্যবহার করছি , gitনবাগত হওয়ার কারণে , এটি বুঝতে আমার কিছুটা সমস্যা হয়েছিল - তাই আমি "পরে মনে রাখব" চাই :); এবং আমি ব্যবহার --no-pagerকরার lessসময় স্প্যানিং দমন করতেও ব্যবহার করি git log

সুতরাং, ধরে নিই যে আপনি একটি ডিরেক্টরিতে myrepo_gitরয়েছেন , এমন একটি সাব-ফোল্ডার যা একটি gitসংগ্রহস্থল; এক করতে পারে:

### check for already existing notes:

$ git --git-dir=./myrepo_git/.git notes show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.
$ git --git-dir=./myrepo_git/.git notes --ref=linrev show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.

### iterate through rev-list three, oldest first,
### create a cmdline adding a revision count as note to each revision

$ ix=0; for ih in $(git --git-dir=./myrepo_git/.git rev-list --reverse HEAD); do \
  TCMD="git --git-dir=./myrepo_git/.git notes --ref linrev"; \
  TCMD="$TCMD add $ih -m \"(r$((++ix)))\""; \
  echo "$TCMD"; \
  eval "$TCMD"; \
done

# git --git-dir=./myrepo_git/.git notes --ref linrev add 6886bbb7be18e63fc4be68ba41917b48f02e09d7 -m "(r1)"
# git --git-dir=./myrepo_git/.git notes --ref linrev add f34910dbeeee33a40806d29dd956062d6ab3ad97 -m "(r2)"
# ...
# git --git-dir=./myrepo_git/.git notes --ref linrev add 04051f98ece25cff67e62d13c548dacbee6c1e33 -m "(r15)"

### check status - adding notes seem to not affect it:

$ cd myrepo_git/
$ git status
# # On branch master
# nothing to commit (working directory clean)
$ cd ../

### check notes again:

$ git --git-dir=./myrepo_git/.git notes show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.
$ git --git-dir=./myrepo_git/.git notes --ref=linrev show
# (r15)

### note is saved - now let's issue a `git log` command, using a format string and notes:

$ git --git-dir=./myrepo_git/.git --no-pager log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD
# 04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 << (r15)
# 77f3902: _user_: Sun Apr 21 18:29:00 2013 +0000:  >>test message 14<< (r14)
# ...
# 6886bbb: _user_: Sun Apr 21 17:11:52 2013 +0000:  >>initial test message 1<< (r1)

### test git log with range:

$ git --git-dir=./myrepo_git/.git --no-pager log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD^..HEAD
# 04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 << (r15)

### erase notes - again must iterate through rev-list

$ ix=0; for ih in $(git --git-dir=./myrepo_git/.git rev-list --reverse HEAD); do \
  TCMD="git --git-dir=./myrepo_git/.git notes --ref linrev"; \
  TCMD="$TCMD remove $ih"; \
  echo "$TCMD"; \
  eval "$TCMD"; \
done
# git --git-dir=./myrepo_git/.git notes --ref linrev remove 6886bbb7be18e63fc4be68ba41917b48f02e09d7
# Removing note for object 6886bbb7be18e63fc4be68ba41917b48f02e09d7
# git --git-dir=./myrepo_git/.git notes --ref linrev remove f34910dbeeee33a40806d29dd956062d6ab3ad97
# Removing note for object f34910dbeeee33a40806d29dd956062d6ab3ad97
# ...
# git --git-dir=./myrepo_git/.git notes --ref linrev remove 04051f98ece25cff67e62d13c548dacbee6c1e33
# Removing note for object 04051f98ece25cff67e62d13c548dacbee6c1e33

### check notes again:

$ git --git-dir=./myrepo_git/.git notes show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.
$ git --git-dir=./myrepo_git/.git notes --ref=linrev show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.

সুতরাং, কমপক্ষে কোনও শাখাবিহীন সম্পূর্ণ রৈখিক ইতিহাসের আমার নির্দিষ্ট ক্ষেত্রে, সংশোধন সংখ্যাগুলি এই পদ্ধতির সাথে মেলে বলে মনে হচ্ছে - এবং অতিরিক্ত হিসাবে, মনে হয় যে এই পদ্ধতির git logপুনর্বিবেচনা রেঞ্জগুলির সাথে ব্যবহার করার অনুমতি দেবে , যখন এখনও সঠিক সংশোধন সংখ্যাগুলি পাবে - ওয়াইএমএমভি ভিন্ন প্রসঙ্গে, যদিও ...

আশা করি এটি কাউকে সাহায্য করবে,
চিয়ার্স!


সম্পাদনা: ঠিক আছে, gitউপরের লুপগুলির জন্য এলিয়াস সহ , এটি বলা যায় setlinrevএবং এখানে কিছুটা সহজ unsetlinrev; আপনার গিট রিপোজিটরি ফোল্ডারে থাকাকালীন করুন ( দুষ্টু পালানোর বিষয়টি নোট করুন bash, # 16136745 দেখুন - একটি সেমিকেলনযুক্ত একটি গিট ওরফে যুক্ত করুন ):

cat >> .git/config <<"EOF"
[alias]
  setlinrev = "!bash -c 'ix=0; for ih in $(git rev-list --reverse HEAD); do \n\
      TCMD=\"git notes --ref linrev\"; \n\
      TCMD=\"$TCMD add $ih -m \\\"(r\\$((++ix)))\\\"\"; \n\
      #echo \"$TCMD\"; \n\
      eval \"$TCMD\"; \n\
    done; \n\
    echo \"Linear revision notes are set.\" '"

  unsetlinrev = "!bash -c 'ix=0; for ih in $(git rev-list --reverse HEAD); do \n\
      TCMD=\"git notes --ref linrev\"; \n\
      TCMD=\"$TCMD remove $ih\"; \n\
      #echo \"$TCMD\"; \n\
      eval \"$TCMD 2>/dev/null\"; \n\
    done; \n\
    echo \"Linear revision notes are unset.\" '"
EOF

... যাতে git setlinrevলিনিয়ার রিভিশন নোট জড়িত লগ করার চেষ্টা করার আগে আপনি কেবল অনুরোধ করতে পারেন ; এবং git unsetlinrevআপনার কাজ শেষ হয়ে গেলে সেই নোটগুলি মুছতে; গিট রেপো ডিরেক্টরি থেকে একটি উদাহরণ:

$ git log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD^..HEAD
04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 <<

$ git setlinrev
Linear revision notes are set.
$ git log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD^..HEAD
04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 << (r15)
$ git unsetlinrev
Linear revision notes are unset.

$ git log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD^..HEAD
04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 <<

এই গোপনীয়তাটি সম্পূর্ণ করতে শেলটি যে সময় নেবে তা নির্ভর করে সংগ্রহস্থলের ইতিহাসের আকারের উপর।


2

যারা একটি আছে জন্য অ্যান্ট বিল্ড প্রক্রিয়া, আপনি এই লক্ষ্য সঙ্গে Git উপর একটি প্রকল্পের জন্য একটি সংস্করণ সংখ্যা তৈরি করতে পারেন:

<target name="generate-version">

    <exec executable="git" outputproperty="version.revisions">
        <arg value="log"/>
        <arg value="--oneline"/>
    </exec>

    <resourcecount property="version.revision" count="0" when="eq">
        <tokens>
            <concat>
                <filterchain>
                    <tokenfilter>
                        <stringtokenizer delims="\r" />
                    </tokenfilter>
                </filterchain>
            <propertyresource name="version.revisions" />
            </concat>
        </tokens>
    </resourcecount>
    <echo>Revision : ${version.revision}</echo>

    <exec executable="git" outputproperty="version.hash">
        <arg value="rev-parse"/>
        <arg value="--short"/>
        <arg value="HEAD"/>
    </exec>
    <echo>Hash : ${version.hash}</echo>


    <exec executable="git" outputproperty="version.branch">
        <arg value="rev-parse"/>
        <arg value="--abbrev-ref"/>
        <arg value="HEAD"/>
    </exec>
    <echo>Branch : ${version.branch}</echo>

    <exec executable="git" outputproperty="version.diff">
        <arg value="diff"/>
    </exec>

    <condition property="version.dirty" value="" else="-dirty">
        <equals arg1="${version.diff}" arg2=""/>
    </condition>

    <tstamp>
        <format property="version.date" pattern="yyyy-mm-dd.HH:mm:ss" locale="en,US"/>
    </tstamp>
    <echo>Date : ${version.date}</echo>

    <property name="version" value="${version.revision}.${version.hash}.${version.branch}${version.dirty}.${version.date}" />

    <echo>Version : ${version}</echo>

    <echo file="version.properties" append="false">version = ${version}</echo>

</target>

ফলাফলটি এরকম দেখাচ্ছে:

generate-version:
    [echo] Generate version
    [echo] Revision : 47
    [echo] Hash : 2af0b99
    [echo] Branch : master
    [echo] Date : 2015-04-20.15:04:03
    [echo] Version : 47.2af0b99.master-dirty.2015-04-20.15:04:03

আপনার সংস্করণ নম্বর উত্পন্ন করার সময় আপনার কাছে ফাইল (গুলি) প্রতিশ্রুতিবদ্ধ না থাকায় নোংরা পতাকাটি এখানে রয়েছে। কারণ সাধারণত, আপনি যখন নিজের অ্যাপ্লিকেশনটি তৈরি / প্যাকেজ করেন, তখন প্রতিটি কোড সংশোধন করতে হবে os


1

কমিটের SHA-1 আইডির সাথে সার্ভারের সময় এবং তারিখটি কী সহায়তা করবে?

এটার মতো কিছু:

প্রতিশ্রুতি 19 আগস্ট 2013 11:30:25 এ ঘটেছে 6886bbb7be18e63fc4be68ba41917b48f02e09d7_19aug2013_113025 হিসাবে প্রদর্শিত হবে


1

গিট ম্যানুয়াল থেকে, ট্যাগগুলি এই ইস্যুটির একটি উজ্জ্বল উত্তর:

গিটে একটি টীকাযুক্ত ট্যাগ তৈরি করা সহজ। সবচেয়ে সহজ উপায় হ'ল - আপনি ট্যাগ কমান্ডটি চালানোর সময় একটি নির্দিষ্ট করে:

$ git tag -a v1.4 -m 'my version 1.4'

$ git tag
v0.1
v1.3
v1.4

পরীক্ষা করে দেখুন 2.6 গীত বুনিয়াদি - ট্যাগিং


খুব খারাপ আপনাকে ডিফল্টগুলি পরিবর্তন করতে হুপের মধ্য দিয়ে ঝাঁপিয়ে By default, the git push command doesn’t transfer tags to remote servers.
পড়তে হবে

1

আমরা এই আদেশটি গিট থেকে সংস্করণ এবং সংশোধন পেতে ব্যবহার করছি :

git describe --always --tags --dirty

এটি ফিরে আসে

  • কোনও ট্যাগিং ব্যবহার না করা হলে সংশোধন হিসাবে হ্যাশ প্রতিশ্রুতিবদ্ধ (যেমন gcc7b71f)
  • কোনও ট্যাগে থাকাকালীন সংস্করণ হিসাবে ট্যাগের নাম (যেমন v2.1.0 , মুক্তির জন্য ব্যবহৃত)
  • ট্যাগের নাম, শেষ ট্যাগের পরে সংশোধন নম্বর এবং একটি ট্যাগের পরে হ্যাশ প্রতিশ্রুতিবদ্ধ (যেমন v5.3.0-88-gcc7b71f)
  • উপরের প্লাসের মতো একটি "নোংরা" ট্যাগের মতো যদি কার্যক্ষম গাছটিতে স্থানীয় পরিবর্তন থাকে (যেমন v5.3.0-88-gcc7b71f-dirty)

আরও দেখুন: https://www.git-scm.com/docs/git-describe#Docamentation/git-describe.txt


0

ভিজ্যুয়াল স্টুডিওর জন্য পোস্ট বিল্ড ইভেন্ট

echo  >RevisionNumber.cs static class Git { public static int RevisionNumber =
git  >>RevisionNumber.cs rev-list --count HEAD
echo >>RevisionNumber.cs ; }

-1

ব্যবহার বিবেচনা করুন

git-rev-label

গিট সংগ্রহস্থল সংশোধন সম্পর্কে ফর্ম্যাট মত তথ্য দেয় master-c73-gabc6bec। পরিবেশগত ভেরিয়েবল এবং গিটের তথ্য সহ টেম্পলেট স্ট্রিং বা ফাইল পূরণ করতে পারে। প্রোগ্রামটির সংস্করণ সম্পর্কিত তথ্য সরবরাহ করতে দরকারী: শাখা, ট্যাগ, কমিট হ্যাশ, গণনা, নোংরা স্থিতি, তারিখ এবং সময়। সর্বাধিক দরকারী জিনিসগুলির মধ্যে অন্যতম হ'ল কমিটগুলি গণনা করা, একীভূত শাখাগুলিকে বিবেচনা না করা - কেবল প্রথম পিতা-মাতা।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.