"বিকাশ" শাখার প্রবণতা চলে যাচ্ছে


82

আমি ইদানীং গিটহাবের কয়েকটি জনপ্রিয় প্রকল্পের দিকে নজর রেখে কিছু লক্ষ্য করেছি, এর কোনও developশাখা নেই। এবং প্রকৃতপক্ষে, গিটহাব ফ্লো গাইড এটির উল্লেখও করে না। আমার বোঝার থেকে, masterসর্বদা স্থিতিশীল হওয়া উচিত এবং উত্পাদন প্রতিফলিত করা উচিত। যদি বিকাশকারীরা বৈশিষ্ট্য শাখাগুলিতে কাজ করে এবং তারপরে এটিগুলিতে মার্জ করে master, এর অর্থ এমন একটি সময় আছে যেখানে বৈশিষ্ট্যগুলি / ফিক্সগুলি একত্রীকরণ করা হয় masterএবং masterশাখাটি উত্পাদনের চেয়ে প্রকৃতপক্ষে নতুন।

দলটি বৈশিষ্ট্য তৈরি / ঠিক করা শাখাগুলি বন্ধ করে দেওয়া develop, এটিতে আবার একত্রিত হওয়া এবং তারপরে যখন পরবর্তী সংস্করণ প্রকাশের জন্য পুরোপুরি প্রস্তুত developহয়, তখন মিশ্রিত হয়ে masterএকটি ট্যাগ তৈরি করা আরও কী বোঝায় না? কল্পনা করুন যে লোকেরা সরাসরি masterমিশ্রিত হচ্ছে, এবং উত্পাদনে একটি বাগ রিপোর্ট করা হয়েছে যা ঠিক করা কঠিন হয়ে পড়ে কারণ masterশাখা কোডবেস উল্লেখযোগ্যভাবে পরিবর্তিত হয়েছে। তারপরে ডেভগুলি কেবল ব্যবহারকারীকে সমস্যাটি সমাধানের জন্য পরবর্তী প্রকাশ পর্যন্ত অপেক্ষা করতে বলতে হবে।

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


11
গিট সক্ষম করে এমন অনেকগুলি সম্ভাব্য ওয়ার্কফ্লো রয়েছে। গিটারফ্লো বা গিথব ফ্লো সমস্ত প্রকল্পের জন্য ব্যবহৃত হবে এমনটি আশা করা উচিত নয়।

খুব মজার প্রশ্ন। আমি nvie.com/posts/a-successful-git-branching-model এর সাথে বহু বছর কাজ করেছি এবং আমাকে বলতে হয়েছে যে এটি আমার পছন্দ হয়েছে। আমি এটি সম্পর্কে সবচেয়ে বেশি যা পছন্দ করি তা হ'ল) ​​ক) মাস্টার হ'ল প্রোডাকশনে যা তা ভার্সন এবং বি এর ক্ষেত্রেও প্রযোজ্য) হটফিক্স এবং বৈশিষ্ট্যের মধ্যে স্পষ্ট পার্থক্য রয়েছে, সেগুলি সূচনা হয় এবং যথাক্রমে মাস্টারের সাথে মিশে যায় এবং বিকাশ হয়। যাইহোক, এই আলোচনা অনুসরণ করার পরে আমার সন্দেহ হওয়া শুরু হয় যে এটি অত্যধিক জটিল বিষয়গুলি কিনা। সে সম্পর্কে কোন মতামত?
আসপাসিয়া

1
আমি এই ধারণাটিকে ঘৃণা করি যে মাস্টার উত্পাদনে যা রয়েছে তার একটি রেকর্ড। আমাদের যদি উত্পাদনের বিষয়টি জানতে হয় তবে আমাদের কেবল উত্পাদন জিজ্ঞাসা করা উচিত এবং উত্পাদনে যা রয়েছে তা সঠিকভাবে প্রতিফলিত করার জন্য মাস্টারের উপর নির্ভর করা উচিত নয়।
জিম ভি

উত্তর:


52

এটি সিআই মানসিকতা থেকে আসে যেখানে দিনে বেশ কয়েকবার সংহত থাকে।

উভয় পক্ষের পক্ষে মতামত রয়েছে।

আমাদের দলে আমরা বিকাশকারী শাখাটিও ত্যাগ করেছি যেহেতু আমরা অনুভব করেছি যে এটি কোনও বাড়তি সুবিধা ছাড়াই কিছু বাড়িয়ে দিয়েছে। ত্রুটিগুলি পূরণ করতে আমরা আমাদের সিআই সফ্টওয়্যার (টিমসিটি) কনফিগার করেছি:

  1. একটি নির্দিষ্ট প্রতিশ্রুতি স্থাপনার সক্ষম করুন। অন্য কথায়: আমরা একটি শাখা মোতায়েন করি না। আমরা একটি প্রতিশ্রুতি নিযুক্ত।
  2. আমরা হটফিক্স / উপসর্গ দিয়ে শুরু করে মাস্টার বা শাখাগুলি স্থাপন করতে পারি।

এই কাজটি করার কারণটি হ'ল সমস্ত পুল অনুরোধে সম্ভাব্য রিলিজযোগ্য কোড রয়েছে তবে এর অর্থ এই নয় যে আমরা সমস্ত প্রতিশ্রুতি মাস্টারে নিযুক্ত করি।

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


10
এক বা দু'বছরের জন্য একটি বিকাশকারী শাখার সাথে কাজ করার পরে, এটি এখন এবং পরে প্রতিটি মাস্টার হিসাবে একীভূত হওয়ার জন্য, আমি কেবলই বলতে পারি: আমেন, জিনিসটি ত্যাগ করুন:]
21

মজাদার. সুতরাং আমি ধরে নিয়েছি আপনি উদাহরণস্বরূপ সংস্করণ 1.3 প্রকাশ করার সময়, আপনি একটি নির্দিষ্ট প্রতিশ্রুতি ট্যাগ করেন master, তাই আপনি যদি masterপ্রবাহের অবস্থায় থাকার পরে কোনও বাগ উত্থিত হয়, আপনি খুব সহজেই 1.3 ট্যাগের বাইরে একটি হটফিক্স শাখা করতে পারবেন?
ffxsam

5
আমি বলব যে "বিকাশ" এর সুবিধা আপনি কী ধরণের সফ্টওয়্যার তৈরি করছেন, এটি কীভাবে স্থাপন করা হয়েছে এবং আপনার একাধিক লাইভ সংস্করণ সমর্থন করা দরকার কিনা তা নির্ভর করে depends
axl

1
@ffxsam আমাদের এমনকি ট্যাগিংয়ের দরকার নেই কারণ বর্তমানে কোন গিট আইডি মোতায়েন রয়েছে তা আমরা ট্র্যাক করছি। এটি TeamCity উভয়ই লগইন করা হয়েছে এবং মোতায়েন করা dll এর এবং অ্যাজুরি ম্যানেজমেন্ট পোর্টালে ব্রাঞ্চ করা আছে। সুতরাং আমরা টিমসিটি দ্বারা স্বয়ংক্রিয় ট্যাগিং ব্যতীত আর ট্যাগিংয়ের প্রয়োজনীয়তা অনুভব করি নি। আপনার যদি মনে হয় ট্যাগিং আপনার কাজের প্রবাহকে আরও ভাল করে তোলে তবে এটি এটিকে সুন্দরভাবে সমাধান করবে। তবে হ্যাঁ, নীতিগতভাবে একটি হটফিক্স শাখা তৈরির জন্য বর্তমানে মোতায়েন করা পরিবর্তন থেকে সরাসরি শাখা বন্ধ করুন।
এসবেন স্কোভ পেডারসেন

25

আপনার বিকাশ প্রক্রিয়া জটিল হলে আপনার বিকাশকারী শাখার ক্ষেত্রে আরও গুরুত্ব রয়েছে release

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

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

ওয়েব অ্যাপস বা অন্য সহজে আপডেট হওয়া সফ্টওয়্যারগুলির এই সীমাবদ্ধতা নেই।

তবে, নোট করুন:

  • গিথুবের অনেকগুলি (সর্বাধিক?) প্রকল্পগুলির এই ধরণের বাধা নেই
  • একটি প্রধান "মাস্টার" একই উদ্দেশ্যে কাজ করে
  • "একটি পিআর বনাম মাস্টার করুন" এর একটি ওয়ার্কফ্লো "শাখার বিরুদ্ধে এমন জনসংযোগ তৈরি করুন যা আপনি এই রেপোতে অবিলম্বে জানেন না" এর চেয়ে অনেক বেশি সার্বজনীন is

18

প্রকল্পগুলিতে আমি দুটি দর্শন দেখেছি এবং আমি মনে করি পছন্দটি কেবল স্বাদের বিষয়:

  1. 'মাস্টার' কে উত্পাদন মুক্তির হিসাবে মনোনীত করুন এবং একটি 'বিকাশ' শাখায় বিকাশ করুন।

  2. 'মাস্টার'-এ বিকাশ করুন এবং স্থিতিশীল উত্পাদনের জন্য পৃথক-নামযুক্ত শাখা রাখুন। আপনার প্রকল্পে একসাথে একাধিক রিলিজ শাখা থাকলে এটি আরও বেশি অর্থবোধ করে (উদাঃ, বর্তমানের পছন্দেরটি রিলিজ -১.৮, তবে আপনি এখনও রিলিজ-১.7 বজায় রাখছেন)।

উভয়ই সাধারণ পন্থা এবং তাদের উপকারিতা এবং বিপরীতে রয়েছে।


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

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

7

উত্পাদনের ক্ষেত্রে প্রকাশগুলি ট্যাগ করা যায়, সুতরাং যে পরিস্থিতি প্রকাশ হয়েছিল তা সর্বদা এই উদ্দেশ্যে পুরো শাখাটি ব্যয় না করে পুনরুত্পাদন করা যেতে পারে।

যদি মাস্টার প্রকাশ করা যায় না এমন মুহুর্তে একটি সমালোচনামূলক ত্রুটি উত্পাদনে পাওয়া যায়, তবে ট্যাগ চেকআউট করা এবং সেখান থেকে একটি নতুন "হটফিক্সেস-ফর-রিলিজ -২.২.০" শাখা শুরু করা যথেষ্ট সহজ। তবে তা বরং বিরল হওয়া উচিত।

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


5

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

...

কল্পনা করুন যে লোকেরা সরাসরি মাস্টারের সাথে মিশে যাচ্ছে এবং উত্পাদনে একটি বাগ রিপোর্ট করা হয়েছে যা সমাধান করা কঠিন হয়ে পড়ে কারণ মাস্টার ব্রাঞ্চ কোডবেস উল্লেখযোগ্যভাবে পরিবর্তিত হয়েছে।

এটি গিথুব প্রবাহ নয়।

এটি আপনার লিঙ্ক অনুযায়ী গিথুব প্রবাহকে মোতায়েন / মার্জ প্রক্রিয়া:

স্থাপন করুন

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

একত্রিত করা

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

(জোর আমার)

অন্য কথায়, masterউত্পাদনের আগে হতে হবে না। একইভাবে, masterসর্বদা স্থিতিশীল, পুনরায় প্রেরণযোগ্য অবস্থায় থাকবে (অপরিবর্তিত বাগগুলি বাদে), যেহেতু সবকিছুতে পর্যালোচনা করা হয়, পরীক্ষা করা হয় এবং একত্রীকরণের আগে উত্পাদনে আনা হয় master


নিস! এটি দুর্দান্ত স্বজ্ঞাত জ্ঞান তৈরি করে - masterআপনি উত্পাদনের দিকে ঠেলে দেওয়া বৈশিষ্ট্য শাখাটি যদি ব্যর্থ হয় তবে সর্বদা আপনার রোলব্যাক অবস্থান। যদি এটি না হয় তবে তা এতে মিশে masterযায় এবং নতুন ফ্যালব্যাক হয়ে যায়। আমি এটা পছন্দ করি.
বিল হরভথ

1

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

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

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

আমি বরং গিটহাব প্রবাহটি এর সরলিকৃত নেসের কারণে ব্যবহার করব। বৈশিষ্ট্যের মতো বান্ডিল সহ, আমি মনে করি এটি আরও ভাল প্রস্তুত হবে। আমি সম্ভবত বান্ডিল প্রকাশের অনুরূপ; তবে, আমি এখনও এটি বিবেচনা করছি।

আরেকটি সমস্যা হ'ল মাস্টারে মার্জ হওয়ার আগে টান অনুরোধ প্রক্রিয়াটি শেষ হয়; যাইহোক, কখনও কখনও আপনি ব্যবসার QA পরীক্ষার আগে পর্যালোচনা কোড করতে চান - সুতরাং মার্জ করার আগে ভাল

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