ছোট দেব দলের জন্য গিট শাখা কৌশল [বন্ধ]


186

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

কারও কি ছোট দলগুলির জন্য প্রিয় গিট শাখা কৌশল রয়েছে যা নিম্নলিখিত প্রয়োজনীয়তাগুলি পূরণ করে:

  1. 2 থেকে 3 বিকাশকারীদের দলের জন্য ভাল কাজ করে
  2. লাইটওয়েট, এবং খুব বেশি প্রক্রিয়া নয়
  3. ডেভগুলিকে সহজেই বাগ ফিক্স এবং বৃহত্তর বৈশিষ্ট্যগুলির কাজ আলাদা করতে দেয়
  4. আমাদের একটি স্থিতিশীল শাখা রাখতে অনুমতি দেয় (যখন আমরা আমাদের প্রোডাকশন সার্ভারগুলি কাজ করতে হয় তখন তাদের 'ওহ ক্রপ' মুহুর্তগুলির জন্য)

আদর্শভাবে, আমি কোনও নতুন বাগে কাজ করা কোনও দেবের জন্য আপনার ধাপে ধাপে প্রক্রিয়াটি দেখতে পছন্দ করব

উত্তর:


247

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

মাস্টার আপনার প্রকল্পের সবচেয়ে স্থিতিশীল সংস্করণ উপস্থাপন করে এবং আপনি কেবল কখনও এই শাখা থেকে উত্পাদনে নিযুক্ত করেন।

বিকাশে এমন পরিবর্তনগুলি রয়েছে যা প্রগতিতে রয়েছে এবং সম্ভবত উত্পাদনের জন্য প্রস্তুত নাও হতে পারে।

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

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

ধাপে ধাপে, এই মডেলটির অধীনে আপনার কার্যপ্রবাহটি দেখতে দেখতে এটি দেখতে পারা যেতে পারে:

  1. আপনার একটি বাগ ঠিক করতে হবে।
  2. একটি শাখা নামক তৈরি করুন myfix যে উপর ভিত্তি করে তৈরি বিকাশ শাখা।
  3. এটি ঠিক না হওয়া অবধি এই বিষয় শাখায় বাগটিতে কাজ করুন।
  4. মার্জ myfix মধ্যে বিকাশ । পরীক্ষা চালান।
  5. আপনি অন্য স্থির শাখার হিফিক্সের সাথে আপনার স্থির বিবাদগুলি আবিষ্কার করেছেন যা আপনার সহকর্মী আপনার ফিক্সে কাজ করার সময় বিকাশে মিশে গিয়েছিলেন ।
  6. এই দ্বন্দ্ব মোকাবেলায় মাইফিক্স শাখায় আরও পরিবর্তন করুন changes
  7. মাইফিক্সকে আবার বিকাশ ও চালনার জন্য মার্জ করুন ।
  8. সবকিছু ঠিকঠাক কাজ করে। মার্জ বিকাশ মধ্যে মাস্টার
  9. যে কোনও সময় মাস্টার থেকে উত্পাদনে নিযুক্ত করুন , কারণ আপনি জানেন যে এটি স্থিতিশীল।

এই কর্মপ্রবাহ সম্পর্কে আরও তথ্যের জন্য প্রো গিতে ব্রাঞ্চিং ওয়ার্কফ্লো অধ্যায়টি দেখুন।


7
এছাড়াও স্কট চকন
প্রোগ্রাম 247365

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

5
যদি আমরা 2 টি পৃথক বৈশিষ্ট্য বিকাশ করি, এফ 1 এবং এফ 2, যেখানে এফ 1 এক সপ্তাহে প্রকাশিত হয় তবে এফ 2 এবং এফ 2 এর বিকাশ মিলে যায় বলে ধরে নিয়ে 2 সপ্তাহের মধ্যে এফ 2 প্রকাশ করা হয়? এ বিষয়ে কোনও পরামর্শ?
মুরাত দেরিয়া Özen

4
developএকটি unecessary একটি সমস্যা করতে 'সমাধান' Git নেই যে। যতদূর আমি বলতে পারি সাফল্যটি কোনও ভাল লেখার কারণে, যদি কোনও মন্তব্য না করার অনুমতি দেওয়া হয় gu এখানে একটি প্রতি-নিবন্ধ বারো.github.io/2016/02/…
টিম আবেল

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

45

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

গত 6 মাসে আমাকে কেবল দুবার দ্বন্দ্ব সংশোধন করতে হয়েছে। বৈশিষ্ট্যগুলি বিকাশকালে আমি সর্বদা মার্জ হওয়ার পরে পরীক্ষার জন্য এবং 'আনতে এবং একত্রীকরণ' বা 'টান - রিয়েজবেস "প্রচুর (একবার সকালে এবং বিকেলে) পরীক্ষা করার পদক্ষেপগুলি যুক্ত করেছি। আমরা সর্বশেষতম কোডটি টানতে কেন্দ্রীয় স্থান হিসাবে github.com ব্যবহার করেছি।


এটি একটি দুর্দান্ত লিঙ্ক! সেই ওয়ার্কফ্লোটি আমাদের ছোট দলের জন্য দুর্দান্তভাবে কাজ করে যারা একসাথে সবসময় রিলিজ এবং সমান্তরালভাবে একাধিক রিলিজ সংস্করণে কাজ করে। খুব ভাল নথিভুক্ত। ধন্যবাদ ক্লাচ!
keithxm23

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

4
আমি যখনই দেখি যে কেউ এই ব্লগ পোস্টটি তুলছে তখন আমি ভিতরেই কিছুটা মারা যাই। এখানে একটি প্রত্যাখ্যান
টিম আবেল

আমি আপনার সাথে একই অনুভূতি শেয়ার করছি @ টিমএবেল; আমি দৃ strongly়ভাবে এটি সঠিকভাবে অনুভব করি যখন এটির default master branchমধ্যে প্রায়শই প্রায়শই বিকাশকারী হিসাবে ব্যবহৃত হয় নাA successful Git branching model
নম জি ভি ইউ

35

(আমার মন্তব্য উপরে এটির নিজের উত্তর তৈরি করুন, যেমনটি আমার প্রথম দিকে হওয়া উচিত ছিল))

গিথুবের স্কট চকন থেকে:

আমরা কীভাবে এটি করি, গিটহাব ফ্লো কী?

  • মাস্টার শাখায় যে কোনও কিছুই শৃঙ্খলাবদ্ধ
  • নতুন কিছু নিয়ে কাজ করার জন্য, মাস্টার ছাড়াই বর্ণনামূলকভাবে নামকরণ করা শাখা তৈরি করুন (যেমন: নতুন-ওউথ 2-স্কোপস)
  • স্থানীয়ভাবে সেই শাখায় প্রতিশ্রুতিবদ্ধ এবং নিয়মিত আপনার কাজটি সার্ভারের একই নামী শাখায় চাপ দিন
  • যখন আপনার প্রতিক্রিয়া বা সহায়তা দরকার হয় বা আপনি মনে করেন যে শাখাটি মার্জ করার জন্য প্রস্তুত, একটি টানার অনুরোধটি খুলুন
  • অন্য কেউ বৈশিষ্ট্যটি পর্যালোচনা ও সাইন ইন করার পরে, আপনি এটিকে মাস্টার হিসাবে মার্জ করতে পারেন
  • এটি একবারে একীভূত হয়ে 'মাস্টার' এ ঠেলে দেওয়ার পরে আপনি তাৎক্ষণিকভাবে মোতায়েন করতে এবং করতে পারেন

আরও বিশদের জন্য পুরো নিবন্ধটি দেখুন: http://scottchacon.com/2011/08/31/github-flow.html

নোট করুন যে "পুল অনুরোধগুলি" একটি গিথুব আবিষ্কার, এবং এটি এমন কিছু যা তাদের ওয়েবসাইটে বেকড, গিট নিজেই নয়: https://help.github.com/articles/used-pull-requests/


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

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

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

15

masterআপনার উন্নয়ন শাখা হিসাবে শাখাটি ব্যবহার করুন এবং বাগ ফিক্সগুলি সম্পাদনের জন্য মুক্ত শাখা তৈরি করুন।

masterবিকাশ উইন্ডো চলাকালীন যে কোনও নতুন বৈশিষ্ট্য চলতে থাকবে (হয় প্রত্যক্ষভাবে প্রতিশ্রুতিবদ্ধ বা টান-অনুরোধ সহ টপিক শাখা হিসাবে, আপনার উপর - গ্রাফিকে দেখানো হয়নি)। আপনার সমস্ত পরিকল্পিত বৈশিষ্ট্যগুলি কার্যকর হয়ে গেলে, বৈশিষ্ট্য হিমায়িত প্রবেশ করুন এবং পরীক্ষা করুন। আপনি যখন খুশি হন, masterতেমন রিলিজটিকে ট্যাগ করুন v1.0

সময়ের সাথে সাথে আপনার ব্যবহারকারীরা বাগগুলি খুঁজে পাবেন v1.0যাতে আপনি tag ট্যাগটি থেকে একটি শাখা তৈরি করতে চান (যেমন মুক্তির পরে নাম দিন 1.0) এবং শাখায় এই বাগগুলি ঠিক করতে চান। যখন আপনি পর্যাপ্ত ত্রুটিগুলি ঠিক করে ফেলেছেন যে আপনি মনে করেন এটি একটি নতুন রিলিজের আদেশ দেয় তখন এটিকে ট্যাগ v1.0.1করে আবার এতে মেশান master

ইতোমধ্যে masterশাখায় একটি নতুন বিকাশ উইন্ডো ঘটতে পারে যা শেষ পর্যন্ত হিসাবে ট্যাগ হবে v1.1

ধুয়ে ফেলুন এবং পুনরাবৃত্তি করুন।

এটি সিমেন্টিক ভার্সিং সংখ্যার যুক্তি অনুসরণ করে ।

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

5
আপনার 1.0.1পরিবর্তনগুলিতে আবার মার্জ করতে ভুলবেন নাmaster
kwahn

এবং 1.1মার্জ হওয়ার পরে সর্বদা মাস্টারকে রিবেস করার বিষয়টি মনে রাখবেন 1.0.1- এটি বিবাদ হ্রাস করতে সহায়তা করে।
নাম জি ভিউ

@ নামজিভিউ আমি এটির পরামর্শ দেব না। 1.1একটি রিলিজ শাখা এবং এতে এক বা একাধিক রিলিজের সঠিক অবস্থার প্রতিনিধিত্বকারী ট্যাগ রয়েছে। এই শাখাটি মুক্তি দিলে আপনি সেই প্রতিনিধিত্ব হারাবেন। এটিকে প্রতিরোধ করার জন্য জোর ধাক্কা দিতে অস্বীকার করার জন্য আমি আপনার মুক্তির শাখাগুলি দৃ setting়তার সাথে প্রস্তাব করব recommend
লাইফ গ্রুইনওয়েল্ট

1
না। রিলিজ শাখাগুলি আবার মাস্টার হিসাবে মার্জ না! এটি আপনাকে যে সমস্ত ধরণের মাথাব্যথার দরকার নেই তা দিতে পারে (কেবলমাত্র রিলিজ-স্টাফগুলিতে মার্জ করা, নতুন রিলিজের সাথে দ্বন্দ্বগুলি মার্জ করে, ভেঙে ফেলা, অ-লিনিয়ার ইতিহাস ইত্যাদি me বিশ্বাস করুন, আমি এটি একাধিকবার ঘটতে দেখেছি) । পরিবর্তে, রিলিজকে কাঁটাচামচ হিসাবে গণ্য করুন। দেখুন bitsnbites.eu/a-stable-mainline-branching-model-for-git
M-bitsnbites

4
মাস্টার হিসাবে রিলিজ পরিবর্তনগুলি পুনরুদ্ধারের জন্য চেরি-পিক একটি ভাল বিকল্প
বার্তোসকেপিপি

4

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

তবে ডিভিসিএসে ("বিকেন্দ্রিত" ভিসিএসের মতো) আপনারও একটি প্রকাশনার ইস্যু রয়েছে , যে শাখাগুলি আপনি আপনার ভাণ্ডারগুলিতে স্থানীয় রাখেন এবং যে শাখাগুলিতে আপনি চাপ দিচ্ছেন বা সেখান থেকে টানছেন with

এই প্রসঙ্গে, আপনার একযোগে উন্নয়নের প্রচেষ্টা চিহ্নিত করে শুরু করুন এবং একটি প্রকাশনা (ধাক্কা / টান) প্রক্রিয়া সম্পর্কে সিদ্ধান্ত নিন। উদাহরণস্বরূপ (এবং এটি একমাত্র উপায় নয়):

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

অন্যান্য রিলিজ ম্যানেজমেন্ট প্রক্রিয়া উপস্থিত রয়েছে, যেমন এই প্রশ্নটি সত্যায়িত হয়


3

রিইনএইচ এর চিত্তাকর্ষক দলগুলির জন্য গিট ওয়ার্কফ্লো মাধ্যমে এখানে পড়ুন: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

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

দ্রষ্টব্য: এই কৌশলটি খুব কমই গিট নির্দিষ্ট, তবে গিট এই কৌশলটি কার্যকর করা সহজ করে তোলে।

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