গিট কমিটে যে শাখায় তারা তৈরি হয়েছিল তার নাম কেন রাখে না?

Question

বৈশিষ্ট্যযুক্ত শাখা ব্যবহার করে কোনও দলে গিটের সাথে কাজ করার সময়, আমি প্রায়শই ইতিহাসে শাখা কাঠামো বুঝতে অসুবিধা বোধ করি।

উদাহরণ:

ধরা যাক এখানে একটি বৈশিষ্ট্যযুক্ত শাখা বৈশিষ্ট্য / মেক-কফি ছিল এবং বৈশিষ্ট্য শাখার সমান্তরালে মাস্টারটিতে বাগফিক্সিং অব্যাহত ছিল ।

ইতিহাস এর মতো দেখতে পারে:

*     merge feature/make-coffee
|\
| *   small bugfix
| |
* |    fix bug #1234
| |
| *    add milk and sugar
| |
* |    improve comments
| |
* |    fix bug #9434
| |
| *    make coffe (without milk or sugar)
| |
* |    improve comments
|/
*

সমস্যা

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

বিপরীতে, সাবভার্সনে, এটি উল্লেখযোগ্যভাবে সহজ কারণ শাখার নামটি ইতিহাসের অংশ - তাই আমি এখনই বলতে পারি যে একটি প্রতিশ্রুতি মূলত "বৈশিষ্ট্য / মেক-কফি" নিয়ে তৈরি হয়েছিল।

কমিট তৈরি করার সময় কমিট মেটাডাটাতে বর্তমান শাখার নাম অন্তর্ভুক্ত করে গিট এটিকে আরও সহজ করতে পারে (লেখক, তারিখ ইত্যাদি সহ)। তবে গিট এটি করে না not

এটি করা না হওয়ার কিছু মৌলিক কারণ আছে কি? বা এটি ঠিক যে বৈশিষ্ট্যটি কেউ চায়নি? যদি এটি পরে হয়, নাম না দেখে historicalতিহাসিক শাখাগুলির উদ্দেশ্য বোঝার অন্যান্য উপায় আছে কি?

Comments

সম্পর্কিত প্রশ্ন: কোন শাখা থেকে কোন শাখা এসেছে তা সন্ধান করা । গিটটি পরিষ্কারভাবে এটি রেকর্ড করে না এমন সত্ত্বেও এই তথ্যটি কীভাবে সন্ধান করা যায় সে সম্পর্কে এটি।

— সেলসেকে

নিজের জন্য নোট: মজার ব্যাপার হচ্ছে, Mercurial মধ্যে কমিট করে শাখার নাম ধারণ করে। সুতরাং দেখে মনে হচ্ছে গার্ক ডেভসের চেয়ে মারকুরিয়াল ডেভস আলাদা ডিজাইনের সিদ্ধান্ত নিয়েছে। বিশদ জানতে উদাঃ felipec.wordpress.com/2012/05/26/… দেখুন ।

— স্লেসকে

Answer 1

সম্ভবত কারণ একটি শাখার মধ্যে শাখার নামগুলি কেবল অর্থবহ। যদি আমি make-coffeeদলে থাকি এবং আমার সমস্ত পরিবর্তন একজন দারোয়ানের মাধ্যমে জমা করি, তবে আমার masterশাখাটি দারোয়ানের শাখায় টানতে পারে make-coffee-gui, যা সে তার make-coffee-backendশাখায় একীভূত হয়ে যাবে, যা একটি make-coffeeশাখায় কেন্দ্রীয় masterশাখায় একীভূত হওয়ার পূর্বে অবকাশ নেবে reb

এমনকি একটি সংগ্রহস্থলের মধ্যেও, শাখার নামগুলি আপনার কার্যপ্রবাহের বিবর্তনের সাথে সাথে পরিবর্তন করতে পারে। masterবলা যেতে পারে পরে পরিবর্তন হতে পারে development।

কোডগনমের ইঙ্গিত অনুসারে, গিটের প্রয়োজন না হলে ডেটাতে কিছু বেক না করার দৃ strong ় নকশার দর্শন রয়েছে। ব্যবহারকারীরা তথ্যের পরে ডেটাগুলিকে তাদের পছন্দ অনুসারে ব্যবহার করতে git logএবং git diffআউটপুট দেওয়ার জন্য বিকল্পগুলি ব্যবহার করবেন বলে আশা করা হচ্ছে। আপনার পক্ষে আরও ভাল কাজ করার মতো কোনও ফর্ম্যাট না পাওয়া পর্যন্ত আমি কিছু চেষ্টা করার পরামর্শ দিচ্ছি। git log --first-parentউদাহরণস্বরূপ, কোনও শাখায় সংযুক্ত হওয়ার বিষয়ে কমিটগুলি দেখানো হবে না।

Comments

এটি লক্ষ করা উচিত যদিও প্রথম পিতামাতার সাধারণত ভুল হয়। কারণ সাধারণত একজন কেবল তারা যা কাজ করছে তাতে মাস্টারকে টেনে নিয়ে যায় এবং তাদের কাজকে প্রথম পিতা-মাতা এবং দ্বিতীয়টিকে মাস্টার করে তোলে।

— জান হুডেক

@ জানহুদেক: আসলে, এটি নির্ভর করে :-)। কাজটি করা ব্যক্তি যদি এটির সাথে মিলিত হয় তবে হ্যাঁ। যদি মার্জটি পরে ঘটে, তবে সম্ভবত কোনও পর্যালোচনার পরে, তারপরে সম্ভবত আরও বেশি সম্ভাবনা রয়েছে যে পর্যালোচক মাস্টার পরীক্ষা করে নিল এবং বৈশিষ্ট্য শাখাকে মাস্টারে মিশ্রিত করে, এটি পরীক্ষা করে ধাক্কা দেয়।

— sleske

Answer 2

সাথে শাখার ইতিহাস ট্র্যাক করুন --no-ff

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

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

   --no-ff
       Create a merge commit even when the merge resolves as a
       fast-forward. This is the default behaviour when merging an
       annotated (and possibly signed) tag.

এটি সাধারণত এর অনুরূপ একত্রীকরণের বার্তা তৈরি করবে Merge branch 'foo', সুতরাং আপনি সাধারণত নিম্নলিখিত পদের সাথে "পূর্বপুরুষের শাখাগুলি" সম্পর্কে তথ্য পেতে পারেন:

$ git log --regexp-ignore-case --grep 'merge branch'

Comments

ধন্যবাদ, তবে তা (বেশিরভাগ) আমার প্রশ্নের উত্তর দেয় না। মূল শাখাটি খুঁজে বের করার অন্যান্য উপায়গুলি আমি জিজ্ঞাসা করছি না, তবে কেন তথ্য নিয়মিত মেটাডেটা হিসাবে অন্তর্ভুক্ত করা হয় না - এটি আরও একটি নকশার প্রশ্ন design

— সেলসেকে

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

— কোডজোনম

শেষটি হওয়া উচিত git log --merges।

— ড্যান

Answer 3

এর সহজ উত্তরটি হ'ল শাখার নামগুলি সাময়িকের। আপনি যদি বলতে চান, একটি শাখার নাম পরিবর্তন করুন ( git branch -m <oldname> <newname>)? এই শাখার বিরুদ্ধে সমস্ত কমিটির কি হবে? বা যদি দুটি লোকের বিভিন্ন স্থানীয় ভাণ্ডারে একই নাম রয়েছে এমন শাখা থাকে?

গিটের একমাত্র অর্থ যা প্রতিশ্রুতিবদ্ধ তার চেকসাম। এটি ট্র্যাকিংয়ের প্রাথমিক ইউনিট।

তথ্য আছে, আপনি কেবল এটি চাইছেন না, এবং এটি ঠিক সেখানে নেই।

গিট প্রতিটি শাখার প্রধানের চেকসাম সংরক্ষণ করে .git/refs/heads। উদাহরণ স্বরূপ:

... /। গিট / রেফেস / মাথা $ ls পরীক্ষা 
-rw-rw-r-- 1 michealt michealt 41 সেপ্টেম্বর 11:50 পরীক্ষা
... /। গিট / রেফিস / মাথা $ বিড়াল পরীক্ষা test 
87111111111111111111111111111111111111d4

(হ্যাঁ, আমি আমার গিট চেকসামগুলি আঁটসাঁট করছি, এটি বিশেষ নয়, তবে তারা ব্যক্তিগত সংগ্রহস্থল যা আমি এই মুহুর্তে দেখছি যে দুর্ঘটনাক্রমে কিছু ফাঁস হওয়ার দরকার নেই)।

এটি দেখে এবং পিতামাতা হিসাবে এই প্রতিশ্রুতি, বা বাবা-মা বা বাবা-মা-বাবা হিসাবে থাকা প্রতিটি প্রতিশ্রুতিগুলি অনুসরণ করে ... আপনি প্রদত্ত প্রতিশ্রুতিবদ্ধ শাখাগুলি কী আছে তা খুঁজে পেতে পারেন re

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

আপনি উপযুক্ত পতাকা সহ গিট লগ কমান্ড চালিয়ে শাখাগুলি দেখতে পাচ্ছেন।

গিট লগ - ব্রাঞ্চগুলি --সোর্স - ব্যাখ্যা = অনলাইন - অনুচ্ছেদ
গিট লগ - সমস্ত --সোর্স - ব্যাখ্যা = অনলাইনলাইন - অনুগ্রহ করে

এর জন্য আপনি কী চান তা বাছাই করার বিভিন্ন উপায় রয়েছে - গিট লগ ডকুমেন্টেশন - -allবিভাগ এবং কয়েকটি বিকল্প যা অনুসরণ করে তা দেখুন।

* 8711111111111111111111111111111111111111d4 পরীক্ষা মার্জ শাখা 'টেস্ট 1' পরীক্ষায়
| \  
| * 4211111111111111111111111111111111111111e8 টেস্ট 1 আপডেট: স্টাফ যুক্ত করুন
* | dd111111111111111111111111111111111111115959 পরীক্ষা মার্জ শাখা 'test3' তে পরীক্ষা
| \ \  

এই 'পরীক্ষা', 'টেস্ট 1' এবং 'টেস্ট 2' হ'ল সেই শাখা যা প্রতিশ্রুতিবদ্ধ হয়েছিল।

নোট করুন যে গিট লগ ডকুমেন্টেশন বিশাল এবং এটি থেকে আপনি যা চান তার প্রায়শই পাওয়া সম্ভব।

Answer 4

গিট কমিটে যে শাখাটি তৈরি করা হয়েছিল তার নাম কেন নেই?

শুধু একটি নকশা সিদ্ধান্ত। আপনার যদি সেই তথ্যের প্রয়োজন হয় তবে আপনি একটি রেপোজিটরিতে এটি প্রয়োগ করতে একটি রেডি-কমিট-কমিট বা কমিট-হিক যুক্ত করতে পারেন।

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

এই ধরনের একটি কার্যপ্রবাহে কমিটের কোনও নির্দিষ্ট উত্স থাকতে পারে না, এবং গিট বিতরণ করার সাথে সাথে প্রায়শই কিছু অযৌক্তিক ডিবাগিং শাখায় মজাদার শাখার নাম সহ অযৌক্তিক ডিবাগিং শাখায় তৈরি হয় ory

সম্ভবত এই নকশার সিদ্ধান্তটি কাকতালীয়ভাবে ঘটেছিল তবে এটি লিনাক্স কার্নেল বিকাশের প্রক্রিয়াটির সাথে ঠিক মেলে।

Answer 5

কারণ গিটে "কফি তৈরির" মত বৈশিষ্ট্যগুলি যখন শাখার মার্জ করা হয় তখন উভয় শাখার অংশ হিসাবে বিবেচিত হয়। এটি যাচাই করার জন্য একটি আদেশও রয়েছে:

% git branch --contains @
  feature/make-coffee
  master

এছাড়াও, শাখাগুলি সস্তা, স্থানীয় এবং ইথেরিয়াল; সেগুলি সার্ভার থেকে সহজেই যুক্ত, মুছে ফেলা, নাম পরিবর্তন, ধাক্কা এবং মুছে ফেলা যায়।

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

ধরা যাক যে আমি 'মাস্টার' শাখায় ছিলাম, এবং আমি দুটি অঙ্গীকার করেছি: 'কফি তৈরি করুন' এবং 'দুধ এবং চিনি যুক্ত করুন', তারপরে আমি সিদ্ধান্ত নিই যে এর জন্য নতুন শাখা ব্যবহার করব, তাই আমি 'মাস্টার'টিকে আবার উত্সে পুনরায় সেট করব / মাস্টার '। কোনও সমস্যা নয়, সমস্ত ইতিহাস এখনও পরিষ্কার: 'কফি তৈরি করুন' এবং 'যোগ করুন দুধ এবং চিনি' মাস্টার অংশ নয়, কেবল বৈশিষ্ট্য / মেক-কফি।

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

সংক্ষেপে: গিট আপনাকে সমস্ত কিছু করার অনুমতি দেয়, মার্চুরিয়াল জিনিসগুলিকে সহজ করতে চায় (এবং আপনার যা ইচ্ছা তা করতে দেওয়া সত্যিই কঠিন করে তোলে)।