নতুন বিকাশকারী শাখা মার্জ করে রাখতে পারেন না

Question

আমি নতুন বিকাশকারী - এটি আমার প্রথম প্রোগ্রামিং অবস্থান।

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

আমি কীভাবে এটিকে কাটিয়ে উঠতে পারি? 'কোডিংয়ে ভাল থাকুন' ব্যতীত আমি অন্য কোন কৌশলটি ব্যবহার করতে পারি? আমি পরের সপ্তাহে আমার সুপারভাইজারের সাথে এটি আনতে চাইছি।

Comments

আপনার শাখাটি কেবল তখনই শেষ করতে হবে যখন আপনি শেষ করেন develop আপনি যখনই চান চূড়ান্ত মার্জটি আরও ছোট করতে আপনার বৈশিষ্ট্য শাখায় ক্রমবর্ধমান মার্জ করতে পারেন।

— ডেভিডবি

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

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

এখানে একটি অদ্ভুত জিনিস রয়েছে "আমি ছোটখাট কাজ নিয়ে কাজ শুরু করি" এবং একত্রে সংশ্লেষের প্রচুর সংঘাত সাধারণত মেলে না। আমি মাত্র একটি 2 সপ্তাহের প্রধান আপডেট শাখাকে একটি পরীক্ষামূলক বিকাশে মিশিয়ে দিয়েছি এবং আমাদের 10 (!) সংঘাত রয়েছে যা স্বয়ংক্রিয়-সমাধানযোগ্য নয়। আপনার টাস্কটি "সমস্ত ফাইলের পরিবর্তে ভেরিয়েবলের নাম পরিবর্তন করুন" না হলে আপনি প্রচুর সংঘাতের মুখোমুখি হবেন না। মাইনর কাজের জন্য নয়।

— টমটম

বাধ্যতামূলক xkcd: xkcd.com/1597

— ED

Answer 1

আপনি যদি আপনার শাখায় যে পরিবর্তনগুলি করেছিলেন সেগুলি আপনার সহকর্মীরা এই developশাখায় যে পরিবর্তনগুলি করেছিল সেই সময়ে যদি আপনি এবং আপনার সহকর্মীরা একই ফাইলের একই কোড বা সংলগ্ন লাইনগুলি পরিবর্তন করেন তবে আপনি মার্জ সংঘাত পেতে পারেন।

সুতরাং মার্জ সংঘাতের সম্ভাবনা হ্রাস করতে, আপনি আগে মার্জ করার চেষ্টা করতে পারেন যাতে আপনার সহকর্মীরা এরই মধ্যে কম লাইন পরিবর্তন করেছিলেন বা আপনি নিজেই কম লাইন পরিবর্তন করার চেষ্টা করতে পারেন।

নিজেকে কম লাইন পরিবর্তন করতে, কেবলমাত্র আপনার টাস্কের সাথে সম্পর্কিত পরিবর্তনগুলি নিশ্চিত করে নিন।

আপনার লক্ষ্য অর্জনের জন্য যদি আপনাকে বিভিন্ন উপায়ে পরীক্ষা করার দরকার হয়, তবে আপনার কিছু পরীক্ষা-নিরীক্ষার লাইন বদলেছে যা সত্যিই পরিবর্তন করার দরকার নেই? মার্জ হওয়ার আগে এই পরিবর্তনগুলি পূর্বাবস্থায় ফেরান।

এছাড়াও কিছু গিট কমান্ড রয়েছে যা আপনাকে যতটা সম্ভব কম লাইন পরিবর্তন করতে সহায়তা করতে পারে:

• git diffএবং git diff --stagedআপনি কোন রেখা পরিবর্তন করেছেন তা দেখতে।
• git add -p আপনার ফাইলের কিছু পরিবর্তন যুক্ত করতে।
• git commit --amendএবং git rebase -iঅন্যান্য গিট সংগ্রহস্থলগুলিতে ঠেলাঠেলি করার আগে আপনি ইতিমধ্যে আপনার স্থানীয় বৈশিষ্ট্য শাখায় তৈরি কমিটগুলি টুইঙ্ক করতে।

(যতটা সম্ভব কয়েক লাইন পরিবর্তন এছাড়াও সহজে আপনার কাজ পর্যালোচনা করতে বা সরঞ্জামগুলি আমাদের কাছে যেমন পার্থক্য কাজ মধ্যে করে ব্যবহার করতে করতে পারেন git cherry-pick, git rebase, git bisect, এবং git blame।)

তবে আপনি মার্জ সংঘাতের সম্ভাবনা হ্রাস করলেও আপনি এখনও কখনও কখনও মার্জ সংঘাতের মধ্যে চলে যাবেন। সুতরাং তাদের থেকে ভয় পাবেন না, তবে দ্বন্দ্বগুলি কীভাবে সমাধান করবেন তা শিখুন।

Comments

মার্জ করার আগেও, এ git fetchএবং git diff origin/developআপনাকে আপনার মার্জ (সাজানোর) পূর্বরূপ দেখায়। আপনি এক টন অর্থহীন দ্বন্দ্ব নেওয়ার আগে আপনাকে আপনার পরিবর্তনগুলি পরিষ্কার করার সুযোগ দেয়।

— সর্বোচ্চ

Answer 2

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

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

আমি মোটামুটি অভিজ্ঞ বিকাশকারী এবং নতুন প্রকল্পে গতি পেতে আমার এখনও বেশ কিছুটা সময় নেয়। আপনার ক্ষেত্রে এটির মতো শোনা যাচ্ছে যে একই প্রকল্পে আপনার একাধিক লোক একই সাথে কাজ করছে, সুতরাং এটি হয় খুব বড় একটি প্রকল্প, বা একটি নতুন প্রকল্প যা দ্রুত বিকশিত হচ্ছে। উভয় ক্ষেত্রেই যদি আপনার প্রবাহে যেতে কয়েক মাস সময় লাগে তবে চিন্তিত হবেন না । আমি যদি 2 বা 3 সপ্তাহের জন্য প্রকল্পগুলি স্যুইচ করি এবং তারপরে আবার স্যুইচ করি তবে আমি নিজে নিজে 100% লিখেছি এমন একটি প্রকল্প পুরোপুরি "ফিরতে" পেতে কয়েক ঘন্টা (বা এমনকি এক-দু'দিন) সময় লাগতে পারে!

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

সম্পাদনা করুন:

বা ব্যবহার merge। এটিও একটি বিকল্প। সুতরাং, উপরেরটি হ'ল : " git rebase -i(এর -iঅর্থ ইন্টারেক্টিভ) ব্যবহার করুন git merge" বা । কোনটি ব্যবহার করবেন তা আপনার দলের সাথে বাকী অংশ নিয়ে আলাপ করুন। তাদের উভয়ভাবেই (বা নাও) দৃ preferences় পছন্দ থাকতে পারে। এটা স্পষ্ট কিছু ভাবেন না শক্তিশালী পছন্দ আছে।

Comments

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

— user949300

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

— ভেক্টরজহান

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

— পিঁপড়া পি

@ ব্যবহারকারী949300 git pullযা কেবল একটি সংমিশ্রণ git fetchএবং git merge(বা আপনি --rebaseমার্জ করার পরিবর্তে একটি রিবেস করতে যোগ করতে পারেন)। ধরে নিই যে আপনি কেবল একদিনের পিছনে রয়েছেন, তবে ল্যানে এটি সম্ভবত দ্বিতীয় সেকেন্ডেরও কম সময়ে সম্পন্ন হবে, ইন্টারনেটে কয়েক সেকেন্ড সময় লাগতে পারে। এমনকি ইন্টারনেটে এবং সামান্য মার্জ সংঘাতের সাথেও আপনি সাধারণত আপ-টু-ডেট হতে পারেন এবং এক মিনিটেরও কম সময়ে পরিষ্কারভাবে মার্জ করতে পারেন। পুরো সপ্তাহে পাঁচ মিনিট ছড়িয়ে পড়া ব্যয়সাধ্য একত্রীকরণ বিরোধের সাথে মোকাবিলা করে সপ্তাহের শেষে এক ঘন্টা ব্যয় করা অনেক ভাল।

— ডেরেক এলকিন্স

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

— কাস্টার

Answer 3

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

Comments

আপনি উল্লিখিত হিসাবে এটি 101 টি কোডিং করছে। অগত্যা নতুন কর্মচারীর উপর একটি সঠিক প্রতিবিম্ব।

— মিস্টার ইতিবাচক

@ ইভান আনাতোলিভিচ ওপি বলেছেন যে তারা এফवायআইআই নয়, বিকাশ বন্ধ করে দিয়েছে

— ম্যাথু ফিৎসগেরাল্ড-চেম্বারলাইন

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

— মোটোড্রিজ্ট

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

— অ্যাকুইটাস

@motoDrizzt কি? কাউকে কখনও এই যুক্তি দিতে শুনিনি।

— jpmc26

Answer 4

আমি যে গ্রহণযোগ্য উত্তরগুলি মনে করি তা প্রযুক্তিগত "গিটকে কীভাবে আরও ভালভাবে ব্যবহার করতে হবে" তার বেশি, আমি মনে করি এটি ইঞ্জিনিয়ারিং বা টুলিংয়ের সমস্যার চেয়ে একটি দলের সমস্যা।

যদি আপনি অনেকগুলি মার্জ সংঘাতের মুখোমুখি হন তবে এর অর্থ হ'ল আপনি এবং দলের অন্য কেউ একে অপরের পায়ের আঙ্গুলের উপর পা রেখেছেন।
কোডিং করার সময় আপনার বা তাদের ব্যক্তিগত জায়গার বিকাশ করা এবং ইতিমধ্যে ব্যস্ত অঞ্চলে কাজ করা এড়ানো উচিত।

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

যদি আপনি সন্ধান করছেন যে আপনাকে একেবারে একত্রীকরণ করতে হবে তবে হয় আপনার সমস্ত দলের কোড এক জায়গায় (যা নিজেই এড়াতে পারে) বা আপনার সমস্ত কাজ।

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

Comments

আমার মনে হয় আপনি সহকর্মীর দ্বন্দ্ব নিয়ে মাথায় পেরেকটি আঘাত করেছেন। সংঘাত বিবাদগুলি একটি নিয়মিত জিনিস তবে এগুলি সাধারণত কয়েকটি মুঠো ফাইলের মধ্যেই সীমাবদ্ধ থাকে।

— ম্যাথিউ মিঃ

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

— ক্রিসডাব্লু

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

— ডেরেক এলকিন্স

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

— রোয়ান

@ রোয়ান কুল হ্যাঁ আমি এতটা ভেবেছি। কার্যকারিতা বিচ্ছিন্নতা ফাইল পৃথককরণ (বিভিন্ন ফাইলের ফাংশনগুলির সেট ইত্যাদি) সহ সহায়তা করতে পারে এবং এই আইএমও মার্জ করার ক্ষেত্রে সহায়তা করে।

— সালটিসুব 2

Answer 5

মার্জ করার সবচেয়ে গুরুত্বপূর্ণ বিষয় হ'ল আপনি যত বেশি সময় অপেক্ষা করবেন তত বেশি বেদনাদায়ক হয়ে উঠবে। এবং সমস্যা লিনিয়ারের চেয়ে আরও বেড়ে যায়। তিনবার বহু দ্বন্দ্ব নয় গুন বেশি কাজ times কিছু কৌশল আছে:

যখনই এটি পরিবর্তন হয় বিকাশ শাখায় মার্জ করুন, তাই আপনি সর্বদা এর নিকটে থাকুন এবং কখনও বিপুল সংখ্যক দ্বন্দ্ব নেবেন না।

আপনি যদি দীর্ঘ সময় নেন, তবে এটি হতে পারে কারণ আপনি বেশিরভাগ সময় পরিবর্তনগুলি কী তা নির্ণয় করে এবং তারপরে পরিবর্তনগুলি কার্যকর করতে অল্প পরিমাণ সময় ব্যয় করে। যদি এটি হয় তবে আপনি প্রকৃত কোড পরিবর্তন শুরু করার আগে বিকাশ শাখায় একত্রী হন।

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

যদি আপনি দ্বন্দ্ব আছে, তাই আপনি মার্জ আপনার মূল কোড, এবং মার্জ কোড করার আগে আপনার কোড আপনার একত্রীকরণ সামনে বিকাশ শাখা তুলনা করতে পারবেন, একটি ভাল পরিবর্তন টুল পেতে, এবং হাত দ্বারা একত্রিত করে।

সবচেয়ে খারাপ ঘটনা: আপনি নিজের কাজটি ফেলে দেবেন না, তবে ঠিক কী পরিবর্তন করেছেন তা খুঁজে বের করার জন্য একটি ভাল ডিফ সরঞ্জাম ব্যবহার করুন, আবার বিকাশ থেকে শাখা করুন এবং পুনরায় টাইপ করার পরিবর্তে ম্যানুয়ালি আপনার করা সমস্ত পরিবর্তন প্রয়োগ করুন।

Comments

বৈশিষ্ট্য শাখাগুলি প্রযুক্তি debtণের অন্য রূপের মতো নিজেকে উপস্থাপন করে, যেখানে প্যারেন্ট শাখা থেকে আপ-স্ট্রিমিং পরিবর্তনগুলি রিফ্যাক্টরিংয়ের মতো।

— ড্যান লিয়ন্স

যে ছাড়া আপনি আছে যে ঋণ পরিশোধ করতে। এখনই।

— gnasher729

Answer 6

সময় দ্বারা আমি করতে প্রস্তুত আছি একত্রীকরণ আমার শাখা ফিরে বিকাশ (জোর খনি)

দ্বন্দ্বগুলি হ্যান্ডেল git mergeকরা প্রায়শই এর চেয়ে সহজ git rebase। গিট মার্জে আপনি একবারে সংশোধন করা ফাইলগুলির পুরো তালিকা দেখতে পাবেন। অন্যান্য সহকর্মীরা কতটা কমিট করেছেন তা বিবেচনা না করেই আপনাকে একবারে মার্জ করতে হবে । পুনর্বাসনের কর্মপ্রবাহের সাহায্যে আপনি একই দ্বন্দ্ব বার বার পেতে পারেন এবং সেগুলি ম্যানুয়ালি পর্যালোচনা করতে হবে। আপনি 13 তম প্রতিশ্রুতি ফিক্সিং শেষ করতে পারেন এবং আপনি টানেলের বাইরে আলো দেখতে পাচ্ছেন না এমন মনে করতে পারেন ।

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

আমি আপনাকে কয়েকটি কৌশল প্রস্তাব করতে যাচ্ছি তবে তারা কেবলমাত্র কাজটি স্বয়ংক্রিয় করার চেয়ে মার্জটিকে আরও সহজতর করতে সহায়তা করতে পারে।

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

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

@ জ্যাকবববিন্স git rebaseএকটি নিত্যদিনের কাজ করার পরামর্শ দেয় । আমি তার পদ্ধতির এগিয়ে যেতে চাই।

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

নির্দিষ্ট কাজের বিষয়ে আপনার যদি অতিরিক্ত প্রশ্ন থাকে তবে নির্দ্বিধায় অনুসন্ধান এবং স্ট্যাকওভারফ্লোতে জিজ্ঞাসা করুন।

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

সর্বোপরি, বালক স্কাউট নিয়ম আপনাকে অন্য লোকের জগাখিচুড়ি পরিষ্কার করার আদেশ দেয় না। শুধু আপনার.

Comments

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

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

পুনরায় ফর্ম্যাট করার বিষয়ে, যদিও ভিএস সংরক্ষণের সময় এটি স্বয়ংক্রিয়ভাবে করতে পারে না, আপনি যদি "সরঞ্জামগুলি" -> "বিকল্পসমূহ" -> "পাঠ্য সম্পাদক" -> "< আপনার পছন্দের ভাষা> "->" ফর্ম্যাটিং ", এর অর্থ এটি পেস্টে অটো ফর্ম্যাট। এটি তিনটি কীস্ট্রোকের ক্রমকে অনুমতি দেয়: সিআরটিএল-এ, সিআরটিএল-সি, সিটিআরটিএল-ভি পছন্দসই ফলাফল পেতে। তাই বলা হয়, + 1- করে. না. একেবারে। পুনঃবিন্যাস। আপনি খুব সাবধানে নিয়ন্ত্রিত অবস্থার অধীন রূপরেখা ব্যতীত।

— dgnuff

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

— jrh

আপনি কোডটি পুনরায় ফর্ম্যাট করার বা হালকাভাবে রিফ্যাক্টর করার প্রয়োজন মনে করেন, এটি আপনার অর্থবহ অঙ্গীকারের আগে বা পরে করুন। এটি কেবল দ্বন্দ্ব হ্রাস করবে না,

— তবুও

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

— শ্বেত স্পেসগুলিকে

Answer 7

প্রথমত, আপনার পরিবর্তনগুলি বাতিল করার বিষয়ে চিন্তা করবেন না। আপনি মার্জ প্রক্রিয়া শিখার সুযোগ হারাবেন।

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

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

এবং ভবিষ্যতে এড়ানোর জন্য,

• আপনার বৈশিষ্ট্য শাখায় নিয়মিত বিকাশকারী শাখাকে মার্জ করা খুব ভাল অনুশীলন।

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

Comments

+1 গিটকে আরও ভাল ব্যবহারের জন্য অন্যান্য পরামর্শগুলি ভাল, তবে বাস্তবে সংযোজিত বিরোধগুলি সম্পর্কে অন্যান্য বিকাশকারীদের সাথে কথা বলা ওপির কার্যকারিতা বিকাশের আরেকটি মূল দিক।

— ড্রাগনেল

"আপনি ইতিহাস দেখতে পারেন" হতে পারে! কীভাবে স্কোয়াশড এবং রিবেসড সমস্ত কিছু নির্ভর করে: পি

— অরবিটে

Answer 8

আপনার বিকাশ শাখা থেকে আপনার নিয়মিত (দৈনিক) কমান্ড 'গিট ফেচ' (গিট টান নয়) চালানো উচিত। এটি অন্যান্য ব্যক্তিদের প্রতিশ্রুতিবদ্ধ পরিবর্তনগুলি পাবে এবং আপনার শাখায় পরিবর্তনগুলি সংহত করার চেষ্টা না করে এগুলিকে আপনার বৈশিষ্ট্য শাখায় আনবে।

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

Comments

আমি নিশ্চিত না যে এটি সঠিক কিনা। গিট ফেচটি আপ টু ডেট রিমোটস / উত্স / মাস্টার পাবেন তবে আপনাকে তারপরে আপনার বৈশিষ্ট্য শাখায় রিমোটস / উত্স / মাস্টারকে একীভূত করতে হবে (বা রিমোটস / উত্স / বিকাশ যদি তারা যে প্রবাহটি ব্যবহার করছে তবে)

— রিচার্ড টিংল

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

@ রিচার্ডটিঙ্গেল সঠিক, তিনি পুনর্বাসনের বিকল্পের কথা ভাবছেন। আপনি কেবল নিজের শাখাটি দেব শাখার সাথে আনতে এবং পুনরায় চালু করতে পারেন। এটি সবকিছু সিঙ্ক আপ করবে।

@ ড্যান আমি মনে করি এটি মতামতের বিষয় হতে পারে। ব্যক্তিগতভাবে আমি প্রচুর ঘৃণা ঘৃণা করি। গিট দ্বিখণ্ডিত করার চেষ্টা করুন!

— রিচার্ড টিংল

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

— জেসন গোয়েম্যাট

Answer 9

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

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

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

Answer 10

আমি যখন আমার শাখাটিকে আবার বিকাশে রূপান্তরিত করতে প্রস্তুত তখন বাকীগুলি এতগুলি পরিবর্তন এনেছে যে বিরোধগুলি সমাধান করা অপ্রতিরোধ্য

এটি জোড় প্রোগ্রামিংয়ের জন্য আদর্শ দৃশ্যের মতো শোনাচ্ছে !

সুবিধাগুলি এবং প্রাথমিক পদ্ধতির সম্পর্কে আরও তথ্য:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-psps/

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

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

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

একটি দ্রুত, আরও অভিজ্ঞ দেবের সাথে বসে সাহায্য করার সম্ভাবনা রয়েছে:

• সম্ভবত অভিজ্ঞ কারো সাথে কাজ করা আপনার একাকী কাজের বিপরীতে সমাপ্তির সময় বাড়িয়ে দেবে বলে মার্জ সংঘাতগুলি সম্ভবত হ্রাস করবে
• যেহেতু তারা আপনাকে শেখাবেন এটি সম্ভবত তারা একা কাজ করার চেয়ে ধীর হবে, তাই এখনও কিছু সংহত বিবাদ হতে পারে এবং তাই তাদের মাধ্যমে পাকা কারও সাথে কাজ করতে পারে এবং তাই সময় সাশ্রয় করার জন্য কিছু টিপস গ্রহণ করতে পারে ইত্যাদি
• আপনাকে সম্ভাব্য কৌশলগুলি এবং দ্রুততর করার উপায়গুলি দেখতে সহায়তা করে (যদিও ধীর হয়ে যাওয়া কখনও কখনও ভাল অনুশীলনের অভাবের চেয়ে অভিজ্ঞতার অভাব মাত্রই হয়)
• যখন কোনও কিছু বোধগম্য হয় না বা 100% পরিষ্কার হয় না তখন সঙ্গে সঙ্গে প্রশ্নগুলি জিজ্ঞাসা করতে পারে
• 1: 1 কাজ করা শেখার জন্য মূল্যবান কারণ আপনি যে ব্যক্তির কাছ থেকে সহায়তা চাইবেন সে সম্পর্কে সঠিক কোড এবং দৃশ্যের বিষয়টি তারা কাজ করছে বলে আগে থেকেই বুঝতে পারে, জোড় প্রোগ্রামিং ছাড়াই আপনাকে কোড এবং দৃশ্যের ব্যাখ্যা দিতে হবে, যা প্রায়শই একটি সমস্যা শেষ করে এবং সুতরাং আপনি আসলে প্রয়োজনীয় পরামর্শ পাওয়ার জন্য তাদের সময় / মনোযোগ হারাবেন
• আরও অভিজ্ঞ এবং পাকা কারও চিন্তার প্রক্রিয়াটি জানুন এবং ভাল যোগাযোগের মাধ্যমে আপনি অবশ্যই নতুন জিনিস শিখবেন

---

'কোডিংয়ে ভাল থাকুন' ব্যতীত আমি অন্য কোন কৌশলটি ব্যবহার করতে পারি? আমি পরের সপ্তাহে আমার সুপারভাইজারের সাথে এটি আনতে চাইছি।

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

Comments

সত্যিই কারা কমেছে :( এটি কোনও বুনো অনুমান নয়, এটি আমার কর্মক্ষেত্রে ঘটে এবং কাজ করার জন্য প্রমাণিত! ঘটনাচক্রে, আমি এই সাইটের অন্যান্য প্রশ্নের উত্তরগুলিতে কঠোর পরিশ্রম করেছি 10 টি প্রতিনিধিত্ব করতে সক্ষম হতে (আমার সম্পর্কিত প্রতিনিধির উপরে ) কেবলমাত্র এটির মধ্যে "জোড় প্রোগ্রামিং" করার পরামর্শ দেওয়ার জন্য কারণ কেউই এটির পরামর্শ দেয় না I আমি এর উত্তর দিতে সত্যিই কঠোর পরিশ্রম করেছি

— জেমস

Answer 11

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

1) আদর্শভাবে আপনি প্রতিদিন আপনার শাখাটি বিকাশে মার্জ করবেন। প্রতিদিন কমপক্ষে একবারে কোডিং করার চেষ্টা করুন যা সমস্ত পরীক্ষায় উত্তীর্ণ হয় যাতে আপনি বিকাশে মিশতে পারেন।

২) যদি আপনার স্বাভাবিক কাজের দিনের সময় কোনও পয়েন্টে ওয়ার্কিং কোড না থাকে তবে আপনার সম্ভবত কাজ করার জন্য খুব বড় কোড রয়েছে। আপনার নিজের কাজটি ছোট ছোট কার্যগুলিতে বিভক্ত করতে হবে যা শেষ (শেষ পর্যন্ত একে অপরের থেকে স্বতন্ত্রভাবে) দ্রুত করা যেতে পারে যাতে আপনি মার্জ করতে পারেন।

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

4) আপনার দলটি খুব বড় হতে পারে। আপনি যদি পুরো বৈশিষ্ট্যটি ছুঁড়ে ফেলা এবং আবার শুরু করা সহজ মনে করেন তবে সম্ভবত একই ভান্ডারে কোড দেওয়ার জন্য খুব বেশি লোক রয়েছে।

5) আপনার নিয়মিত কোড বিন্যাসের মান নাও থাকতে পারে। আপনি যদি সকলেই ধারাবাহিকভাবে একই কোড বিন্যাস ব্যবহার না করেন তবে একই কোডটির জন্য আপনি বিভিন্ন বিবাদ পাবেন। আপনার গিটটি কীভাবে সেট আপ করা হয়েছে তার উপর নির্ভর করে এমনকি শ্বেত স্পেস বিবাদগুলিতে নেমে আসতে পারে (লাইন এন্ডিংস, ইনডেন্টেশন, ট্যাব বনাম স্পেস)।

)) লোকেরা তাদের পরিবর্তনগুলি সরাসরি বিকাশকারী শাখার দিকে ঠেলে দিচ্ছে।

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

Answer 12

আমার কাজটি স্ক্র্যাপ করা এবং টাস্কটি শুরু করা আসলে সহজ মনে হচ্ছে যা অবশ্যই কোনও টেকসই সমাধান নয়)

বেশিরভাগ সময়, আমি এটিই করি, প্রথম বার আমি কোনও বাগ ঠিক করেছিলাম বা সিস্টেমে কোনও পরিবর্তন আনছি, আমি কীভাবে এটি করব তা শিখছি। পরের বার আমি একই বাগটি ঠিক করে ফেললে এটি এখন 1% সময় নেয় কারণ আমি এখন সমস্যাটি বুঝতে পারি।

আমি আরও দেখতে পাই যে আমি যখন কিছুটা কাজ আবার করি তখন আমি আরও ভাল কোড লিখি .....

অতএব আপনার কী করা দরকার তা মনে করিয়ে দেওয়ার জন্য আপনার "ব্যক্তিগত শাখা" ব্যবহার করার সময় মাস্টার থেকে নতুন শাখা তৈরি করা, এতে আপনার কাজটি পুনরায় করাতে কোনও ভুল নেই wrong

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

Answer 13

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

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

Answer 14

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

1. কাজগুলি স্বাধীনভাবে ভাগ করুন:

   আপনি আপনার কাজ শুরু করার আগে পুরো কাজগুলিকে এমনভাবে পরিকল্পনা করুন এবং ভাগ করুন যাতে প্রতিটি দলের সদস্যের জন্য নির্ধারিত কাজ যতটা সম্ভব স্বাধীন এবং মডুলার (বিকাশের সময় সম্ভাব্য দ্বন্দ্ব এড়াতে)। আপনি নবাগত হওয়ায় আপনার জন্য কিছু স্বাধীন কাজ বরাদ্দ করতে আপনি আপনার স্ক্র্যাম নেতার কাছে যেতে পারেন।

2. ঘন ঘন ঘন কমিটগুলি মার্জ করুন:

   চূড়ান্ত মার্জ হওয়ার আগে পুরো টাস্কটি সম্পন্ন হওয়ার জন্য অপেক্ষা করবেন না। কোর্সে কোনও বড় কাজ একাধিক সাবটাস্কে বিভক্ত করা যায়। সুতরাং বৃহত্তর দ্বন্দ্বের সমাধান এড়াতে ঘন ঘন ছোট সাবটাস্কের জন্য ছোট ছোট কমিটগুলি মার্জ করা আরও ভাল পন্থা।

3. আপনার শাখা ঘন ঘন রিবেস করুন:

   রিমোটের সাথে আপনার স্থানীয় শাখায় ঘন ঘন পুনর্বাসনের একটি অনুশীলন করুন। আপনার স্থানীয় শাখাকে দূরবর্তী একের সাথে ঘন ঘন রিবাইস করতে আপনি নীচের কমান্ডটি ব্যবহার করতে পারেন,

   git pull --rebase #or
   git pull --rebase origin dev #when dev is remote branch
   

   এটি আমার উন্নয়ন জীবনে আমার জন্য এখন পর্যন্ত সবচেয়ে দরকারী গিট কমান্ড।

4. সতীর্থদের সাথে নিবিড়ভাবে কাজ করুন:

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

5. গিট বিকল্পগুলির সাথে অভ্যস্ত থাকুন:

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