পুনর্বাসনের পরে শাখায় ঠেলাঠেলি করতে পারে না

Question

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

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

প্রশ্ন: পুনঃবাস এবং সংঘাতের সমাধানের পরে, আমি কীভাবে সদৃশ কমিট তৈরি না করে আমার স্থানীয় এবং দূরবর্তী বিকাশকারী শাখাগুলি সিঙ্ক করব?

সেটআপ:

// master branch is the main branch
git checkout master
git checkout -b myNewFeature

// I will work on this at work and at home
git push origin myNewFeature

// work work work on myNewFeature
// master branch has been updated and will conflict with myNewFeature
git pull --rebase origin master

// we have conflicts
// solve conflict
git rebase --continue

//repeat until rebase is complete
git push origin myNewFeature

//ERROR
error: failed to push some refs to '[e-mail]:ariklevy/dropLocker.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

// do what git says and pull
git pull origin myNewFeature

git push origin myNewFeature

// Now I have duplicate commits on the remote branch myNewFeature

সম্পাদনা

সুতরাং মনে হচ্ছে এটি কর্মপ্রবাহটি ভেঙে দেবে:

ডেভেলপার 1 আমার নিউফিউচার ডেভেলপার 2 এ কাজ করছে তার নিউ ফিউচার দুজনেই মাস্টারকে প্রধান শাখা হিসাবে ব্যবহার করছে

বিকাশকারী 2 আমারনিউজ ফিচারকে তার নিউ ফিচারে মার্জ করে

বিকাশকারী 1 পুনর্বাসনা করে, দ্বন্দ্বগুলি সমাধান করে, তারপরে আমার নিউ ফিজির জন্য দূরবর্তী শাখায় জোর করে

কয়েক দিন পরে, বিকাশকারী 2, আমার নিউফিউচারটিকে আবার তার নিউ ফিচারে মার্জ করে

এর ফলে কি অন্যান্য বিকাশকারীগণ বিকাশকারীকে ঘৃণা করবে?

Comments

সমাধান নয়, কেবল একটি চিন্তা। কে we? আপনি শুধু আপনি চেয়ে বেশি একটি দলে আছেন? theyবলুন (আমার চেয়ে বেশি পরিচিত লোকেরা) যে আপনি যদি আপনার কোডটি ভাগ করেন তবে আপনার ব্যবহার করা উচিত নয় rebase। কেন আপনি শুধু করছেন না git pullএবং git merge?

— অ্যাডামটি

দুঃখিত, আমরা = উন্নয়ন দল

— ম্যাট

হ্যাঁ, আপনি কোড ভাগ করে নেওয়ার সময় সম্ভবত রিবাজ করা উচিত নয়। যা আপনাকে নীচে তালিকাভুক্ত ( forceধাক্কা) এর মতো কাজ করতে পারে

— অ্যাডামটি

ওহ দুঃখিত, যখন তারা বলেন rewriting history, এটি একটিrebase

— অ্যাডামটি

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

— লেরাথ 2

Answer 1

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

o-----o-----o-----o-----o-----o       master
 \
   o-----o-----o                      devel0
                \
                  o-----o-----o       devel1

তারপরে রিমোটের সাথে আপ টু ডেট থাকার জন্য আমি নিম্নলিখিতগুলি করব:

 git fetch origin
 git checkout master
 git merge --ff origin/master

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

তারপরে যখন রিমোটের পরিবর্তন হয় এবং আমি দ্রুত আমি ফেরত দেব তা দ্রুত পাঠিয়েছি:

git checkout devel0
git rebase master
git push -f origin devel0

অন্যান্য বিকাশকারীরা তখন জানে যে তাদের আমার ডেভেল শাখাগুলি আমার সর্বশেষে বন্ধ করে দিতে হবে:

git fetch <remote>
git checkout devel1
git rebase <remote>/devel0

যা অনেক ক্লিনার ইতিহাসে ফলাফল:

o-----o                                 master
       \
         o-----o-----o                  devel0
                      \
                        o-----o-----o   devel1

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

এছাড়াও এটির মতো শোনাচ্ছে যে অন্যান্য বিকাশকারীরা আপনার ডেভেল শাখাগুলিতে কমিট করে। আপনি এটা নিশ্চিত করতে পারেন?

একত্রীকরণের সময় কেবলমাত্র যখন আপনার বিষয় শাখাটি স্বীকৃতি পেতে প্রস্তুত master।

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

git branch 'my-name/devel-branch'

সুতরাং সমস্ত বিকাশকারী বিষয় শাখাগুলি তাদের নিজস্ব নেস্টেট সেটের মধ্যে থাকে।

Comments

"এছাড়াও এটির মতো শোনাচ্ছে যে অন্যান্য বিকাশকারীরা আপনার ডেভেল শাখাগুলিতে কমিট করছে। আপনি এটি নিশ্চিত করতে পারেন?" হ্যাঁ তারা ...

— ম্যাট

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

— ম্যাট

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

— ট্রেভর নরিস

দুর্দান্ত উত্তর। আমার একটি পার্শ্ব প্রশ্ন আছে, আপনি --forceযখন পতাকাটি ব্যবহার করছেন তখন কেন git push -f origin devel0?

— নোবিতা

@ নোবিতা যখন কোনও git pushদ্রুত-ফরোয়ার্ড করতে পারে না (যেমন শ ইতিহাসটি মেলে না) আপনাকে অবশ্যই পূর্বের ইতিহাসটি ওভাররাইট করার জন্য পুস্তকে জোর করা উচিত যখন থেকে উত্পন্ন নতুন ইতিহাসের সাথে git rebase।

— ট্রেভর নরিস

Answer 2

লাইন গিটটি আরও কমিটকে সরানোর সাথে সাথে আপনাকে শাখার ডগায় কমিট যোগ করার আশা করা হচ্ছে বলে আপনাকে চাপ দিতে হবে। git push -f origin myNewFeatureআপনার সমস্যা সমাধান করবে।

টিপ: উপরে চাপ দেওয়া বৈধ ব্যবহার। কখনও কখনও সর্বজনীন অ্যাক্সেসযোগ্য ভান্ডারে ইতিহাস পুনর্লিখন করবেন না বা প্রচুর লোক আপনাকে ঘৃণা করবে না।

Comments

আমি এই কাজের প্রবাহ বজায় রাখার সবচেয়ে অনুকূল উপায়।

— সৈয়দ প্রিম

ধন্যবাদ বন্ধু. আমি আমার আদেশযুক্ত স্থানীয় শাখাটিকে একই দূরবর্তী শাখায় বাধ্য করতে এই আদেশটি ব্যবহার করেছি।

— ওয়েই

ব্যবহার git push --force-with-leaseকরা ব্যবহারের চেয়ে অনেক বেশি নিরাপদgit push --force

git push --force-with-lease origin HEAD- ধরে নিচ্ছি আপনার টার্গেট শাখা ইতিমধ্যে চেক হয়েছে

— লুচাকি সার্জিউ

Answer 3

এখানে মনে রাখার মূল বিষয়টি হ'ল পর্দার আড়ালে টানা এবং পুনর্বাসনা কী করছে।

একটি টান মূলত দুটি জিনিস করবে: আনুন এবং একত্রিত হন। আপনি যখন --rebase অন্তর্ভুক্ত করবেন তখন এটি মার্জের পরিবর্তে একটি রিবেস করবে।

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

(এটি ব্যাখ্যা করে যে কেন আপনি একত্রীকরণের সাথে পেতে হতে পারে এমন দ্বন্দ্বের সমাধানের তুলনায় পুনরায় রিবেস করার সময় কেন আপনি একাধিক সংঘাতের সমাধানের অনুরোধ জানাতে পারেন otherwise আপনার প্রতিশ্রুতি রক্ষা করার জন্য পুনর্বাসন করা প্রতিটি প্রতিশ্রুতি সম্পর্কিত বিরোধের সমাধান করার সুযোগ আপনার রয়েছে। )

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

এর জন্য আপনাকে শক্তি প্রয়োগ করে সময়ে পুনর্বহাল পরিবর্তনগুলি ঠেকাতে হবে:

git push -f origin newfeature

বা কিছু ক্ষেত্রে আপনার প্রশাসক জোর করার ক্ষমতা সরিয়ে ফেলেছে যাতে আপনাকে অবশ্যই মুছতে এবং পুনরায় তৈরি করতে হবে:

git push origin :newfeature
git push origin newfeature

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

মনে রাখবেন আপনি প্রায় সবসময় গিটের জিসিতে ফ্যালব্যাক করতে পারেন এর সুবিধা গ্রহণ করে:

git reflog

আপনি যদি আপনার সমস্ত রিবেস / সংঘাতের ব্যবস্থাপনায় হারিয়ে যান তবে আপনি আরও স্থিতিশীল অবস্থায় পুনরায় সেট করতে পারেন বলে এটি একটি বিশাল জীবনরক্ষক।

Comments

উপরের মুছুন এবং পুনঃনির্ধারণ বিকল্পটি আমার জন্য দুর্দান্ত কাজ করেছে। আমার রেপোতে কোন জোর করার অনুমতি নেই!

— সাইমন হোমস

Answer 4

আপনি একটি জোরপূর্বক ধাক্কা সঞ্চালন করা প্রয়োজন, অর্থাত্ git push -f origin myNewFeature

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

Comments

ব্যবহার git push --force-with-leaseকরা ব্যবহারের চেয়ে অনেক বেশি নিরাপদgit push --force

@ মিঃচোলো লোকরা -fসাধারণ জোর করে ধাক্কা দেওয়ার মতো গিট এর জন্য একটি সংক্ষিপ্ত বিকল্প যোগ না করা অবধি এটি ব্যবহার শুরু করবে না

— থিফমাস্টার

হ্যাঁ, আমি এটি একটি স্বয়ংক্রিয় স্ক্রিপ্টে ব্যবহার করেছি

Answer 5

সাধারণ উত্তর যা ইতিমধ্যে দেওয়া হয়েছে - git push -f origin myNewFeatureরিবেসড পরিবর্তনগুলিকে ধাক্কা দেওয়ার সময় ব্যবহার করা - এটি একটি ভাল শুরু করার জায়গা। আমি সম্পাদনাটি সম্বোধনের জন্য এই উত্তরটি লিখছি যা এটি আপনার কর্মপ্রবাহকে ভঙ্গ করবে কিনা।

যদি আমরা ধরে নিই যে আপনি git pull --rebase ...রিমোট শাখায় একটি চাপ-ধাক্কা অনুসরণ করে (বা তার কিছু কিছু পরিবর্তন) ব্যবহার করতে যাচ্ছেন , তবে আপনার উদাহরণে কর্মপ্রবাহ ভেঙে জিনিসটি বিকাশকারী 2 হয়ে myNewFeatureযাচ্ছে hisNewFeature। আপনার নিজস্ব বৈশিষ্ট্য শাখাটি রিবেস করতে সক্ষম হবে তা বোঝা যায় যতক্ষণ না। শাখায় অন্য কেউ কাজ করছেন না, তাই আপনাকে শাখার অঞ্চল নির্ধারণের জন্য বিধিগুলির প্রয়োজন।

আপনি ক) এর মাধ্যমে কোনও নিয়ম প্রতিষ্ঠা করে আপনি কেবল কখনও মিশ্রিত হন masterবা খ) একটি যৌথ developশাখা তৈরি করে, যার উপর ভিত্তি করে আপনি নিজের myNewFeatureশাখাটি ভিত্তি করে থাকেন এবং এমন কোনও নিয়ম প্রতিষ্ঠা করেন যা আপনি কেবল কখনও মিশ্রিত হন develop। masterতারপরে কেবল মাইলফলক বা রিলিজের জন্য সংরক্ষিত থাকবে (বা অন্যথায় আপনি এটি সেট আপ করতে চান) এবং developএটি সেখানে থাকবে যখন আপনি প্রতিটি বৈশিষ্ট্যটিকে অন্য বৈশিষ্ট্য শাখায় সংহত করার জন্য প্রস্তুত হন push

আমি বিশ্বাস করি এটি গিটফ্লো ওয়ার্কফ্লোয়ের একটি সরল সংস্করণ হিসাবে বিবেচনা করা যেতে পারে।

Answer 6

আমি একমত MrCholo এবং হয়তো ট্রেভর নরিস তার আপডেট করার বিবেচনা করতে পারে ভাল উত্তর প্রতিস্থাপন

git push -f origin devel0

সঙ্গে

git push --force-with-lease origin devel0