যখন আমি যা করছি সমস্ত স্কোয়াশ করছে তখন গিট-রিবেস আমাকে কেন মার্জ কোন্দল দেয়?


146

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

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


repo_squash.sh (এটি আসলে স্ক্রিপ্টটি চালিত হয়):


rm -rf repo_squash
git clone repo repo_squash
cd repo_squash/
GIT_EDITOR=../repo_squash_helper.sh git rebase --strategy theirs -i bd6a09a484b8230d0810e6689cf08a24f26f287a

repo_squash_helper.sh (এই স্ক্রিপ্টটি কেবল repo_squash.sh দ্বারা ব্যবহৃত হয়):


if grep -q "pick " $1
then
#  cp $1 ../repo_squash_history.txt
#  emacs -nw $1
  sed -f ../repo_squash_list.txt < $1 > $1.tmp
  mv $1.tmp $1
else
  if grep -q "initial import" $1
  then
    cp ../repo_squash_new_message1.txt $1
  elif grep -q "fixing bad import" $1
  then
    cp ../repo_squash_new_message2.txt $1
  else
    emacs -nw $1
  fi
fi

repo_squash_list.txt: (এই ফাইলটি কেবল repo_squash_helper.sh দ্বারা ব্যবহৃত হয়)


# Initial import
s/pick \(251a190\)/squash \1/g
# Leaving "Needed subdir" for now
# Fixing bad import
s/pick \(46c41d1\)/squash \1/g
s/pick \(5d7agf2\)/squash \1/g
s/pick \(3da63ed\)/squash \1/g

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

জেফ্রুমির সাথে আলোচনা থেকে অতিরিক্ত তথ্য দিয়ে আপডেট করা:

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

ব্যর্থ হওয়ার পরে আমি যে বার্তাটি পাই তা হ'ল:

Finished one cherry-pick.
# Not currently on any branch.
nothing to commit (working directory clean)
Could not apply 66c45e2... Needed subdir

এটি প্রথম স্কোয়াশ কমিটের পরে প্রথম পিক। চলমান git statusএকটি পরিষ্কার ওয়ার্কিং ডিরেক্টরি ফলন করে। তারপরে যদি আমি এটি করি তবে git rebase --continueআমি আরও কিছু কমিট করার পরে একটি খুব অনুরূপ বার্তা পেয়েছি। আমি যদি আবার এটি করি তবে কয়েক ডজন কমিট করার পরে আমি আরও একটি অনুরূপ বার্তা পেয়েছি। যদি আমি এটি আবারও করি, এবার এটি প্রায় একশটি কমিটের মধ্য দিয়ে যায় এবং এই বার্তাটি দেয়:

Automatic cherry-pick failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>', and
run 'git rebase --continue'
Could not apply f1de3bc... Incremental

আমি যদি তখন দৌড়ে যাই তবে git statusআমি পেলাম:

# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   repo/file_A.cpp
# modified:   repo/file_B.cpp
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified:      repo/file_X.cpp
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted:    repo/file_Z.imp

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

যদি আমি ম্যানুয়ালি ফাইল_এক্স.পি.পি. ঠিক করে রাখি, তবে এটির পরে খুব শীঘ্রই অন্য বিরোধের সাথে ব্যর্থ হয়, এবার একটি ফাইলের মধ্যে (সিএমকেলিস্ট.টেক্সট) যা একটি সংস্করণ মনে করে যে একটি সংস্করণ থাকা উচিত এবং একটি সংস্করণ মনে করে। আমি যদি এই ফাইলটি (যা আমি করি) চাই বলে এই বিরোধটি স্থির করে তুলি তবে কয়েকটা কমিটমেন্ট পরে আমি আরও একটি দ্বন্দ্ব পাই (এই একই ফাইলে) যেখানে এখন কিছুটা তুচ্ছ তাত্পর্যপূর্ণ পরিবর্তন রয়েছে। এটি এখনও বিরোধের মধ্য দিয়ে প্রায় 25% পথ the

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

আপডেট # 2:

একটি লার্কে (জেফ্রোমের মন্তব্য দ্বারা প্রভাবিত), আমি আমার repo_squash.sh পরিবর্তনটি করার সিদ্ধান্ত নিয়েছি:

rm -rf repo_squash
git clone repo repo_squash
cd repo_squash/
git rebase --strategy theirs -i bd6a09a484b8230d0810e6689cf08a24f26f287a

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

আপডেট # 3:

বিকল্পভাবে, যদি আমি কৌশল বাদ দিয়ে শেষ কমান্ডটি প্রতিস্থাপন করি তবে:

git rebase -i bd6a09a484b8230d0810e6689cf08a24f26f287a

রিবেস সমস্যাগুলি আমি আর "প্রতিশ্রুতিবদ্ধ হওয়ার মতো কিছুই" পাই না, তবে আমি এখনও অন্য সংঘাতগুলির মধ্যে রয়েছি।

খেলনা ভান্ডার সাথে আপডেট করুন যা সমস্যাটি পুনরায় তৈরি করে:

test_squash.sh (এটি আসলে আপনি ফাইল করেন):

#========================================================
# Initialize directories
#========================================================
rm -rf test_squash/ test_squash_clone/
mkdir -p test_squash
mkdir -p test_squash_clone
#========================================================

#========================================================
# Create repository with history
#========================================================
cd test_squash/
git init
echo "README">README
git add README
git commit -m"Initial commit: can't easily access for rebasing"
echo "Line 1">test_file.txt
git add test_file.txt
git commit -m"Created single line file"
echo "Line 2">>test_file.txt 
git add test_file.txt 
git commit -m"Meant for it to be two lines"
git checkout -b dev
echo Meaningful code>new_file.txt
git add new_file.txt 
git commit -m"Meaningful commit"
git checkout master
echo Conflicting meaningful code>new_file.txt
git add new_file.txt 
git commit -m"Conflicting meaningful commit"
# This will conflict
git merge dev
# Fixes conflict
echo Merged meaningful code>new_file.txt
git add new_file.txt
git commit -m"Merged dev with master"
cd ..

#========================================================
# Save off a clone of the repository prior to squashing
#========================================================
git clone test_squash test_squash_clone
#========================================================

#========================================================
# Do the squash
#========================================================
cd test_squash
GIT_EDITOR=../test_squash_helper.sh git rebase -i HEAD@{7}
#========================================================

#========================================================
# Show the results
#========================================================
git log
git gc
git reflog
#========================================================

test_squash_helper.sh (test_sqash.sh দ্বারা ব্যবহৃত):

# If the file has the phrase "pick " in it, assume it's the log file
if grep -q "pick " $1
then
  sed -e "s/pick \(.*\) \(Meant for it to be two lines\)/squash \1 \2/g" < $1 > $1.tmp
  mv $1.tmp $1
# Else, assume it's the commit message file
else
# Use our pre-canned message
  echo "Created two line file" > $1
fi

পিএস: হ্যাঁ, আপনি যখন ফ্যাল-ব্যাক সম্পাদক হিসাবে ইম্যাক্স ব্যবহার করতে দেখেন তখন আমি কারও কারও ক্রিঞ্জ জানি know

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

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


ব্যবহৃত স্ক্রিপ্টগুলির চেয়ে আরও প্রাসঙ্গিক হ'ল চূড়ান্ত চেষ্টা করা ক্রিয়া - এটি আন্তঃমিক্সড পিক এবং স্কোয়াশের তালিকা হতে বেশ নিশ্চিত মনে হচ্ছে, তাই না? এবং রিবেসড শাখায় কোনও মার্জ কমিট আছে? (যদিও আপনি rebase -pযেভাবেই ব্যবহার করছেন না )
ক্যাসাবেল

আমি নিশ্চিত করুন যে আপনি "চূড়ান্ত চেষ্টা কর্ম" দ্বারা কি বোঝাতে চেয়েছেন নই, কিন্তু এটা হয় শুধু intermixed পিক এবং স্কোয়াশ একটি তালিকা গত 400 সহ বা তাই সব পিক হচ্ছে। সেই তালিকায় কোনও মার্জ নেই, যদিও রিবাইজিং নিজেই নিজস্ব মার্জগুলি সম্পাদন করে। আমি যা পড়েছি তার অনুসারে, "রিবাজ-পি" ইন্টারেক্টিভ মোডের সাথে সুপারিশ করা হয় না (যা আমার ক্ষেত্রে অবশ্যই এটি সমস্ত ইন্টারেক্টিভ নয়)। থেকে kernel.org/pub/software/scm/git/docs/git-rebase.html : "এই অভ্যন্তরীণভাবে --interactive যন্ত্রপাতি ব্যবহার করে, কিন্তু --interactive বিকল্প এটা মিশ্রন স্পষ্টভাবে সাধারণত একটি ভাল ধারণা নয়"
বেন হংকিং

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

দরকারী মন্তব্যের জন্য ধন্যবাদ। আমি আমার উত্তরগুলি প্রতিবিম্বিত করতে প্রশ্ন আপডেট করেছি।
বেন হকিং

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

উত্তর:


69

ঠিক আছে, আমি একটি উত্তর দিতে যথেষ্ট আত্মবিশ্বাসী। সম্ভবত এটি সম্পাদনা করতে হবে, তবে আমি বিশ্বাস করি আপনার সমস্যাটি কী তা আমি জানি।

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

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

সুতরাং, ধরা যাক আমাদের খুব সাধারণ কেস আছে, যেখানে আমরা A, B এবং C একসাথে স্কোয়াশ করতে চাই:

- o - A - B - C - X - D - E - F (master)
   \             /
    Z -----------

এখন, যেমন আমি বলেছিলাম, এক্সে যদি কোনও বিবাদ না ঘটে, git rebase -i -pআপনি যেমন প্রত্যাশা করতেন তেমন কাজ করে।

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

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

* বা, আপনি rerere-train.shগিট-কন্ট্রোল থেকে স্ক্রিপ্টটি চেষ্টা করতে পারেন , যা "বিদ্যমান মার্জ কমিটগুলি থেকে ডাটাবেসকে পুনরায় দেখাতে" চেষ্টা করে - মূলত, এটি সমস্ত মার্জ কমিটগুলি পরীক্ষা করে, সেগুলিকে মার্জ করার চেষ্টা করে, এবং যদি মার্জটি ব্যর্থ হয়, এটি ফলাফলগুলি ধরে এবং এগুলি দেখায় git-rerere। এটি সময় সাপেক্ষ হতে পারে এবং আমি বাস্তবে এটি কখনই ব্যবহার করি নি তবে এটি খুব সহায়ক হতে পারে।


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

আমি অবশ্যই এই যেতে হবে। এই পোস্ট করার পর আমি এছাড়াও খেয়াল করেছি কিছু ক্ষেত্রে, আমি কেবল টাইপ করতে পারেন git commit -a -m"Some message"এবং git rebase --continue, এবং এটি উপর অব্যাহত থাকবে। এটি -pবিকল্প ছাড়াও কাজ করে , তবে বিকল্পের সাথে এটি আরও ভাল কাজ করে -p(যেহেতু আমি কোনও পুনঃ-অর্ডার করছি না, মনে -pহয় এটি ভাল)। যাইহোক, আমি আপনাকে পোস্ট রাখতে হবে।
বেন হকিং

পরীক্ষার উদাহরণ চালানোর আগে সেট করা git config --global rerere.enabled trueএবং git config --global rerere.autoupdate trueপূর্ববর্তীকরণ প্রাথমিক সমস্যার সমাধান করে। আকর্ষণীয় যথেষ্ট, তবে, এটি নির্দিষ্টকরণের পরেও মার্জগুলি সংরক্ষণ করে না --preserve-merges। তবে, যদি আমার কাছে সেগুলি না থাকে এবং আমি টাইপ করি git commit -a -m"Meaningful commit"এবং git rebase --continueনির্দিষ্ট করার সময় --preserve-mergesএটি মার্জগুলি সংরক্ষণ করে। যাইহোক, এই সমস্যাটি কাটিয়ে উঠতে আমাকে সহায়তা করার জন্য ধন্যবাদ!
বেন হকিং

84

যদি আপনি কোনও নতুন শাখা তৈরি করতে আপত্তি না করেন তবে আমি সমস্যার সাথে এইভাবে মোকাবিলা করেছি:

মূলত:

# create a new branch
git checkout -b new_clean_branch

# apply all changes
git merge original_messy_branch

# forget the commits but have the changes staged for commit
git reset --soft main        

git commit -m "Squashed changes from original_messy_branch"

3
দ্রুত এবং দক্ষ সমাধান :)
ইসলামতাহা

2
এটি একটি দুর্দান্ত পরামর্শ ছিল! বেশ কয়েকটি কমিটি দ্রুত একীকরণের জন্য খুব ভাল কাজ করেছেন।
ফিলিদেম

3
এটি অনেক বেশি নিরাপদ সমাধান। আমি সংযুক্তিতে - স্কোয়াশও যুক্ত করেছি। হচ্ছে: গিট মার্জ
স্কোয়াশ

1
আমার দিন এবং জীবন বাঁচানোর জন্য আপনাকে ধন্যবাদ :) যে কেউ সেরা সমাধান পেতে পারেন

আপনি যখন git diff new_clean_branch..original_messy_branchতাদের একই হওয়া উচিত? আমার জন্য তারা আলাদা।
লিওনার্ডচ্যালিস

5

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

git reset –hard mybranch-start-commit
git checkout mybranch-end-commit . // files only of the latest commit
git add -a
git commit -m”New Message intermediate commits discarded”

ভায়োলা আমরা শাখার শুরু প্রতিশ্রুতি সর্বশেষ প্রতিশ্রুতি সংযুক্ত করেছি! সংঘাতের সমস্যা নেই! আমার শেখার অনুশীলনে আমি এই পর্যায়ে এই সিদ্ধান্তে পৌঁছেছি, উদ্দেশ্যটির জন্য আরও ভাল পদ্ধতির কী আছে?


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

1

উপরে @ hlidka এর দুর্দান্ত উত্তরের উপর বিল্ডিং যা ম্যানুয়াল হস্তক্ষেপকে হ্রাস করে, আমি এমন একটি সংস্করণ যুক্ত করতে চেয়েছিলাম যা কোনও স্ক্র্যাশে শাখায় নেই এমন মাস্টার সম্পর্কে কোনও নতুন প্রতিশ্রুতি সংরক্ষণ করে।

আমি বিশ্বাস করি যে এগুলি git resetউদাহরণের পদক্ষেপে সহজেই হারিয়ে যেতে পারে lost

# create a new branch 
# ...from the commit in master original_messy_branch was originally based on. eg 5654da06
git checkout -b new_clean_branch 5654da06

# apply all changes
git merge original_messy_branch

# forget the commits but have the changes staged for commit
# ...base the reset on the base commit from Master
git reset --soft 5654da06       

git commit -m "Squashed changes from original_messy_branch"

# Rebase onto HEAD of master
git rebase origin/master

# Resolve any new conflicts from the new commits

0

মনে রাখবেন যে -Xইন্টারেক্টিভ রিবেস ব্যবহার করার সময় এবং কৌশল বিকল্পগুলি এড়ানো হয়েছিল।

দেখুন db2b3b820e2b28da268cc88adff076b396392dfe কমিট (জুলাই 2013 Git 1.8.4+),

ইন্টারেক্টিভ রিবেসে মার্জ বিকল্পগুলি উপেক্ষা করবেন না

মার্জ কৌশল এবং এর বিকল্পগুলিতে নির্দিষ্ট করা যেতে পারে git rebaseতবে এর সাথে -- interactiveএগুলি সম্পূর্ণ উপেক্ষা করা হয়েছিল।

সাইন-অফ-বাই: আরনাড ফন্টেইন

এর অর্থ -Xএবং কৌশলটি এখন ইন্টারেক্টিভ রিবেস, পাশাপাশি প্লেইন রিবেস সহ কাজ করে এবং আপনার প্রাথমিক স্ক্রিপ্ট এখন আরও ভাল কাজ করতে পারে।


0

আমি একটি সরল কিন্তু অনুরূপ ইস্যুতে ছুটছিলাম, যেখানে আমার ১) স্থানীয় শাখায় একীভূত সংঘাতের সমাধান হয়েছে, ২) আরও অনেক সামান্য কমিট যুক্ত করে কাজ চালিয়ে গেছে, ৩) পুনরায় সংশোধন করতে চেয়েছিল এবং মার্জ সংঘাতগুলি আঘাত করতে চেয়েছিল।

আমার জন্য, git rebase -p -i masterকাজ। এটি মূল দ্বন্দ্বের সমাধানের প্রতিশ্রুতি রক্ষা করেছে এবং আমাকে অন্যদের স্কোয়াশ করার অনুমতি দিয়েছে।

আশা করি যে কাউকে সাহায্য করবে!


আমি -p এর সাথে রিবেসের চেষ্টা করার সময় আমি ম্যানুয়ালি সমাধানের জন্য কয়েকটি বিবাদ পেয়েছি স্বীকার করে যে সেখানে খুব কম সংঘর্ষ হয়েছিল এবং সেগুলি আমার আগে যে সকল কোড ফাইলগুলির সাথে দ্বন্দ্ব হচ্ছিল তার চেয়ে প্রজেক্ট ফাইলে সীমাবদ্ধ ছিল। স্পষ্টতই "সংঘর্ষের সমাধানগুলি মার্জ করার জন্য সংঘাতের সমাধানগুলি বা ম্যানুয়াল সংশোধনগুলি সংরক্ষণ করা হয় না।" - stackoverflow.com/a/35714301/727345
JonoB
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.