আমি বিভিন্ন সার্ভার থেকে কোড ঘাঁটি আলাদা করার জন্য কীভাবে গিট ব্যবহার শুরু করব?

Question

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

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

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

প্রশ্ন: এগুলি সংগঠিত করার এবং গিটে স্থানান্তর করার আমার পক্ষে সবচেয়ে ভাল উপায় কী হবে? কোডের পার্থক্য সামঞ্জস্য করার জন্য আমি কীভাবে আমার রেপো / শাখাগুলি কাঠামো করব?

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

Comments

সুতরাং আপনি শুরু করার আগে কি সমস্ত বিকাশকারী বাকি আছে?

— ইভান

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

— ব্যবহারকারী9268966

" Nvie.com/posts/a-successful-git-branching-model " এ একবার দেখুন এটি প্রায়শই ব্যবহৃত একটি মডেল।

— প্যাট্রিক মেভেক

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

— প্যাট্রিক মেভেক

@ রবার্টহার্ভি যেমন বলেছিলাম: প্রায়শই ব্যবহৃত হয় , সম্ভবত ব্যবহারের 100% ক্ষেত্রে সমাধান হয় না তবে কোন মডেলটি ব্যবহার করবেন তা সিদ্ধান্ত নেওয়ার আগে এটি পড়ার পক্ষে কমপক্ষে দরকারী। এবং পূর্ববর্তী বিকাশকারীগণ ছিল, সুতরাং একাকী লোকটি সবসময় একা নাও হতে পারে ... :-)

— প্যাট্রিক মেভিজেক

Answer 1

উত্পাদনের masterস্টাফটিকে একটি নতুন রেপোর শাখায় ঠেলাও। developএটি থেকে একটি শাখা তৈরি করুন এবং তারপরে স্টেজিং সার্ভারটি মার্জ করুন। আপনি সংঘাতের সাথে মিলে যেতে পারেন যা সমাধানের প্রয়োজন। ঐ সুরাহা না হয়, আরেকটি তৈরি feature_branchথেকে developএবং তা উন্নয়ন সার্ভার একত্রিত করে। উদ্ভূত যে কোনও দ্বন্দ্ব সমাধান করুন।

এটি আপনাকে 3 টি শাখা রেখে দেয় যা আপনার উত্পাদন, মঞ্চায়ন এবং বিকাশের পরিবেশকে উপস্থাপন করে। উত্পাদন -> master, মঞ্চায়ন -> develop, উন্নয়ন -> feature_branch। সমস্ত বিকাশটি এইভাবে করা হয় feature_branchesএবং কেবল developযখন বৈশিষ্ট্যটি সম্পন্ন হয়, পরীক্ষা করা হয় এবং স্থিতিশীল হয় তখন কেবল শাখায় মিশে যায় । যেহেতু এটি স্থিতিশীল, তাই এটি মঞ্চ হিসাবে ব্যবহার করা যেতে পারে। যখন আপনি প্রকাশের জন্য প্রস্তুত হবেন তখন releaseথেকে একটি শাখা কাটুন develop, কোনও আলগা প্রান্ত বেঁধে দিন, এতে একত্রীকরণ করুন masterএবং তারপরে আপনার নতুন উত্পাদন তৈরি হবে।

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

এই মডেলটিতে, প্রতিটি প্রকল্পের নিজস্ব রেপো থাকবে, এবং সেই রেপোর একটি masterএবং developশাখা থাকবে, feature_branchesকোনও কাজ করার জন্য।

মন্তব্যগুলি সম্বোধন করতে সম্পাদনা করুন: হ্যাঁ, এটি গিটফ্লো।

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

---

* আপনি অন্য কোনও বৈশিষ্ট্য শাখাটি কাটতে এবং যে কোনও সুস্পষ্ট নতুন বৈশিষ্ট্য মুছে ফেলতে এবং সেই শাখাকে develop(এবং তারপরে master) মার্জ করতে চাইতে পারেন । এটি আপনাকে করা সমস্ত অন্যান্য পরীক্ষার উপরে নতুন বৈশিষ্ট্যগুলি পরীক্ষা করা থেকে বিরত রাখে।

Comments

গিটফ্লোয়ের মতো শোনাচ্ছে।

— রবার্ট হার্ভে

এটি কিছুটা কার্গো কাল্ট উত্তর। কীভাবে গিটফ্লো প্রশ্নটিতে বর্ণিত সমস্যা সমাধানে সহায়তা করবে?

— মিঃ কোচিজ

@ মিঃকোচিস আমার সম্পাদনা দেখুন

— মমথিস

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

— user9268966

Answer 2

আমি stagingআপনার প্রাথমিক আমদানির জন্য সেরা বেসলাইন হিসাবে কোডটি সুপারিশ করতে যাচ্ছি । এটা এ কারণে যে সেখানে পরিবর্তন productionযে এতে নেই staging, গরম সংশোধন করা হয়েছে কারণে এ পর্যন্ত কম তাহলে কোনো পরিবর্তন কিন্তু stagingযে হয় না production। একইভাবে সেখানে পরিবর্তন developmentযে হয় না staging, নতুন বৈশিষ্ট্য কারণে যদি কোনো পরিবর্তন, কিন্তু সম্ভবত এ পর্যন্ত কম stagingযে নেই development।

দ্রষ্টব্য, আপনার প্রাথমিক আমদানির পরে আপনি আপনার বেসলাইন হতে চান নাstaging । পূর্বে পরিবর্তনগুলি ট্র্যাক না করার কারণে এটি কেবল সাময়িক পরিস্থিতি is আপনি যদি ব্রাউজগুলি মুছে ফেলার পরিবর্তে পরিবর্তনগুলি যুক্ত করেন তবে শাখার ক্রিয়াকলাপগুলি আরও সহজেই চলে । আপনার প্রাথমিক আমদানির পরে, ব্রাঞ্চিং মডেলটি আপনার প্রয়োজনগুলির পক্ষে সবচেয়ে ভাল এগিয়ে চলেছে to

সুতরাং, আপনার stagingকোডটি একটি stagingশাখায় পরীক্ষা করুন , তারপরে git checkout -b master stagingআপনার masterশাখাটি তৈরি করতে একটি করুন , এবং সেখানে আপনার উত্পাদন কোডটি পরীক্ষা করুন। তারপরে git checkout -b development stagingআপনার developmentশাখা তৈরি করতে একটি করুন , এবং সেখানে আপনার বিকাশ কোডটি পরীক্ষা করুন।

এখন আপনার চেক আউট developmentশাখা ও একত্রীকরণ master মধ্যে এটি। এটি আপনাকে সম্ভবত masterউত্পাদনে আসলে কী রয়েছে তার রেকর্ড হিসাবে বজায় রেখে বিপুল সংখ্যক সংশ্লেষ বিরোধের সমাধান করতে দেবে । developmentএখন প্রতিটি পরিবেশ থেকে সমস্ত পরিবর্তন রয়েছে। ব্রাঞ্চিং মডেল যা আপনার পক্ষে সবচেয়ে উপযুক্ত তা এখন আপনি স্যুইচ করতে পারেন।

Answer 3

ইতিহাস থাকা ভাল ধারণা। আমি সবচেয়ে স্থিতিশীল পরিবেশ থেকে সংগ্রহস্থল (বা প্রতিটি পণ্যের জন্য একটি) তৈরি করব। অন্যদের জন্য শাখা বা পৃথকীকরণ তৈরি করুন।

উচ্চ স্তরে:

1. একটি নতুন রেপো তৈরি করুন
2. উত্পাদন-ভিত্তিক কার্যকরী অনুলিপি থেকে: সমস্ত যুক্ত করুন, প্রতিশ্রুতি দিন এবং চাপ দিন
3. একটি নতুন ডিরেক্টরিতে চেকআউট মাস্টার
4. প্রতিটি অতিরিক্ত পরিবেশের জন্য XYZ
   1. শাখা তৈরি করুন Archive-XYZ
   2. XYZউত্স দিয়ে সবকিছু প্রতিস্থাপন করুন (.git ব্যতীত)
   3. সমস্ত যোগ করুন, প্রতিশ্রুতিবদ্ধ, এবং ধাক্কা

বিকল্পভাবে, যদি আপনি git diff > XYZ.diffসত্যিকারের প্রতিশ্রুতিবদ্ধ এবং চাপ দেওয়ার পরিবর্তে এর মান সম্পর্কে সন্দেহবাদী হন এবং পার্থক্যটি সংরক্ষণাগারভুক্ত করেন।

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