যে প্রকল্পে একাধিক বড় সংস্করণ বজায় রাখা হচ্ছে এমন কোনও প্রকল্পে কীভাবে গিট-ফ্লো ব্যবহার করা যায়?


18

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

বিশেষত, আমি একটি "নিখরচায় সংস্করণ" এবং "প্রদত্ত সংস্করণ" বা অন্য কোনও সমান্তরাল মডেল বজায় রাখছি না, আমি এমন একটি প্রকল্পের কথা বলছি যেখানে সংস্করণ 1 প্রকাশিত হবে এবং ছোটখাটো সংস্করণ (1.1, 1.2 ইত্যাদি) দ্বারা সমর্থিত থাকবে remains ।) সংস্করণ 3 প্রকাশিত হওয়া অবধি, 4 এবং অবধি প্রকাশ না হওয়া অবধি 2 এবং 3 বজায় রাখা হবে ... আপনি ধারণা পাবেন get

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


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

@ প্রডিজিসিম: ডেটা পয়েন্টের জন্য ধন্যবাদ, তবে এটি কি আমি বা এটি ট্র্যাক এবং পরিচালনা করতে নির্দিষ্ট পরিমাণের ওভারহেড যুক্ত করবে?
হেজমেজ

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

@Rin তারা মर्कুরিয়াল ব্যবহার করে use আমি মনে করি না সফ্টওয়্যারটির সমান্তরাল প্রধান সংস্করণগুলি ট্র্যাকিংয়ের ক্ষেত্রে ব্রাঞ্চিং খুব পরিষ্কার হবে clean
ProdigySim

তখন আমার সন্দেহ ছিল সঠিক। এবং হ্যাঁ, আপনার সরঞ্জাম যদি এটি সঠিকভাবে সমর্থন করে তবে এটি বেশ পরিষ্কার। গিট এবং লিনাক্স কার্নেল উভয় এটি এভাবে করে।
রেন হেনরিচস

উত্তর:


10

man gitworkflows, 'গিট ফ্লো' ওয়ার্কফ্লো এর গ্র্যান্ড বাবা, সাধারণ গিট ওয়ার্কফ্লো নির্দেশিকা বর্ণনা করে; ব্যবহারের pu, next, masterএবং maintশাখা; এবং কিভাবে maintপরিচালিত হয়। আপনার যদি একাধিক রক্ষণাবেক্ষণ শাখা থাকে তবে আপনি তাদের নাম রাখতে পারেন, উদাহরণস্বরূপ maint/1.x, maint/2.xএবং আরও অনেক কিছু।

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


কিন্তু এই প্রশ্নের উত্তর দেয়? যথা, গিট-ফ্লো প্রশ্নটিতে বর্ণিত হিসাবে একটি নমনীয় রিলিজ মডেল সমর্থন করে, বা কেউ বেসিক গিট কমান্ডে ফিরে যেতে পারে? ("গিট ওয়ার্কফ্লোস" বেসরকারী গিট ওয়ার্কফ্লো ব্যবহারের বর্ণনা দেয়, প্রাক-গিট-প্রবাহ) গিট-প্রবাহ গিট মার্জ / শাখা প্রক্রিয়াগুলি সহজ করার জন্য তৈরি হয়েছিল (অবশ্যই) দলগুলি (গিট-ফু দক্ষতার বিভিন্ন ডিগ্রী সহ) কোডিং এবং ফোকাস করতে পারে সময়সাপেক্ষ "ভুল সংযোজন" ভুল এড়াতে। V1 গিগাবাইট প্রবাহ বজায় রাখা এবং বিকাশ করা কি সম্ভব? {1,2,3, .. v একই সাথে v2.5 হিসাবে। 1,2,3, ...}? সম্ভবত ডাব্লু / দীর্ঘমেয়াদে মুক্তি শাখা? বা মাস্টার 1, মাস্টার 2, ...?
মাইকেল

0

মূলত, আপনি নকল হবে master, releaseএবং developপ্রতিটি বৃহত সংস্করণ বজায় রাখার জন্য শাখা। তারা কীভাবে একে অপরের সাথে যোগাযোগ করে তা একই থাকে। জন্য featureশাখা, শুধু শাখা করতে ভুলবেন না থেকে প্রাচীনতম শাখা আপনাকে ফেরত একত্রীকরণ মনস্থ মধ্যে , যা অবাঞ্ছিত নির্ভরতা মধ্যে টেনে বাধা দেয়। তারপরে আপনি যখন নিজের featureশাখাটি আবার সংযুক্ত করলেন, আপনি কেবল প্রতিটি উপযুক্ত নতুন প্রধান সংস্করণ শাখায় অতিরিক্ত মার্জ করবেন।


1
প্রতিটি প্রকাশিত সংস্করণ অন্তর্ভুক্ত করার জন্য মাস্টার পুরো পয়েন্ট নয় ?
হেজমেজ

@ হেজজেজ, আরও লিনিয়ার রিলিজ চক্রের ক্ষেত্রে এটি ক্ষেত্রে তবে এটি সমান্তরাল বড় সংস্করণগুলির জন্য অত্যন্ত অযৌক্তিক।
কার্ল বিলেফেল্ট

এটি সর্বাধিক ব্যবহারিক সমাধানের মতো বলে মনে হচ্ছে, যদি না হটফিক্স বা এমন কিছু ব্যবহারের চেষ্টা করা হয় যা আমি অবগত নই। আমি গিট-ফ্লো প্রবর্তনের জন্য একটি উপায় সন্ধান করেছি এবং এখনও (আমাদের দুর্ভাগ্য পূর্বশর্ত হিসাবে) আমাদের বিদ্যমান প্রকাশের মডেল রাখতে সক্ষম হব, যেখানে আমাদের পুরানো প্রকাশগুলি বজায় রাখতে হবে / কেবল হটফিক্সগুলি নয়) develop সুতরাং v5.1.x v6.1.x প্রকাশের কয়েক বছর পরে (ডাব্লু / নতুন বৈশিষ্ট্য যুক্ত, বাগ সংশোধন করা ইত্যাদি) চারদিকে আটকে থাকবে। যে কোনও সময়ে প্রায় 2-3 টি বড় সংস্করণ সমর্থিত এবং বিকাশিত। তবে বাগের সংশোধনগুলি প্রতিটি সংস্করণে প্রয়োগ করা দরকার যেখানে বাগটি বিদ্যমান।
মাইকেল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.