আপনি কীভাবে গিটের সাথে সংখ্যাসূচক সংস্করণটি অর্জন করবেন?

Question

আমার সংস্থা এসভিএন থেকে গিতে যাওয়ার বিষয়ে বিবেচনা করছে। সরানোর বিরুদ্ধে একটি যুক্তি নিম্নরূপ:

আমরা কীভাবে সংস্করণ করব?

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

সম্ভাব্য সমাধান:

• হাডসন থেকে বিল্ড নম্বর ব্যবহার করে (সমস্যা: এটি সত্যিকারের গিট সংস্করণের সাথে সম্পর্কিত করতে আপনাকে হডসনটি পরীক্ষা করতে হবে)
• রাত্রি এবং স্থিতিশীল জন্য সংস্করণটিকে ম্যানুয়ালি আপিং (সমস্যা: শেখার বক্ররেখা, মানব ত্রুটি)

যদি অন্য কারও কারওর সাথে একই রকম সমস্যা দেখা দেয় এবং এর সমাধান হয়, আমরা কীভাবে তা শুনতে আগ্রহী।

Comments

আপনি কি প্রতিটি হডসন ( জেনকিনস নন ?) সার্ভারটি gitপ্রতিটি সফল বিল্ডের পরে স্বয়ংক্রিয়ভাবে একটি ট্যাগ যুক্ত করতে পারবেন ? এটির অতিরিক্ত সুবিধা হ'ল এটি এটি পরিষ্কার gitকরে দেয় যে কোন অঙ্গীকারগুলি তৈরির বিষয়টি বা পরীক্ষায় ব্যর্থতা রয়েছে, যেহেতু তারা ট্যাগবিহীন থাকবে।

— মার্ক বুথ

দেখতে stackoverflow.com/questions/677436/...

— CharlesB

পার্শ্ব নোট হিসাবে, আপনি বিল্ডের সময়গুলি ট্র্যাক করে ট্যাগটিতে বিল্ড কাউন্ট যুক্ত করতে পারেন ।

— শাহবাজ

যদি কোনও কার্যকর সমাধান না হয় তা নিশ্চিত না, তবে প্রতিটি বিল্ডের আগে গিট থেকে কোনও এসএনএন রেপোতে রফতানি কীভাবে? তারপরে কেবল এসএনএন রেপো থেকে তৈরি করুন - যদি কেন্দ্রিয়ায়িত হয় যা আমরা চাই, কেবল তার পরিবর্তে এটি ব্যবহার করুন।

— জনি 20

Answer 1

সংস্করণ সংখ্যা সহ কমিটগুলি চিহ্নিত করতে ট্যাগগুলি ব্যবহার করুন :

git tag -a v2.5 -m 'Version 2.5'

ট্যাগগুলি উপরের দিকে চাপ দিন — এটি ডিফল্টরূপে করা হয় না:

git push --tags

তারপরে বর্ণনা কমান্ডটি ব্যবহার করুন :

git describe --tags --long

এটি আপনাকে বিন্যাসের একটি স্ট্রিং দেয়:

v2.5-0-gdeadbee
^    ^ ^^
|    | ||
|    | |'-- SHA of HEAD (first seven chars)
|    | '-- "g" is for git
|    '---- number of commits since last tag
|
'--------- last tag

Comments

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

— অকেজো

ছোট উন্নতি: git describe --long --tags --dirty --always। 'ডার্টি' আপনাকে বলবে যে 'বর্ননা' সম্পন্ন হওয়ার সময় স্থানীয় পরিবর্তন হয়েছিল কিনা (অর্থাত এটি রেপোর অবস্থার পুরোপুরি বর্ণনা করতে পারে না)। 'সর্বদা' মানে যখন কোনও ট্যাগ নেই তখন আপনি ত্রুটি পাবেন না। এটি কেবল একটি প্রতিশ্রুতিবদ্ধ হ্যাশ থেকে পড়ে যাবে। সুতরাং আপনি 76001f2-dirtyউদাহরণ হিসাবে পেতে পারেন । স্পষ্টতই, 'নোংরা' দেখার অর্থ কেউ গণ্ডগোল করেছে।

— মাইক ওয়েলার

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

— void.pointer

@ void.pointer: অবশ্যই, এই সংস্করণ নম্বরটি এই প্রশ্নের উত্তর দেয় যে "কোন রিলিজটি এই প্রতিশ্রুতিভিত্তিক ছিল?" নয় "কোন রিলিজটি এই প্রতিশ্রুতিবদ্ধ হবে?" তবে আপনি ট্যাগগুলি আলাদাভাবে ব্যাখ্যা করতে মুক্ত হন। উদাহরণস্বরূপ, আপনি যদি ট্যাগ HEADহিসাবে থাকেন তবে আপনি 2.5 রিলিজ চক্রের সূচনাv2.5 হিসাবে এটির পাশাপাশি তা ব্যাখ্যা করতে পারেন , তারপরে ট্যাগ করুন বা যা যা আপনার পছন্দ করুন। v2.5-release

— জন পুরি

আরেকটি ছোট উন্নতি। আপনি যদি অন্যান্য ট্যাগও রাখতে চান তবে সংশোধন জেনারেশনের জন্য একটি নির্দিষ্ট নকশার ট্যাগটি ব্যবহার করতে পারেন, আপনি --matchএই বিকল্পটি ব্যবহার করতে পারেন :git describe --long --tags --dirty --always --match 'v[0-9]\.[0-9]'

— আলেকজান্ডার আমেলকিন

Answer 2

এটি আমার জন্য কয়েকটি প্রকল্পে উঠে এসেছে। আমি এখনও অবধি সবচেয়ে ভাল সমাধানটি হ'ল এর মতো সংস্করণ নম্বর উত্পন্ন করা:

xy <কমিটের সংখ্যা> .r <git-hash>

সাধারণত, এটি আমাদের বিল্ড সিস্টেম দ্বারা কয়েকটি সংশোধন নম্বর git rev-list HEAD | wc -l(যা ব্যবহারের চেয়ে দ্রুততর ছিল git log) পেতে, এবং এর জন্য কিছু স্থির ফাইল বা ট্যাগের সংমিশ্রণ ব্যবহার করে উত্পন্ন হয়েছিল git rev-parse HEAD। যুক্তিটি নিম্নরূপ ছিল:

1. আমাদের উচ্চ-স্তরের সংস্করণ স্পষ্টভাবে ঘটানোর সক্ষমতা প্রয়োজন (iexy)
2. যখন সমান্তরাল বিকাশ ঘটেছিল তখন আমাদের একই সংস্করণ নম্বরটি কখনই তৈরি করা উচিত ছিল না।
3. আমরা কোনও সংস্করণটি কোথা থেকে এসেছে তা সহজেই সন্ধান করতে চাই।
4. যখন সমান্তরাল লাইনগুলি একত্রিত করা হয়েছিল, আমরা নতুন সংস্করণটি শাখার যে কোনওটির চেয়ে বেশি সমাধান করতে চেয়েছিলাম।

সংখ্যা 2 বেশিরভাগ মানুষের কাছে অদৃশ্য তবে সত্যই গুরুত্বপূর্ণ এবং বিতরণকৃত উত্স নিয়ন্ত্রণে সত্যই কঠিন। এসভিএন আপনাকে একক সংশোধন নম্বর দিয়ে এটিতে সহায়তা করে। এটি প্রমাণিত হয়েছে যে প্রতিশ্রুতিবদ্ধ গণনাটি আপনি যতটা কাছে পেতে পারেন ততই কাছাকাছি, যখন জাদুগতভাবে # 4 সমাধানও করছেন। শাখাগুলির উপস্থিতিতে, এটি এখনও অনন্য নয়, এক্ষেত্রে আমরা হ্যাশ যুক্ত করি, যা খুব সুন্দরভাবে # 3 সমাধান করে।

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

আপনি যদি ভাবছেন, আমরা পাইথন প্যাকেজিং সংস্করণ সংখ্যায় অক্ষরগুলি পরিচালনা করে (যেমন ae 0 এর চেয়ে কম, যা "1.3.10.a1234" তৈরি করবে) কিছু অদ্ভুততার কারণে আমরা হ্যাশের সামনে আরটি স্থাপন করা বেছে নিয়েছি << "1.3.10" <"1.3.10.1234")।

Comments

বিটিডব্লিউ, গিট-হ্যাশ যাচাইয়ের আগে আপনি মুরগির ডিমের সমস্যা নির্ধারণের ক্ষেত্রে কীভাবে মোকাবেলা করেছেন? আপনি কিছুটা .gitignore বা অন্য কোনও কৌশল ব্যবহার করেছেন?

— kfmfe04

আমি না। প্যাকেজ তৈরির সময় না হওয়া পর্যন্ত আমি হ্যাশ ব্যবহার করি না, যা চেক-ইন করার অনেক পরে। এটি ইনজেকশন করার জন্য বিভিন্ন ভাষার বিভিন্ন উপায় রয়েছে। পাইথনের জন্য, আমি './setup.py ডিম_ইনফো-বি "ব্যবহার করি। U বিল্ড_ ভার্সন s" এসডিস্ট'। সি এবং সি ++ এর জন্য, আমি 'সিএফএলএজিএস = -D "$ U বিল্ড_ভার্সন}"' দিয়ে সংকলনের সময় একটি ম্যাক্রো সংজ্ঞায়িত করি। Go এর জন্য, আমি 'go ইনস্টল -ldflags appmodule.BuildVersion "-X এর সাথে লিঙ্ক টাইমে একটি প্রতীককে সংজ্ঞায়িত করেছি $ U বিল্ড_ভার্সন}"'।

— জয়সন

এটি সেরা উত্তর হওয়া উচিত।

— অ্যালভিনাবাদ

খুব ভাল উত্তর

— হেলিক্স

Answer 3

সংস্করণগুলি চেকিনের সময় সঞ্চিত ডিরেক্টরি গাছের সমস্ত ফাইলের SHA1 হ্যাশগুলি চিহ্নিত করা হয়। এই হ্যাশটি প্যারেন্ট চেকিন (গুলি) এর হ্যাশগুলির পাশাপাশি সংরক্ষণ করা হয় যাতে পুরো ইতিহাসটি পড়তে পারে।

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

এখানে একটি দুর্দান্ত ব্লগ যা আপনি কী চান তা কীভাবে পাবেন তার উদাহরণ দেয়:

http://cd34.com/blog/programming/using-git-to-generate-an-automatic-version-number/

Answer 4

এটি কিছুটা ওভারকিল হতে পারে তবে আমি কীভাবে এটি করি তা আপনাকে জানাব।

আমরা খুব অনুরূপ একটি শাখাবিন্যাস গঠন ব্যবহার এই ।

হাডসন আমাদের "বিকাশ" শাখাগুলি তৈরি করে এবং ইনক্রিমেন্টগুলি ০ থেকে শুরু করে সংখ্যাগুলি তৈরি করে The বিল্ড নম্বর প্রতিটি প্রকল্পের জন্য স্বতন্ত্র এবং সংস্করণ নিয়ন্ত্রণে ট্যাগ হয়। এর কারণটি হ'ল আপনি যা বলতে পারবেন যে কোন শাখার বিকাশটি ৪২ টি থেকে এসেছে, উদাহরণস্বরূপ (প্রতিটি প্রকল্পের সমান্তরালভাবে বেশ কয়েকটি বিকাশশীল শাখা থাকতে পারে, কারণ প্রতিটি প্রকল্পে বেশ কয়েকটি দল প্রকল্পের বিভিন্ন দিক নিয়ে কাজ করতে পারে)।

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

উদাহরণ: 2.1.0 বিল্ড 1337

এর অর্থ, কোনও নির্দিষ্ট পণ্য প্রকাশের জন্য, আপনি বলতে পারবেন যে এটিতে সর্বশেষ দলটি কাজ করেছিল এবং আপনি যদি প্রয়োজন হয় তবে কোনও সমস্যা নির্ণয় করার জন্য প্রকাশিত সমস্ত কমিটের জন্য গিটকে জিজ্ঞাসা করতে পারেন can

Answer 5

জন পুরীর সঠিক ধারণা আছে। git flowএই শাখাগুলির প্রকৃত পরিচালনাও সহজ করে তোলে এবং শাখা পরিচালনাও সরানোর পক্ষে যুক্তি git।

এর মৌলিক ভগ্নস্বাস্থ্য শিঠ্ট দিয়ে শুরু করা যাক git, যেহেতু আপনার কাছ থেকে আসছে svn-to- gitদৃষ্টিকোণ। gitনিম্নলিখিত বিবেচনা করুন :

master--...............-.....-..............-
        \             /     /              /
         ---develop---------............../
                            \            /
                             --feature---

সর্বোপরি, আপনি শাখায় বিভক্ত masterকরার develop(দ্বারা প্রকাশ \), এবং শাখা developএকটি থেকে featureশাখা। আমরা সেই শাখাগুলিকে ব্যাক আপ (দ্বারা চিহ্নিত /), -একটি শাখার সাথে কমিট ( ) দিয়ে মার্জ করি । (যদি কোনও প্রতিশ্রুতি না থাকে তবে মার্জটি ডান দিকে যাওয়ার উপায় রয়েছে, সেখানে .পরবর্তীটি -পরবর্তী প্রতিশ্রুতিবদ্ধ তা দেখানোর জন্য সূচক রয়েছে )।

যথেষ্ট সহজ আমাদের মূল প্রকাশে যদি হটফিক্স থাকে?

master--...............-.....-................-...........-.........-
        \             /     /                / \         /|        /
         \           /     /                /   -hotfix-- V       /
          ---develop---------............../..............-...----
                             \            / \             V   /
                              --feature---   --feature2...----

উপরে, developশাখা থেকে master। যে বাগটি আবিষ্কার হয়েছিল masterতা শাখা থেকে ঠিক করে masterএবং এটিতে আবার মার্জ করে ঠিক করা হয়েছিল master। আমরা তখন মার্জ masterমধ্যে develop, এবং তারপর developমধ্যেfeature2 , যা থেকে নতুন কোড ঘূর্ণিত hotfixএই শাখা মধ্যে।

আপনি যখন feature2আবার মার্জ হয়ে যান develop, এর ইতিহাসটি এর developসাথে অন্তর্ভুক্ত থাকে hotfix। তেমনিভাবে, নতুন developকোডটির feature2সাথে মিশে গেছে master, সুতরাং কোনও সংযোজন ছাড়াই developফিরে মার্জ হয়ে যাওয়া masterহবে, কারণ এটি masterসেই সময়ে করা সেই প্রতিশ্রুতির উপর ভিত্তি করে — যেন আপনি masterসেই বিন্দু থেকে শাখা করেছিলেন ।

সুতরাং এটি করার অন্য একটি উপায়।

master--..........-........-
        \        /\       /
         ---1.0--  --1.1-- 

তোমার 1.0 রিলিজ tagged- পেতে 1.0.1, 1.0.2, 1.0.3, এবং তাই ঘোষণা।

এখন এখানে একটি কৌশল: আপনি 1.0 এ একটি বাগ খুঁজে পেয়েছেন এবং এটি 1.1, 1.2 এবং 1.3 কে প্রভাবিত করে। আপনি কি করেন?

আপনি আপনার সর্বশেষতম বা প্রাথমিক রক্ষণাবেক্ষণ প্রকাশ বন্ধ করুন এবং এটি ঠিক করুন। তারপর আপনি আপনার নতুন একত্রীকরণ hotfixমধ্যে শাখা 1.3মধ্যে -আর 1.2, 1.1এবং 1.0। রক্ষণাবেক্ষণ সংস্করণের প্রতিটি শাখা থেকে শাখা করবেন না; মার্জ না 1.0মধ্যে masterবা একত্রীকরণ masterফিরে 1.0। একটি hotfixশাখা নিন এবং এটি আপনার সমস্ত সংস্করণ শাখায় মার্জ করুন। যদি কোন্দল হয় তবে তা আপনাকে বলবে; পরিবর্তনগুলি সঠিক কিনা তা নিশ্চিত করতে আপনার কোডটি পর্যালোচনা করুন ( git diffএটি আপনার বন্ধু)।

এখন সুনির্দিষ্ট পরিবর্তনটি সর্বত্র প্রয়োগ করা হয়েছে। বংশ ব্রাঞ্চ করা হয়েছে, তবে ঠিক আছে। এটা হাফিজার্ড নয়। 1.31.3.17 হিসাবে শিরোনামটি ট্যাগ করুন , এটিকে ব্রাঞ্চযুক্ত প্রতিটি বৈশিষ্ট্যে-অগ্রগতিতে মার্জ 1.3করুন এবং এগিয়ে যান।

git flowএক্সটেনশন আপনার জন্য এই রক্ষণাবেক্ষণ, বৈশিষ্ট্য, এবং hotfix শাখা পরিচালনা করতে সাহায্য করে। ওয়ার্কফ্লোটি একবার ডাউন হয়ে গেলে, এটি তুচ্ছ এবং উত্স কোড পরিচালনার বাইরে বিপুল পরিমাণ সমস্যায় পড়ে takes

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

Answer 6

Key.২ বিভাগে প্রো গিট "কীওয়ার্ড" সম্প্রসারণ অংশের "গিট অ্যাট্রিবিউটস" এর মধ্যে আরসিএস-স্টাইলের কীওয়ার্ড তৈরির জন্য স্ম্যাড এবং ক্লিন ফিল্টার ব্যবহারের দুর্দান্ত উদাহরণ রয়েছে। কোডটিতে কিছু সংস্করণ-স্ট্রিং এম্বেড করার জন্য আপনি একই কৌশলটি ব্যবহার করতে পারেন , আপনার নিয়ম অনুসারে ফর্ম্যাট এবং গণনা করা হয়েছে । আপনি এখনও স্টারিং পয়েন্ট হিসাবে ব্যবহার করতে পারেন git describe, তবে আপনার আরও উপযুক্ত ফর্মে রূপান্তরিত হওয়ার এবং v2.5.5- ফিবিডেড থেকে পাওয়ার সম্ভাবনা রয়েছে, উদাহরণস্বরূপ, পরিষ্কার করুন 2.5.14

Comments

অ্যাড হোমিনেম আক্রমণের জন্য সম্পূর্ণ অপ্রয়োজনীয় একটি ভাল উত্তর নষ্ট করার জন্য -1।

— জার্গ ডব্লু মিট্টাগ

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

— মার্ক বুথ

এফওয়াইআই, আমি সবেমাত্র উত্তরটি সম্পাদনা করেছি।

— কিথ থম্পসন

git describeশেষ না --longহওয়া পর্যন্ত ট্যাগের নাম আউটপুট দেয় বা শেষ ট্যাগ থেকে কমিটস থাকে না, তাই এটি ইতিমধ্যে সম্পূর্ণ পরিষ্কার। আপনি যদি ডিফল্টগুলি পরিবর্তন না করে থাকেন তবে এটি আপনাকে যা চেয়েছিল ঠিক তা দিত।

— strcat 25'15