একটি উত্পাদন শাখা আছে বা মাস্টার ব্যবহার করে?


16

আমি একটি Railsঅ্যাপ্লিকেশনে অন্যান্য দূরবর্তী বিকাশকারীদের সাথে ছোট দলে কাজ করি । আমরা আমাদের gitকর্মপ্রবাহ পরিবর্তন করতে শুরু করছি starting আমরা নীচের মত একটি শাখা কাঠামো সম্পর্কে চিন্তা করেছি:

(dev) -> (qa) -> (stag) -> (master)

তবে কিছু বিকাশকারী ভেবেছিলেন যে এটি নতুন বিকাশকারীদের জন্য কম বিভ্রান্তিকর হতে পারে যারা স্বয়ংক্রিয়ভাবে মাস্টারের উপর উত্পাদন করতে পারে push পরিবর্তে তারা ভেবেছিল সবাইকে মাস্টার নিয়ে কাজ করতে হবে এবং উত্পাদনের জন্য একটি পৃথক শাখা তৈরি করা উচিত।

(master) -> (qa) -> (stag) -> (prod)

আমি আপনাকে শিখিয়েছি আপনি মাস্টারকে নিযুক্ত রাখতে চান এবং এটিকে বিকাশ হিসাবে এবং আগের জায়গাগুলি থেকে যেখানে আমি মাস্টারকে কাজ করেছি তার অর্থ উত্পাদনের জন্য সর্বদা নিযুক্তযোগ্য able

শাখা কাঠামো ব্যবহারের কিছু অসুবিধাগুলি কী হতে পারে যেখানে মাস্টার সক্রিয়ভাবে বিকাশের জন্য ব্যবহৃত হয় এবং একটি পৃথক প্রোড শাখা আপনি মোতায়েনের জন্য ব্যবহার করেন?

git 

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

2
আমরা কয়েকটি পার্থক্য সহ এই সাইটে বর্ণিত গিট ওয়ার্কফ্লো সফলভাবে ব্যবহার করি। nvie.com/posts/a-successful-git-branching-model পার্থক্য কেবলমাত্র এই যে আমরা স্থানীয় শাখা স্কোয়াশিংকে একটি উন্নত ইতিহাসের দেখাশোনা করার জন্য একটি বিকাশ করতে পছন্দ করি এবং "একটি প্রতিশ্রুতি, একটি সমস্যা" যুক্তি অনুসরণ করি
জেপেসেন

আপনার "স্ট্যাগ" শাখায় সাধারণত কি ঘটে?
সিমজিনিজার

পরিষ্কার সিআই / সিডি জন্য সুপারিশ। মাস্টার ব্রাঞ্চ ব্যবহার করা হয় না কারণ এটি সম্ভবত ভুল ব্যাখ্যা করা হয়। {বিকাশ} - {ইউনিট} - {সংহত} - {মঞ্চ aging - {উত্পাদন}} নীল / সবুজ রঙের উত্পাদন ক্রমাগত বিল্ডিং> সক্রিয় স্লাইস, এবং মজাদার> নিষ্ক্রিয় স্লাইস। মাথা> বৈশিষ্ট্যগুলি বন্ধ করা হয় যেখানে শাখা বিকাশ করুন। ইন্টিগ্রেশন এবং মঞ্চায়নের দিকে অগ্রগতি ইউনিটের দিকে এগিয়ে যাওয়ার জন্য ওয়েব হুকগুলি বিকাশ করুন (সংহতকরণের জন্য উপযুক্ত ট্যাগ সহ)। হটফিক্সগুলি বিকাশ + উত্পাদনের দিকে (বিরল তবে তা ঘটে)। আরও জটিলতা কিন্তু একটি সাধারণ ধারণা।
জিমি এমজি লিম

উত্তর:


16

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

এখানে প্রকৃত ঝামেলা প্রক্রিয়া এবং পদ্ধতি এক। আরও সিনিয়র ডেভস যেগুলি উদ্বিগ্ন যে এটি এক উপায়ে করলে তা আরও নতুন বিভ্রান্ত করবে, রিলিজের মডেলটি কী এবং কেন সেভাবে তা বোঝাতে সময় বিনিয়োগের জন্য প্রস্তুত থাকা প্রয়োজন।

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


1
আমি সত্যিই মনে করি আপনি একটি ভাল পয়েন্ট হিট। সাহায্য করার জন্য ধন্যবাদ.

ট্যাগ করার জন্য +1 কমিট করে। আমি বেশিরভাগ সময় নিজেই কাজ করি তবে আমি দুটি কারণে রিলিজ ট্যাগ করি। 1) বাস্তবে উত্পাদনে কোন কমিট রয়েছে তা দেখানোর জন্য এটি ভিজ্যুয়াল গিট ইতিহাস সরঞ্জামের সাথে দুর্দান্ত কাজ করে। 2) এটি গিটহাবের মতো সরঞ্জামগুলির সাথে দুর্দান্ত কাজ করে যা ট্যাগ করা প্রতিশ্রুতি পরীক্ষা করে এবং গ্রাসের জন্য একটি জিপ ফাইলে প্যাক করে রিলিজ সংস্করণগুলি প্যাকেজ করতে পারে।
13

9

আমি আপনার দ্বিধা দেখতে পাচ্ছি। আমার কাছে এটি ছিল, যতক্ষণ না আমি সর্বদা মাস্টার সম্পর্কে যা অনুমান করি তা অজ্ঞান করে দিয়েছি।

আমি আপনাকে শিখিয়েছি আপনি মাস্টারকে নিযুক্ত রাখতে চান এবং এটিকে বিকাশ হিসাবে এবং আগের জায়গাগুলি থেকে যেখানে আমি মাস্টারকে কাজ করেছি তার অর্থ উত্পাদনের জন্য সর্বদা নিযুক্তযোগ্য able

গিটের ডকুমেন্টেশন / বই থেকে - গিট শাখা

গিতে "মাস্টার" শাখাটি কোনও বিশেষ শাখা নয়। এটি ঠিক অন্য কোনও শাখার মতো। প্রায় প্রতিটি সংগ্রহস্থলের একমাত্র কারণ হ'ল git init কমান্ড এটিকে ডিফল্টরূপে তৈরি করে এবং বেশিরভাগ লোকেরা এটি পরিবর্তন করতে বিরত হন না।

সুতরাং, আপনার যদি পছন্দসই কর্মপ্রবাহ থাকে, এবং এটির সাথে কাজ করা কঠিন কারণ দলের বিভিন্ন বিকাশকারীদের সম্পর্কে বিভিন্ন ধারণা রয়েছে master। আপনি এমনকি নীচের মত একটি ওয়ার্কফ্লো masterবলার জন্য prodএবং পুনরায় নামকরণ বিবেচনা করতে পারেন -

(dev) -> (qa) -> (stag) -> (prod)

এখানে কিভাবে তুমি মাস্টার শাখা নাম পরিবর্তন

আমি বলছি না যে আপনাকে অবশ্যই masterশাখার নাম পরিবর্তন করতে হবে । তবে যদি আপনার পছন্দসই কর্মপ্রবাহ থাকে এবং এটি masterশাখার নাম পরিবর্তন করতে সহায়তা করে তবে তা সর্বদাই করে করুন :-)


এটা খুব ভালো ধারণা. উজ্জ্বল করার জন্য ধন্যবাদ আমি জানি না যে আমরা নামকরণের জন্য এতদূর যাব কিনা তবে এটি জেনে রাখা ভাল যে গিট কোনও বিশেষভাবে মাস্টারকে ব্যবহার করে না। ধন্যবাদ!

6

আমি এক্ষেত্রে সম্মেলনের চেয়ে চেক পছন্দ করি। প্রতিটি দলে এমন সদস্য রয়েছে যারা নতুন বৈশিষ্ট্যগুলি শুরু করতে আরও ভাল এবং অন্যান্য ব্যক্তিরা যারা মুক্তির জন্য জিনিসগুলিকে স্থিতিশীল করতে আরও ভাল।

যদি আপনার পরবর্তীটির অভাব হয়, তবে কোড পর্যালোচনাগুলি সহায়তা করবে (প্রায়শই, আরও শৃঙ্খলাবদ্ধ লোকেরা যাইহোক কোড রিভিউ চাইবে)।

এ কারণেই আমরা আমাদের গিট রেপো কনফিগার করে (আমরা গিটল্যাব ব্যবহার করছি) যে কেবলমাত্র নির্দিষ্ট লোকেরা পুল অনুরোধগুলিকে একীভূত করতে পারে এবং প্রতিটি বিকাশকারী মূল রেপোর নিজস্ব ব্যক্তিগত কাঁটাচামচ পান।

এটি দুটি সমস্যার সমাধান করে:

  1. নতুন বিকাশকারীরা ভুল শাখা পরিবর্তন করতে পারে না (যেহেতু তারা সরাসরি তাদের কাজটি মূল রেপোতে ঠেলাতে পারে না)। তারা masterতাদের নিজস্ব রেপোতে চাপ দিতে পারে তবে যখন টানা অনুরোধটি আসবে তখন তা ঠিক হয়ে যাবে।

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


1

এটি সমস্ত সামগ্রিক সফ্টওয়্যার বিকাশের প্রক্রিয়ার উপর নির্ভর করে। কনফিগারেশন পরিচালনা এবং কীভাবে একটি নতুন সংস্করণ আসে তা সামগ্রিক প্রক্রিয়া সম্পর্কে না জেনে সংজ্ঞায়িত করা যায় না।

"চটচটে" গোষ্ঠী আছে যারা "সর্বদা কার্যনির্বাহী প্রথম কমিটের অঞ্চল" বেছে নেবে। তারা সেই অঞ্চলের বিরুদ্ধে অবিচ্ছিন্নভাবে স্বয়ংক্রিয় বিল্ড এবং পরীক্ষার সুবিধা চালাত এবং "সর্বদা" একটি কার্যনির্বাহী ব্যবস্থা রাখার চেষ্টা করবে।

তারা (মাস্টার) -> (মুক্তি) দেখতে পাবে সম্ভবত 1,2 মধ্যবর্তী পদক্ষেপের সংস্থাকে উপকারী হিসাবে দেখায়।

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

এই ক্লাসিক পদ্ধতির অর্থ অগত্যা এই নয় যে দীর্ঘ সময় রয়েছে যেখানে সম্পূর্ণ পণ্য বিল্ড পাওয়া যায় না।

সুতরাং "ক্লাসিক" কর্মপ্রবাহটি হবে: (দেব) -> (ইউনিট) -> (সংহতকরণ) -> (পরীক্ষা / কিউএ) -> (উত্পাদন)।

ইন্টিগ্রেটারের ভূমিকা হ'ল মুক্তিপ্রাপ্ত ইউনিটগুলি "গ্রহণ / ক্রয়" করা বা যদি তারা পরবর্তী আসন্ন মুক্তির প্রয়োজনীয়তার সাথে ফিট না করে তবে তাদের প্রত্যাখ্যান করে।

এটি একটি পাশের নোটে সুবিধাজনক উপায়ে 2 2 টি মৌলিক পদ্ধতির মিশ্রণ করাও সম্ভব।

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

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