আমি যদি একমাত্র বিকাশকারী হয়ে থাকি তবে নিজের রেপোতে পুল অনুরোধগুলি ব্যবহার করার কোনও উদ্দেশ্য আছে?


38

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

এখন যখন আমি আমার শাখাটি গিটহাবের দিকে ধাক্কা দিই, আমার সেই বিভাগটি রয়েছে যেখানে আমার দুটি বোতাম রয়েছে: Pull Requestএবং Compareসেই শাখার নাম দিয়ে আমি সম্প্রতি ঠেলেছি। আমি Compareবোতামটির উদ্দেশ্য বুঝতে পেরেছি তবে আমি কেন নিজের রেপোতে একটি টানা অনুরোধ তৈরি করতে চাই তা পাই না।

কেউ আমাকে ব্যাখ্যা করতে পারেন আমি কেন এমন করবো? আমি একমাত্র বিকাশকারী হলে নিজের রেপোতে পুল অনুরোধ করা কি কার্যকর?

উত্তর:


28

অনেকগুলি (সম্ভবত বেশিরভাগ) স্বতন্ত্র বিকাশকারীরা তাদের নিজস্বভাবে কাজ করছেন, পুল অনুরোধ তৈরি করা সম্ভবত উপযুক্ত নয়। তবে আমি এটি করার কমপক্ষে একটি সম্ভাব্য কারণ সম্পর্কে ভাবতে পারি:

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

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

আপনি যদি লিনিয়ার কমিটের ইতিহাসকে আটকে রাখার সিদ্ধান্ত নেন (মার্জ করার আগে আপনার বৈশিষ্ট্য শাখাগুলিকে রিব্যাক করে, যাতে মার্জটি সবসময় দ্রুত-অগ্রসর হিসাবে সম্পাদন করা যায়) এবং আপনি যদি সম্পাদনা এবং স্কোয়াশিং সম্পর্কে খুব শৃঙ্খলাবদ্ধ হন তবে এটি কম কার্যকর হতে পারে মাস্টারে মার্জ হওয়ার আগে প্রতিশ্রুতিবদ্ধ, কারণ সেই ক্ষেত্রে স্বতন্ত্র প্রতিশ্রুতি বার্তাগুলি তাদের মধ্যে পরিবর্তন হিসাবে ব্যবহার করা যেতে পারে।


10

টানুন অনুরোধগুলি তৈরি করা হয় যাতে কেউ কাজটি পর্যালোচনা করতে পারে, মন্তব্য করতে পারে, পরামর্শ দিতে পারে, সম্পাদনাগুলি করতে বা অনুরোধ করতে পারে এবং তারপরে কোডটি মাস্টারে মার্জ করতে পারে।

আপনার ক্ষেত্রে কেউ আপনি হয়।

একমাত্র বিকাশকারী হিসাবে আপনার এখনও নিজের কাজটি পর্যালোচনা করা উচিত, এটি রিফ্যাক্টর করা উচিত এবং প্রস্তুত হওয়ার পরে এটি মাস্টারটিতে মার্জ করুন।

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

সুতরাং, আপনি যেমনটি ইঙ্গিত করেছেন, আপনি শাখাগুলিতে কাজ করা উচিত যখন আপনি বৈশিষ্ট্য এবং পরিবর্তনগুলি আলাদা করতে চান যা মাস্টারের জন্য প্রস্তুত নয়। আপনি শাখাগুলিতে এগুলি সব করতে পারেন (আপনি যদি পিআর টাস্কগুলি যাইহোক সম্পাদন করেন তবে এগুলি পরিচালনা করার জন্য আপনার কাছে টানা অনুরোধের দরকার নেই, তবে এটি আপনার জন্য কার্যকর কাঠামো সরবরাহ করতে পারে)।

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

সুতরাং আপনার শাখাগুলিতে কাজ করা উচিত এবং পুরো শাখাকে একীভূত করার সিদ্ধান্ত না নেওয়া পর্যন্ত সরাসরি মাস্টারকে প্রতিশ্রুতিবদ্ধ না করা উচিত

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


3

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

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


আমি একাধিক কম্পিউটার থেকে কাজ করার কারণে আমি ইচ্ছাকৃতভাবে আমার শাখাগুলিকে গিথুবে চাপছি এবং আমি চাই যে আমার কোডগুলি সমস্ত তাদের মধ্যে সিঙ্ক হয়। এটা জেনে কি আপনার উত্তরে কিছু পরিবর্তন হয়?
মার্কো ফিসেট

@ মার্কো ফিসেট এর উত্তর পরিবর্তন করা উচিত নয়। আপনি ঠিক কোনটি অনুরোধের বোতামটি উল্লেখ করছেন তা আমি নিশ্চিত নই ..
ডেভিড কাউডেন

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

0

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


0

আমি এটি করার কারণটি হ'ল সমস্ত স্বয়ংক্রিয় চেকগুলি পাস হওয়ার বিষয়টি নিশ্চিত করার একটি সুবিধাজনক উপায় (এটি সংকলন করে, এতে সঠিক বিন্যাস রয়েছে, ইউনিট পরীক্ষাগুলি পাস হয়েছে ...)।

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

আরও সাধারণভাবে, পরিবর্তনগুলি সম্পূর্ণরূপে হুক সংযোগ করার একটি উপায়। পরীক্ষা একটি উদাহরণ; @ জন অন্যান্য উদাহরণ হিসাবে রিলিজ নোট তৈরির কথা উল্লেখ করেছেন।


-2

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

পুল অনুরোধের মডেল (কাস্টম শাখা বা ব্যক্তিগত সংগ্রহস্থলগুলি থেকে) কোডটি ব্যবহার করে এবং প্রাপ্ত সকলের জন্য সুসংগত ইতিহাস সরবরাহ করার উপায় হিসাবে কাজ করে।

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


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

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