গিটিং কমিটগুলি একই শাখায় একটি রিবেস করার পরে নকল করা হয়

Question

প্রো গিট- এ রিলিজিংয়ের বিপদ সম্পর্কিত বিষয়গুলি উপস্থাপনাটি আমি বুঝতে পারি । মূলত লেখক আপনাকে ডুপ্লিকেট করা কমিটগুলি এড়ানোর জন্য কীভাবে বলে:

আপনি যে পাবলিক স্টোরগুলিতে চলে এসেছেন সেই প্রতিশ্রুতিগুলি রিবেস করবেন না।

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

ধরা যাক আমি তাদের স্থানীয় প্রতিযোগীদের সাথে দুটি রিমোট শাখা রেখেছি:

origin/master    origin/dev
|                |
master           dev

চারটি শাখায় একই কমিট রয়েছে এবং আমি এর মধ্যে বিকাশ শুরু করতে যাচ্ছি dev:

origin/master : C1 C2 C3 C4
master        : C1 C2 C3 C4

origin/dev    : C1 C2 C3 C4
dev           : C1 C2 C3 C4

বেশ কয়েকটা কমিটমেন্টের পরে আমি পরিবর্তনগুলিকে এতে চাপছি origin/dev:

origin/master : C1 C2 C3 C4
master        : C1 C2 C3 C4

origin/dev    : C1 C2 C3 C4 C5 C6  # (2) git push
dev           : C1 C2 C3 C4 C5 C6  # (1) git checkout dev, git commit

masterদ্রুত সমাধান করতে আমাকে ফিরে যেতে হবে:

origin/master : C1 C2 C3 C4 C7  # (2) git push
master        : C1 C2 C3 C4 C7  # (1) git checkout master, git commit

origin/dev    : C1 C2 C3 C4 C5 C6
dev           : C1 C2 C3 C4 C5 C6

এবং devআমার বাস্তব উন্নয়নে দ্রুত সমাধানকে অন্তর্ভুক্ত করতে আমি পরিবর্তনগুলি পুনরায় ফিরিয়ে আনছি:

origin/master : C1 C2 C3 C4 C7
master        : C1 C2 C3 C4 C7

origin/dev    : C1 C2 C3 C4 C5 C6
dev           : C1 C2 C3 C4 C7 C5' C6'  # git checkout dev, git rebase master

আমি যদি গিটএক্স / গিটকের সাথে কমিটের ইতিহাস প্রদর্শন করি তবে আমি খেয়াল করব যে origin/devএখন দুটি অভিন্ন কমিট রয়েছে C5'এবং C6'যা গিতের থেকে পৃথক। এখন আমি যদি এইগুলিতে পরিবর্তনগুলি ধাক্কা origin/devদিই তবে ফলাফল:

origin/master : C1 C2 C3 C4 C7
master        : C1 C2 C3 C4 C7

origin/dev    : C1 C2 C3 C4 C5 C6 C7 C5' C6'  # git push
dev           : C1 C2 C3 C4 C7 C5' C6'

প্রো গিতের ব্যাখ্যাটি আমি পুরোপুরি বুঝতে পারি না, তাই আমি দুটি জিনিস জানতে চাই:

1. রিব্যাক করার সময় কেন গিট এই কমিটগুলি নকল করে? কেবল প্রয়োগ করার পরে C5এবং C6পরে এটি করার কোনও বিশেষ কারণ আছে কি C7?
2. আমি কীভাবে এড়াতে পারি? এটা করা কি বুদ্ধিমান হবে?

Answer 1

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

• C5এবং C6অস্থায়ীভাবে বাইরে টানা হয়dev
• C7 প্রয়োগ হয় dev
• C5এবং C6আবার C7নতুন খেলানো হয় এবং তাই নতুন কমিট তৈরি করে শীর্ষে প্লে হয় its

সুতরাং, আপনার devশাখায়, C5এবং C6কার্যকরভাবে আর অস্তিত্ব নেই: তারা এখন C5'এবং হয় C6'। আপনি যখন এগিয়ে যান origin/dev, গিটটি নতুন কমিট হিসাবে দেখবে C5'এবং C6'তাদের ইতিহাসের শেষের দিকে এগিয়ে নিয়ে যাবে। প্রকৃতপক্ষে, যদি আপনি এর মধ্যে C5এবং C5'মধ্যে পার্থক্যগুলি origin/devলক্ষ্য করেন তবে আপনি লক্ষ্য করবেন যে বিষয়বস্তুটি একই হলেও লাইন সংখ্যা সম্ভবত পৃথক - যা কমিটের হ্যাশটিকে আলাদা করে তোলে।

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

Comments

আমার একই সমস্যা আছে, আমি কীভাবে এখন আমার দূরবর্তী শাখার ইতিহাস ঠিক করতে পারি, শাখাটি মুছে ফেলা এবং চেরি-পিকিংয়ের মাধ্যমে এটি পুনরুদ্ধার করা ছাড়া অন্য কোনও বিকল্প আছে কি ??

— ওয়াজারী

@xdsy: Jave কটাক্ষপাত এই এবং এই ।

— জাস্টিন ᚅᚔᚈᚄᚒᚔ

আপনি বলছেন "সি 5 এবং সি 6 অস্থায়ীভাবে দেব থেকে সরানো হয়েছে ... সি 7 কে দেব প্রয়োগ করা হয়েছে"। যদি এটি হয় তবে সি 5 এবং সি 6 কেন উত্স / দেবের উপর আদেশের ক্রমে সি 7 এর আগে প্রদর্শিত হবে?

— কেজে 50

@ কেজে 50: কারণ সি 5 এবং সি 6 ইতিমধ্যে প্রবেশ করানো হয়েছে origin/dev। যখন devরিবেস করা হয়, এর ইতিহাসটি সংশোধিত হয় (সি 5 / সি 6 অস্থায়ীভাবে সরানো হয় এবং সি 7 এর পরে পুনরায় প্রয়োগ করা হয়)। পুশ রেপোসের ইতিহাস সংশোধন করা সাধারণত একটি সত্যই খারাপ ধারণা ™ আপনি যদি না জানেন তবে আপনি কী করছেন। এই সহজ যদি বিষয়টি তুলে বল ধাক্কা থেকে করে সমাধান করা যেতে পারে devথেকে origin/devঅন্য কেউ রি-বেসের ফলে পরে এবং বিজ্ঞপ্তির বন্ধ কাজ origin/devতারা সম্ভবত সম্পর্কে একটি খারাপ দিন আছে করছি যে। আরও ভাল উত্তর, আবার "এটি করবেন না ... পরিবর্তে মার্জ ব্যবহার করুন"

— জাস্টিন ᚅᚔᚈᚄᚒᚔ

একটি বিষয় লক্ষণীয়: সি 5 এবং সি 5 এর হ্যাশ অবশ্যই পৃথক, তবে লাইন সংখ্যাগুলি পৃথক হওয়ার কারণে নয়, তবে নিম্নলিখিত দুটি তথ্যের জন্য যে কোনওটি পার্থক্যের জন্য যথেষ্ট: ১) আমরা যে হ্যাশটির কথা বলছি কমিট করার পরে পুরো উত্স গাছের হ্যাশ, ডেল্টা পার্থক্যের হ্যাশ নয়, এবং C5 'সি 7 থেকে যা কিছু আসে তা ধারণ করে, যখন সি 5 হয় না, এবং 2) সি 5 এর পিতামাতা' সি 5 থেকে আলাদা এবং এই তথ্য হ্যাশ ফলাফলকে প্রভাবিত করে এমন একটি কমিট ট্রি এর মূল নোডেও অন্তর্ভুক্ত।

— ওজগুর মুরাত

Answer 2

সংক্ষিপ্ত উত্তর

আপনি যে দৌড়েছিলেন তা বাদ দিয়েছেন git push, নিম্নলিখিত ত্রুটিটি পেয়েছেন এবং তারপরে চালিয়ে যেতে git pull:

To [e-mail]:username/test1.git
 ! [rejected]        dev -> dev (non-fast-forward)
error: failed to push some refs to '[e-mail]:username/test1.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

গিট সহায়ক হওয়ার চেষ্টা করার পরেও, এর 'গিট টান' পরামর্শটি সম্ভবত আপনি যা করতে চান তা নয় ।

যদি তুমি হও:

• "বৈশিষ্ট্য শাখা" বা "বিকাশকারী শাখা" একা কাজ করা , তারপরে আপনি git push --forceআপনার পোস্ট-রিবেস কমিটগুলি ( ব্যবহারকারীর 40406767 এর উত্তর অনুসারে ) রিমোটটি আপডেট করতে চালাতে পারেন ।
• একই সাথে একাধিক বিকাশকারীদের সাথে একটি শাখায় কাজ করা, তবে আপনার সম্ভবতgit rebase প্রথম স্থানটি ব্যবহার করা উচিত নয় । আপডেট করতে devপরিবর্তনগুলির masterআপনি উচিত, পরিবর্তে চলমান git rebase master dev, রান git merge masterথাকাকালীন উপর dev( জাস্টিন এর উত্তর অনুযায়ী )।

কিছুটা দীর্ঘ ব্যাখ্যা

গিতে প্রতিটি কমিট হ্যাশ বিভিন্ন কারণের উপর ভিত্তি করে তৈরি করা হয়, যার মধ্যে একটি প্রতিশ্রুতি হ্যাশ যা এর আগে আসে।

যদি আপনি কমিটিকে পুনরায় অর্ডার করেন তবে প্রতিশ্রুতিবদ্ধ হ্যাশগুলি পরিবর্তন করবেন; রিবাজিং (যখন এটি কিছু করে) কমিট হ্যাশগুলিকে পরিবর্তন করবে। এটির সাথে , দৌড়ের ফলাফল git rebase master dev, যেখানে devসামঞ্জস্যের বাইরে রয়েছে , সেখানে নতুন কমেটগুলি masterতৈরি করবে (এবং এইভাবে হ্যাশগুলি) একই বিষয়বস্তুতে রয়েছে তবে তাদের পূর্বে theোকানো প্রতিশ্রুতিগুলির সাথে ।devmaster

আপনি একাধিক উপায়ে এইরকম পরিস্থিতিতে শেষ করতে পারেন। দুটি উপায় যা আমি ভাবতে পারি:

• আপনি masterনিজের devকাজের উপর ভিত্তি করে নিতে চাইলে তাতে কমিট থাকতে পারে
• আপনি এর উপর কমিটগুলি devইতিমধ্যে একটি দূরবর্তী স্থানে ঠেলাঠেলি করা যেতে পারে, যা আপনি তারপরে পরিবর্তন করতে এগিয়ে যান (পুনরায় শব্দ প্রতিশ্রুতি বার্তা, পুনরায় অর্ডার বার্তা, স্কোয়াশ কমিট ইত্যাদি)

আসুন কী ঘটেছিল তা আরও ভালভাবে বুঝতে পারি — এখানে একটি উদাহরণ রয়েছে:

আপনার কাছে একটি সংগ্রহস্থল রয়েছে:

2a2e220 (HEAD, master) C5
ab1bda4 C4
3cb46a9 C3
85f59ab C2
4516164 C1
0e783a3 C0

তারপরে আপনি কমিটগুলি পরিবর্তন করতে এগিয়ে যান।

git rebase --interactive HEAD~3 # Three commits before where HEAD is pointing

(এই জায়গাতেই আপনাকে এখানে আমার শব্দটি গ্রহণ করতে হবে: গিতে কমিটগুলি পরিবর্তন করার বিভিন্ন উপায় রয়েছে this এই উদাহরণে আমি সময় পরিবর্তন করেছি C3তবে আপনি নতুন কমিট সন্নিবেশ করছেন, প্রতিশ্রুতি বার্তাগুলি পরিবর্তন করছেন, কমিটগুলি পুনরায় অর্ডার করছেন, স্কোয়াশিং একসাথে কমিট করে, ইত্যাদি)

ba7688a (HEAD, master) C5
44085d5 C4
961390d C3
85f59ab C2
4516164 C1
0e783a3 C0

এখানেই এটি লক্ষ্য করা গুরুত্বপূর্ণ যে প্রতিশ্রুতিবদ্ধ হ্যাশগুলি আলাদা। আপনি তাদের সম্পর্কে কিছু (কিছু) পরিবর্তন করেছেন বলে এটি প্রত্যাশিত আচরণ। এটি ঠিক আছে, তবে:

চাপ দেওয়ার চেষ্টা করা আপনাকে একটি ত্রুটি দেখাবে (এবং আপনাকে চালানো উচিত এমন ইঙ্গিত git pull)।

$ git push origin master
To [e-mail]:username/test1.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to '[e-mail]:username/test1.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

আমরা যদি চালাই তবে আমরা git pullএই লগটি দেখতে পাচ্ছি:

7df65f2 (HEAD, master) Merge branch 'master' of bitbucket.org:username/test1
ba7688a C5
44085d5 C4
961390d C3
2a2e220 (origin/master) C5
85f59ab C2
ab1bda4 C4
4516164 C1
3cb46a9 C3
0e783a3 C0

অথবা, অন্যভাবে দেখানো হয়েছে:

এবং এখন আমাদের স্থানীয়ভাবে সদৃশ কমিট রয়েছে। যদি আমাদের চালানো হয় তবে git pushআমরা সেগুলি সার্ভারে প্রেরণ করব।

এই পর্যায়ে না এড়াতে, আমরা দৌড়াতে পারি git push --force(যেখানে আমরা তার পরিবর্তে ছুটে এসেছি git pull)। এটি কোনও সমস্যা ছাড়াই সার্ভারে নতুন হ্যাশ সহ আমাদের কমিটগুলি প্রেরণ করত। এই পর্যায়ে সমস্যাটি সমাধান করতে, আমরা দৌড়ানোর আগেই আবার রিসেট করতে পারি git pull:

আমাদের দৌড়ানোর আগেgit reflog কমিট হ্যাশটি কী ছিল তা দেখতে রিফ্লগ ( ) দেখুন ।git pull

070e71d HEAD@{1}: pull: Merge made by the 'recursive' strategy.
ba7688a HEAD@{2}: rebase -i (finish): returning to refs/heads/master
ba7688a HEAD@{3}: rebase -i (pick): C5
44085d5 HEAD@{4}: rebase -i (pick): C4
961390d HEAD@{5}: commit (amend): C3
3cb46a9 HEAD@{6}: cherry-pick: fast-forward
85f59ab HEAD@{7}: rebase -i (start): checkout HEAD~~~
2a2e220 HEAD@{8}: rebase -i (finish): returning to refs/heads/master
2a2e220 HEAD@{9}: rebase -i (start): checkout refs/remotes/origin/master
2a2e220 HEAD@{10}: commit: C5
ab1bda4 HEAD@{11}: commit: C4
3cb46a9 HEAD@{12}: commit: C3
85f59ab HEAD@{13}: commit: C2
4516164 HEAD@{14}: commit: C1
0e783a3 HEAD@{15}: commit (initial): C0

উপরে আমরা দেখতে পাই যে ba7688aদৌড়ানোর আগে আমরা যে প্রতিশ্রুতিবদ্ধ ছিল তা ছিল git pull। হাতে থাকা এই প্রতিশ্রুতিবদ্ধ হ্যাশটির সাহায্যে আমরা সেই ( git reset --hard ba7688a) টিতে পুনরায় সেট করতে পারি এবং তারপরে চালাতে পারি git push --force।

এবং আমরা সম্পন্ন করেছি।

তবে অপেক্ষা করুন, আমি সদৃশ কমিটগুলি বন্ধ করে দিয়েছি

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

এর মতো দেখতে:

3b959b4 (HEAD, master) C10
8f84379 C9
0110e93 C8
6c4a525 C7
630e7b4 C6
070e71d (origin/master) Merge branch 'master' of bitbucket.org:username/test1
ba7688a C5
44085d5 C4
961390d C3
2a2e220 C5
85f59ab C2
ab1bda4 C4
4516164 C1
3cb46a9 C3
0e783a3 C0

অথবা, অন্যভাবে দেখানো হয়েছে:

এই দৃশ্যে আমরা সদৃশ কমিটগুলি সরিয়ে ফেলতে চাই, তবে তাদের উপর ভিত্তি করে করা কমিটগুলি রাখি — আমরা C10 এর মাধ্যমে C6 রাখতে চাই। বেশিরভাগ জিনিসগুলির মতোই, এ সম্পর্কে অনেকগুলি উপায় রয়েছে:

উভয় ক্ষেত্রেই:

• সর্বশেষ সদৃশ কমিট ¹ এ একটি নতুন শাখা তৈরি করুন , cherry-pickপ্রতিটি কমিট (সি 10 এর মাধ্যমে সি 6 অন্তর্ভুক্ত) সেই নতুন শাখায়, এবং সেই নতুন শাখাটিকে ক্যানোনিকাল হিসাবে বিবেচনা করুন।
• চালান git rebase --interactive $commit, সদৃশ ² টির পূর্বে$commit প্রতিশ্রুতিবদ্ধ কোথায় । এখানে আমরা ডুপ্লিকেটগুলির জন্য লাইনগুলি সরাসরি মুছে ফেলতে পারি।

¹ আপনি দুজনের মধ্যে যে কোনওটি বেছে নিন ba7688aবা 2a2e220ঠিকঠাক কাজ করুন তা বিবেচ্য নয়।

² উদাহরণে এটি হবে 85f59ab।

টি এল; ডিআর

এতে সেট advice.pushNonFastForwardকরুন false:

git config --global advice.pushNonFastForward false

Comments

"গিট টান ..." পরামর্শ অনুসরণ করা ঠিক আছে যতক্ষণ না এলিসিসটি "--rebase" বিকল্পটি লুকিয়ে রাখে (ওরফে "-আর") long ;-)

— জি। সিলভি ডেভিস

আমি ব্যবহার সুপারিশ করবে git push's --force-with-leaseআজকাল যেমন এটি একটি ভাল ডিফল্ট এর

— Whymarrh

এটি হয় এই উত্তর বা একটি টাইম মেশিন। ধন্যবাদ!

— জেমুন

খুব ঝরঝরে ব্যাখ্যা ... আমি বারবার রিবেস করার চেষ্টা করার পরে আমার কোডটি 5-6 বার নকল করে এমন একটি সমস্যা পেয়েছি ... কেবলমাত্র মাস্টারের সাথে কোডটি আপ টু ডেট আছে তা নিশ্চিত হওয়ার জন্য ... তবে প্রতিবারই এটি ঠেলেছে আমার শাখায় নতুন প্রতিশ্রুতিবদ্ধ, আমার কোডটিও নকল করে। আপনি কি আমাকে বলবেন যে ফোর্স পুশ (ইজারা বিকল্প সহ) এখানে করা নিরাপদ কিনা আমি যদি আমার শাখায় কাজ করা একমাত্র বিকাশকারী? বা আমার পরিবর্তে মাস্টারকে মার্জ করা বদল করা আরও ভাল উপায়?

— ধ্রুব সিংহল

Answer 3

আমি মনে করি আপনার পদক্ষেপগুলি বর্ণনা করার সময় আপনি একটি গুরুত্বপূর্ণ বিশদটি এড়িয়ে গেছেন। আরও সুনির্দিষ্টভাবে, আপনার শেষ পদক্ষেপটি, git pushদেবকে আসলে আপনাকে একটি ত্রুটি দিয়েছে, কারণ আপনি সাধারণত অ-দ্রুতগতির পরিবর্তনগুলিকে ধাক্কা দিতে পারেন না।

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

অথবা আপনি এর পরিবর্তে একটি তৈরি করেছেন git pull --rebase(বা এটি --rebaseআপনার কনফিগারেশনের দ্বারা নিহিত থাকলে স্পষ্ট ছাড়াই ), যা আপনার স্থানীয় দেবের মূল সি 5 এবং সি 6 কে আবার টেনে এনেছে (এবং নীচেরগুলিকে নতুন হ্যাশগুলিতে পুনরায় পুনর্বাসিত করেছে, সি 7 'সি 5' 'সি 6' ')।

এর থেকে বেরিয়ে আসার একটি উপায় হতে পারে git push -fযখন চাপটি চাপিয়ে দেওয়া হয়েছিল এবং সি 5 সি 6 টি উত্স থেকে মুছে ফেলা হয়েছে তবে অন্য কেউ যদি সেগুলি মুছে ফেলার আগে আপনাকে এনে টানতে থাকে তবে আপনি আরও অনেক বেশি সমস্যার জন্য থাকতে পারেন .. মূলত: C5 C6 থাকা প্রত্যেককেই এগুলি থেকে মুক্তি পাওয়ার জন্য বিশেষ পদক্ষেপগুলি করা দরকার। ঠিক এ কারণেই তারা বলেছে যে ইতিমধ্যে প্রকাশিত কোনও কিছুই আপনার পুনরায় ব্যবহার করা উচিত নয়। "প্রকাশনা" একটি ছোট দলের মধ্যে থাকলেও এটি এখনও কার্যক্ষম।

Comments

বাদ দেওয়া git pullঅত্যন্ত গুরুত্বপূর্ণ। আপনার সুপারিশটি git push -fবিপজ্জনক হলেও সম্ভবত এটিই পাঠকরা খুঁজছেন।

— 23

প্রকৃতপক্ষে. আমি যখন প্রশ্নটি আসলে লিখেছিলাম তখন ফিরে আসি git push --forceকেবল গিট কী করতে চলেছে তা দেখার জন্য। আমি তখন থেকে গিট সম্পর্কে একটি টন শিখেছি এবং আজকাল rebaseআমার স্বাভাবিক কর্মপ্রবাহের অংশ। তবে আমি git push --force-with-leaseঅন্য কারও কাজ ওভাররাইট করা এড়ানোর জন্য করি do

— এলিটালন

ব্যবহার --force-with-leaseকরা একটি ভাল ডিফল্ট, আমি আমার উত্তরের নীচে একটি মন্তব্যও রেখে দেব

— কেনোমারহ

Answer 4

আমি জানতে পেরেছিলাম যে আমার ক্ষেত্রে, এটি একটি গিট কনফিগারেশন সমস্যার পরিণাম। (জড়িত টান এবং মার্জ)

সমস্যার বর্ণনা:

লক্ষণসমূহ: পুনর্বাসনের পরে শিশু শাখায় অনুলিপি করা কমিটগুলি পুনর্বাসনের সময় এবং পরে অনেকগুলি সংশ্লেষ বোঝায়।

কর্মপ্রবাহ: আমি যে কর্মপ্রবাহটি সম্পাদন করছিলাম তার পদক্ষেপগুলি এখানে:

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

এই কর্মপ্রবাহের স্বতন্ত্রতা হিসাবে, পূর্ববর্তী রিবেস থেকে "বৈশিষ্ট্য-শাখা" এর সমস্ত অঙ্গীকারের সদৃশ ... :-(

সমস্যাটি পুনঃবাসের আগে শিশু শাখায় পরিবর্তন আনার কারণে হয়েছিল। গিটের ডিফল্ট পুল কনফিগারেশনটি "মার্জ" " এটি শিশু শাখায় সম্পাদিত প্রতিশ্রুতিগুলির সূচিগুলি পরিবর্তন করছে।

সমাধান: গিট কনফিগারেশন ফাইলে, রিবেস মোডে কাজ করতে টান কনফিগার করুন:

...
[pull]
    rebase = preserve
...

আশা করি এটি জেএন গ্রক্সকে সহায়তা করতে পারে

Answer 5

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

যদি এটি ঘটে থাকে তবে আপনি নিম্নলিখিতগুলি করতে পারেন:

git reset --hard HEAD~n

কোথায় n == <number of duplicate commits that shouldn't be there.>

তারপরে নিশ্চিত হয়ে নিন যে আপনি সঠিক শাখা থেকে টানছেন এবং তারপরে চালান:

git pull upstream <correct remote branch> --rebase

সাথে টানলে --rebaseনিশ্চিত হবে যে আপনি বহিরাগত কমিট যোগ করছেন না যা প্রতিশ্রুতিবদ্ধ ইতিহাসকে জঞ্জাল করে তুলবে।

গিট রিবেসের জন্য কিছুটা হাত ধরে।