විශේෂාංග ශාඛා නැවත භාවිතයෙන් පසු Git තල්ලු කිරීම ප්‍රතික්ෂේප කරන ලදි


953

හරි, මම හිතුවා මේක සරල වාතාවරණයක් කියලා, මට මොනවද නැති වෙලා තියෙන්නේ?

මට masterශාඛාවක් හා featureශාඛාවක් තිබේ. මම යම් වැඩක් කරමි master, සමහරක් ක්‍රියාත්මක වේ feature, පසුව තවත් සමහරක් කරන්නෙමි master. මම මේ වගේ දෙයකින් අවසන් වෙමි (ශබ්දකෝෂ අනුපිළිවෙලෙන් අදහස් කරන්නේ අනුපිළිවෙලයි):

A--B--C------F--G  (master)
       \    
        D--E  (feature)

git push origin masterදුරස්ථව masterයාවත්කාලීනව තබා ගැනීමට හෝ git push origin feature(වැඩ කරන විට feature) මගේ featureවැඩ සඳහා දුරස්ථ උපස්ථයක් පවත්වා ගැනීමට මට කිසිදු ගැටළුවක් නොමැත . මේ වන තුරු, අපි හොඳයි.

ඒත් දැන් මම rebase කිරීමට අවශ්ය featureවූ මත F--Gස්වාමියා මත අනාචාරයේ, ඒ නිසා මම git checkout featureසහ git rebase master. තවමත් හොඳ. දැන් අපට ඇත්තේ:

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

ප්රශ්නය: දත්ත උපස්ථ කිරීමට මට අවශ්ය මේ මොහොතේ නව rebased featureසමග අතු git push origin feature, තල්ලුව ප්රතික්ෂේප ගස නිසා rebasing වෙනස් කර ඇති බැවින්. මෙය විසඳිය හැක්කේ සමඟ පමණි git push --force origin feature.

මට --forceඑය අවශ්‍ය බව නොදැන මම භාවිතා කිරීමට අකමැතියි. ඉතින්, මට එය අවශ්‍යද? ප්‍රතිප්‍රහාරයෙන් අනිවාර්යයෙන්ම ඇඟවෙන්නේ ඊළඟට පූර්ණ pushවිය යුතු බවයි --force?

මෙම ලක්ෂණය ශාඛා මට කිසිම ප්රශ්නයක් තියෙනවා ඒ නිසා, වෙනත් ඕනෑම devs සමග බෙදා නොවේ තත්වාකාර , බලය තල්ලුව ද සමග මම කිසිම දත්ත අහිමි යන්නේ නෑ, ප්රශ්නය තවත් සංකල්පීය වේ.

Answers:


708

ගැටළුව වන්නේ git pushදුරස්ථ ශාඛාව ඔබේ ප්‍රාදේශීය ශාඛාවට වේගයෙන් යොමු කළ හැකි යැයි උපකල්පනය කිරීමයි, එනම් දේශීය හා දුරස්ථ ශාඛා අතර ඇති සියලුම වෙනස දේශීය වශයෙන් නව ගිවිසුම් කිහිපයක් තිබීමයි.

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

ඔබ කොමිස් සිදු කරන විට git rebaseඩී සහ ඊ නව පදනමට යොදන අතර නව කොමිස් නිර්මාණය වේ. එයින් අදහස් වන්නේ නැවත ලබා දීමෙන් පසු ඔබට එවැනි දෙයක් ඇති බවයි:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

එවැනි තත්වයක් තුළ දුරස්ථ ශාඛාව වේගයෙන් දේශීය වෙත යොමු කළ නොහැක. න්‍යායාත්මකව දේශීය ශාඛාව දුරස්ථව ඒකාබද්ධ කළ හැකි වුවද (පැහැදිලිවම ඔබට එය අවශ්‍ය නොවේ), නමුත් git pushවේගයෙන් ඉදිරියට යන විට පමණක් එය විසි කිරීම හා දෝෂය ඇතිවේ.

කුමක් --forceවිකල්පය පමණක් දුරස්ථ ශාඛා රාජ්ය නොසලකා හරිමින් හා එය පිහිටුවීම කරන්නේ ඔබ එය තුලට තල්ලු කරනවා නසාගන්නවා. එබැවින් git push --force origin feature-branchහුදෙක් origin/feature-branchදේශීය සමඟ අභිබවා යයි feature-branch.

මගේ මතය අනුව, විශේෂාංග ශාඛා නැවත ප්‍රතිස්ථාපනය කිරීම masterසහ ඒවා නැවත දුරස්ථ ගබඩාවට තල්ලු කිරීම ඔබ එම ශාඛාවේ වැඩ කරන එකම තැනැත්තා වන තාක් කල් හරි ය.


72
ඇත්තම කිව්වොත්, විශේෂාංග ශාඛාවේ මුල් පිටපත නැවත ප්‍රතිස්ථාපනය කළ එක් ආකාරයකට ඇදගෙන ඒකාබද්ධ කිරීමෙන් නැවත ප්‍රතිස්ථාපනය කිරීමේ සම්පූර්ණ අදහසම ඉවත් වේ.
KL-7

24
සමහර විට මම ඔබව නිවැරදිව තේරුම් නොගත්තෙමි, නමුත් ඔබ විශේෂාංග ශාඛාව අදින්නේ නම්, එය නැවුම් ප්‍රධාන ශාඛාවට නැවත ප්‍රතිස්ථාපනය කළහොත්, ඔබට එය බලහත්කාරයෙන් පසුපසට තල්ලු කළ නොහැක, මන්ද විශේෂාංග ශාඛාවේ දුරස්ථ අනුවාදය ඔබේ නව වෙත වේගයෙන් යොමු කළ නොහැකි බැවිනි. (ප්‍රතිනිර්මාණය කරන ලද) විශේෂාංග ශාඛාවේ අනුවාදය. OP ඔහුගේ ප්‍රශ්නයේ විස්තර කර ඇත්තේ එයයි. නැවත ප්‍රතිස්ථාපනය කිරීමෙන් පසුව, නමුත් තල්ලු කිරීමට පෙර, ඔබ git pull feature-branchමෙම ක්‍රියාව මඟින් නව ඒකාබද්ධ කිරීමේ බැඳීමක් ජනනය කරනු ඇත (විශේෂාංග ශාඛාවේ දුරස්ථ හා දේශීය අනුවාදයන් ඒකාබද්ධ කිරීමෙන්). එබැවින් එක්කෝ ඔබට නැවත ප්‍රතිස්ථාපනය කිරීමෙන් පසු අනවශ්‍ය ඒකාබද්ධ කිරීමක් ලැබෙනු ඇත, නැතහොත් ඔබ තල්ලු කරයි --force.
KL-7

6
අහ්, මම හිතන්නේ මට තේරුණා. ඔබ විස්තර කරන්නේ මාක් ලෝන්ගෙයාර්ගේ පිළිතුරට සමාන ප්‍රවේශයකි. නමුත් එය ඒකාබද්ධ කිරීමේ බැඳීමක් ජනනය කරයි. සමහර අවස්ථාවල එය ප්‍රයෝජනවත් විය හැකි නමුත්, push --forceකිසිදු ඒකාබද්ධ කිරීමකින් තොරව ඉතිහාසය රේඛීයව තබා ගැනීම සඳහා මම බොහෝ විට මගේම විශේෂාංග ශාඛා තුළ නැවත භාවිතා කරමි (එබැවින් ගැටළුවක් නොවේ).
KL-7

11
“බල තල්ලු කිරීම” සමඟ ඇති කරදරය නම්, ඔබට සැබවින්ම “ලිහිල් දේවල්” (පෙර කළ හැකි), ඕනෑම අනුවාද පාලන පද්ධතියක සාමාන්‍යයෙන් කළ නොහැකි දෙයක් that එම හේතුව නිසා අවම වශයෙන් එක් “මාස්ටර්-ඊෂ්” ශාඛාවක්වත් තිබිය යුතුය. බල-තල්ලු කිරීම් නොකිරීමට , විභව හානිය සීමා කිරීමට සැකසුම් . (පහත සඳහන් ඕනෑම එකක් නම් කරන්න: කෝපාවිෂ්ට / සේවයෙන් පහ කළ සේවකයින්, තමන්ගේම මෝඩකම, වෙහෙසට පත්වූ සහ වැඩිපුර වැඩ කරන 'තීරණ' ...).
ෆ්‍රෑන්ක් නොක්

13
--force-with-lease@ හාර්දේව් යෝජනා කළ පරිදි එය හොඳ විකල්පයකි
augustorsouza

500

-F හෝ --force භාවිතා කරන්නන් වෙනුවට සංවර්ධකයින් භාවිතා කළ යුතුය

--force-with-lease

මන්ද? එය හොඳ අදහසක් වන වෙනස්කම් සඳහා දුරස්ථ ශාඛාව පරික්ෂා කරන බැවිනි. ජේම්ස් සහ ලීසා එකම විශේෂාංග ශාඛාවක වැඩ කරන අතර ලීසා කැපවීමක් ඇති කර ඇතැයි සිතමු. ජේම්ස් දැන් සිය ප්‍රාදේශීය ශාඛාව නැවත ප්‍රතික්ෂේප කරන අතර තල්ලු කිරීමට උත්සාහ කරන විට එය ප්‍රතික්ෂේප කරනු ලැබේ. ඇත්ත වශයෙන්ම ජේම්ස් සිතන්නේ මෙය නැවත ප්‍රතිස්ථාපනය කිරීම හා බලකාය භාවිතා කිරීම නිසා වන අතර ලීසාගේ සියලු වෙනස්කම් නැවත ලියනු ඇත. ජේම්ස් --force-with-lease භාවිතා කළේ නම්, වෙනත් අයෙකු විසින් කරන ලද කොමිස් ඇති බවට ඔහුට අනතුරු ඇඟවීමක් ලැබෙනු ඇත. ප්‍රතිප්‍රහාරයකින් පසු තල්ලු කිරීමේදී කිසිවෙකු --force-with-lease වෙනුවට --force භාවිතා කරන්නේ මන්දැයි මම නොදනිමි.


36
විශිෂ්ට පැහැදිලි කිරීමක්. git push --force-with-leaseමට පොකුරක් බේරුවා.
ckib16

5
මෙය ප්‍රයෝජනවත් අදහස් දැක්වීමකි, නමුත් ඇත්ත වශයෙන්ම ප්‍රශ්නයට පිළිතුරක් නොවේ.
ඩලින්

4
මෙය පිළිතුරයි, ස්වාමියාට / සංවර්ධනයට නැවත පැමිණීම ගැටළුවක් නිර්මාණය කරයි, --force-with-lease පවතින්නේ මේ නිසාය.
තමීර් ඩැනියලි

3
මෙය පිළිගත් පිළිතුර විය යුතුය. විස්තර කර ඇති ගැටළුව හරියටම විසඳයි - මේ අතරතුර වෙනත් අයෙකු සිදු කර ඇත්නම් බල නොකර තල්ලු කිරීම.
ලුසියාන්

3
මම හිතන්නේ පිළිගත් පිළිතුර සහ මෙය එක ප්‍රශ්නය ආමන්ත්‍රණය කරයි. පිළිගත් පිළිතුර ඔබට බල කිරීමට අවශ්‍ය වන්නේ ඇයිද යන්න පැහැදිලි කරයි. --force-with-leaseභාවිතා කිරීමට ඇති උනන්දුව ආමන්ත්‍රණය කරන්නේ මන්දැයි මෙය පැහැදිලි කරයි--force
ජෙෆ් අපරෙටි

51

මම ඒ වෙනුවට "checkout -b" භාවිතා කරන අතර එය තේරුම් ගැනීම පහසුය.

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

ඔබ මකා දැමූ විට විවිධ SHA හැඳුනුම්පත් අඩංගු පිටවන ශාඛාවකට තල්ලු වීම වළක්වයි. මම මෙම නඩුවේ දුරස්ථ ශාඛාව පමණක් මකා දමමි.


6
මෙය ඉතා හොඳින් ක්‍රියාත්මක වේ, විශේෂයෙන් ඔබේ කණ්ඩායමට සියලු git push --force විධාන ප්‍රතික්ෂේප කරන git කොක්කක් තිබේ නම්.
රයන් තේම්ස්

1
එය හොඳින් ක්‍රියාත්මක වීම ගැන ඔබට ස්තූතියි. වඩා හොඳින් තේරුම් ගැනීම සඳහා මා කියවූ වැඩි විස්තර මෙන්න. ඔබට බල තල්ලුවක් කිරීමට අවශ්‍ය නැති විට හෝ කළ නොහැකි විට මෙය ඉතා ප්‍රයෝජනවත් වේ. දුරස්ථ ශාඛා මකා දැමීම සහ නැවත සකස් කිරීම
රාජ්කොන්

5
මෙය සමාන push --forceප්‍රති come ලයක් ඇත , එබැවින් git repo වලක්වා ගත හැකි ක්‍රමයක් පමණි --force. එනිසා, මෙය කිසි විටෙකත් හොඳ අදහසක් යැයි මම නොසිතමි - එක්කෝ රෙපෝ අවසර දෙයි push --force, නැතහොත් හොඳ හේතුවක් නිසා එය අක්‍රීය කරයි. --forceදුරස්ථ repo හි අක්‍රීය කර ඇත්නම් නබිගේ පිළිතුර වඩාත් යෝග්‍ය වේ, මන්ද එය වෙනත් සංවර්ධකයින්ගේ කොමිස් අහිමි වීමේ අවදානමක් හෝ වෙනත් ආකාරයකින් ගැටළු ඇති කරයි.
ලෝගන් පිකප්

20

මෙයට එක් විසඳුමක් නම්, msysGit හි ප්‍රතිස්ථාපන ඒකාබද්ධ කිරීමේ ස්ක්‍රිප්ට් එක කරන දේ කිරීමයි - ප්‍රතිප්‍රහාරයෙන් පසුව, පැරණි හිස featureසමඟ ඒකාබද්ධ කරන්න -s ours. ඔබ කැපවීමේ ප්‍රස්ථාරයෙන් අවසන් වේ:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... ඔබේ තල්ලුව featureවේගයෙන් ඉදිරියට යනු ඇත.

වෙනත් වචන වලින් කිවහොත්, ඔබට මෙය කළ හැකිය:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(පරීක්ෂා කර නැත, නමුත් මම හිතන්නේ එය නිවැරදියි ...)


28
භාවිතා කිරීමට වඩාත්ම පොදු හේතුව git rebase( masterඔබේ විශේෂාංග ශාඛාවට නැවත ඒකාබද්ධ කිරීම වෙනුවට ) පිරිසිදු රේඛීය කොමිස් ඉතිහාසය සෑදීම බව මම විශ්වාස කරමි . ඔබේ ප්‍රවේශයත් සමඟ ඉතිහාසය තවත් නරක අතට හැරේ. ප්‍රතිනිර්මාණය කිරීම ඔවුන්ගේ පෙර සංස්කරණ ගැන කිසිදු සඳහනක් නොමැතිව නව කොමිස් නිර්මාණය කරන බැවින් මෙම ඒකාබද්ධ කිරීමේ ප්‍රති result ලය ප්‍රමාණවත් වනු ඇතැයි මට විශ්වාස නැත.
KL-7

6
@ KL-7: මෙහි සමස්ත කරුණ merge -s oursනම්, එය පෙර අනුවාදයට මව් යොමු කිරීමක් කෘතිමව එකතු කිරීමයි. නිසැකවම, ඉතිහාසය පිරිසිදුව නොපෙනේ, නමුත් featureශාඛාවේ තල්ලුව බලෙන් පැටවීමෙන් ප්‍රශ්න කරන්නා විශේෂයෙන් කරදර වන බවක් පෙනේ , මෙය ඒ වටා එයි. ඔබට නැවත ප්‍රතිස්ථාපනය කිරීමට අවශ්‍ය නම්, එය වැඩි හෝ අඩු එකක් හෝ වෙනත් ය. :) වඩාත් පොදුවේ ගත් කල, msysgit ව්‍යාපෘතිය මෙය කිරීම සිත්ගන්නා සුළු යැයි මම සිතමි ....
මාර්ක් ලොන්ගෙයාර්

@ KL-7: අහම්බෙන්, මම ඔබේ පිළිතුර + 1 කර ඇති අතර එය පැහැදිලිවම නිවැරදි පිළිතුරයි - මම සිතුවේ මෙයද සිත්ගන්නාසුළු විය හැකි බවයි.
මාර්ක් ලොන්ගෙයාර්

එය අනිවාර්යයෙන්ම සිත්ගන්නා සුළුය, අවම වශයෙන් මට. ඔබට ස්තුතියි. මම මීට oursපෙර උපාය මාර්ග දැක ඇති නමුත් එය අපේ ශාඛාවේ වෙනස්කම් භාවිතා කර ඒවා ස්වයංක්‍රීයව විසඳා ගැනීමෙන් ගැටුම් තත්වයන්ට පමණක් අදාළ යැයි මම සිතුවෙමි. එය වෙනස් ආකාරයකින් ක්‍රියා කරයි. ඔබට නැවත සංස්කරණය කරන ලද අනුවාදයක් අවශ්‍ය නම් (උදා: රෙපෝ නඩත්තු කරන්නාට එය පිරිසිදුව යෙදීම සඳහා master) නමුත් බලෙන් තල්ලු කිරීමෙන් වැළකී සිටීමට අවශ්‍ය නම් (ඒ නිසා වෙනත් පීපීඑල් බොහෝමයක් ඔබේ විශේෂාංග ශාඛාව භාවිතා කරන්නේ නම්) ඒ ආකාරයෙන් වැඩ කිරීම ඉතා ප්‍රයෝජනවත් වේ .
KL-7

L KL-7 "අපගේ ශාඛාවේ වෙනස්කම් භාවිතා කරමින් ඒවා ස්වයංක්‍රීයව නිරාකරණය කිරීමෙන් ගැටුම් තත්වයන්ට පමණක් අදාළ වේ යැයි මම සිතුවෙමි." මෙය ඉතා පැරණි තනතුරක් බව මම දනිමි, නමුත් එය යම් පැහැදිලි කිරීමක් දරයි. ඔබ විස්තර කරන දේ "අපේ" විකල්පය "පුනරාවර්තන" (පෙරනිමි) උපාය මාර්ගයට ගැලපේ . UI හි "අපේ" යන වචනය අධික ලෙස පැටවීම අවාසනාවකි. (උපාය මාර්ගික විකල්පයන් -X
ආගන්

16

මෙම ශාඛාවේ ඇත්තේ එක් සංවර්ධකයෙකු පමණක් බව සමහර විට හෝ නොවිය හැකිය, එය දැන් (ප්‍රතිප්‍රහාරයෙන් පසුව) මූලාරම්භය / අංගය සමඟ නොගැලපේ.

එනිසා පහත දැක්වෙන අනුක්‍රමය භාවිතා කිරීමට මම යෝජනා කරමි:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

ඔව්, නව ශාඛාව, මෙය බලකායකින් තොරව විසඳිය යුතුය, එය සාමාන්‍යයෙන් විශාල අඩුපාඩුවක් යැයි මම සිතමි.


3
කීමට කණගාටුයි නමුත්: “දැනට පවතින ඒවා බලහත්කාරයෙන් ඉක්මවා යාම වළක්වා ගැනීම සඳහා“ ශාඛා උත්පාදනය කිරීම “හුදකලා විශේෂාංග සංවර්ධකයින්ට” (අභිබවා යා හැකි) හෝ විශේෂාංග ශාඛාවක වැඩ කරන බහු පුද්ගලයන්ට උදව් නොකරයි (එම ශාඛාව “වර්ධක” සන්නිවේදනය කිරීම සහ පැවසීම යන්න, ජනතාව). - එය අනුවාද පද්ධතියක් තුළ අත්පොත අනුවාදය (“thesis_00.doc, thesis_01.doc, ...”) වැනි ය ...
ෆ්‍රෑන්ක් නොක්

2
ප්ලස්, ඔබ එක් ශාඛා නාමයකින් ගිතුබ් පීආර් විවෘත කර ඇති විට මෙය උදව් නොකරයි, ඔබ තල්ලු කළ නව ශාඛා නාමය සඳහා නව පීආර් එකක් සෑදිය යුතුය.
gprasant

1
ranfrankee මගේ අත්දැකීම් වලින් අඩක් ඇත්ත. හුදකලා සංවර්ධකයෙකු සඳහා, ඔව්, බල කිරීම තල්ලු කිරීම පහසුය, නමුත් එය පසුව ඔබට දෂ්ට කළ හැකි පුරුද්දකි. + අළුත් දේව් කෙනෙක් දැන් එකතු වුනාද? හෝ --hard reset භාවිතා නොකරන සමහර CI පද්ධතියක් විය හැකිද? කණ්ඩායමක් සහයෝගයෙන් කටයුතු කිරීම සඳහා, නව ශාඛා නාමය සන්නිවේදනය කිරීම පහසුය, මෙය පහසුවෙන් තිර රචනය කළ හැකිය + කණ්ඩායමක් සඳහා, මම යෝජනා කරන්නේ දේශීයව නැවත ප්‍රතිස්ථාපනය කිරීමට හෝ ශාඛාව ඒකාබද්ධ වීමට සූදානම් වන විට මිස එදිනෙදා වැඩ වලදී නොවේ , ප්‍රති commit ලයක් ලෙස ප්‍රතිචක්‍රීකරණය / ඒකාබද්ධ කිරීමේ ගැටුම් සමඟ කටයුතු කිරීමට වඩා අමතර කැපවීම අඩු කරදරයකි.
JAR.JAR.beans

PR සඳහා gprasant, නැවතත්, මම සිතන්නේ මෙය නැවත ප්‍රතිස්ථාපනය කිරීම වැරදියි, මට ඇත්ත වශයෙන්ම අවශ්‍ය වන්නේ PR නිවැරදි කිරීම් සමඟ තනි කැපවීම් දැකීමටයි. නැවත ගෙවීමක් (ස්කොෂ්) සිදුවිය යුත්තේ මාස්ටර් සමඟ ඒකාබද්ධ කිරීමේ කොටසක් ලෙස වන අතර PR සියල්ල අවසන් කර සූදානම් වූ විට (එබැවින් නව PR එකක් විවෘත කිරීම අවශ්‍ය නොවේ).
JAR.JAR.beans

13

අනෙක් අය ඔබේ ප්‍රශ්නයට පිළිතුරු දී ඇත. ඔබ ශාඛාවක් නැවත ප්‍රතිස්ථාපනය කරන්නේ නම්, එම ශාඛාව තල්ලු කිරීමට ඔබට බල කළ යුතුය.

ප්‍රතිස්ථාපනය සහ හවුල් ගබඩාවක් සාමාන්‍යයෙන් නොගැලපේ. මෙය ඉතිහාසය නැවත ලිවීමකි. අනෙක් අය එම ශාඛාව භාවිතා කරන්නේ නම් හෝ එම ශාඛාවෙන් අතු බෙදී ඇත්නම් නැවත ප්‍රතිස්ථාපනය කිරීම අප්‍රසන්න වනු ඇත.

පොදුවේ ගත් කල, දේශීය ශාඛා කළමනාකරණය සඳහා නැවත ගෙවීම හොඳින් ක්‍රියාත්මක වේ. පැහැදිලි ඒකාබද්ධ කිරීම් (--no-ff) සමඟ දුරස්ථ ශාඛා කළමනාකරණය වඩාත් හොඳින් ක්‍රියා කරයි.

විශේෂාංග ශාඛාවකට මාස්ටර් ඒකාබද්ධ කිරීමෙන් ද අපි වැළකී සිටිමු. ඒ වෙනුවට අපි ප්‍රගුණ කිරීමට ප්‍රතිස්ථාපනය කරන නමුත් නව ශාඛා නාමයකින් (උදා: අනුවාද උපසර්ගයක් එක් කිරීම). හවුල් ගබඩාවේ නැවත ප්‍රතිස්ථාපනය කිරීමේ ගැටළුව මෙය වළක්වයි.


7
කරුණාකර ඔබට උදාහරණයක් එකතු කළ හැකිද?
තර්මෙක්

13

බල තල්ලුව මග හැරීමේ මගේ ක්‍රමය නම් නව ශාඛාවක් නිර්මාණය කිරීම සහ එම නව ශාඛාවේ අඛණ්ඩ වැඩ කටයුතු කිරීම සහ යම් ස්ථාවරත්වයකින් පසුව නැවත ප්‍රතිස්ථාපනය කළ පැරණි ශාඛාව ඉවත් කිරීම:

  • පරීක්ෂා කළ ශාඛාව දේශීයව නැවත ප්‍රතිස්ථාපනය කිරීම
  • ප්‍රතිසංස්කරණය කරන ලද ශාඛාවේ සිට නව ශාඛාවකට ශාඛා කිරීම
  • එම ශාඛාව දුරස්ථයට නව ශාඛාවක් ලෙස තල්ලු කිරීම. සහ දුරස්ථව පැරණි ශාඛාව මකා දැමීම

1
මෙම විකල්පය සඳහා ආදරය නැත්තේ ඇයි? එය අනිවාර්යයෙන්ම පිරිසිදු, සරලම, ආරක්ෂිතයි.
cdmo

මක්නිසාද යත් මට ශාඛා නාමය නිරීක්ෂණය කරන පද්ධති 200 ක් පමණ ඇති අතර, එය කාර්යය සඳහා නිශ්චිත නමක් විය යුතු අතර, මම ශාඛා නැවත නම් කිරීම ආරම්භ කළහොත් සෑම තල්ලුවක්ම නම් කරමි.
තමීර් ඩැනියලි

AmTamirDaniely මම උත්සාහ කර නැත, නමුත් එකම පැරණි නම සහිත නව ශාඛාව තල්ලු කිරීමට හා තල්ලු කිරීමට පෙර පැරණි ශාඛාව (දුරස්ථ සිට) මකා දැමීම ඔබේ ගැටලුව විසඳන්නේද?
නබි

2
Ab නබි එය හරියටම --force-with-lease කරන්නේ, එය ඔබගේ නොවන නව කොමිස් නොමැති බව තහවුරු කිරීම හැර.
තමීර් ඩැනියලි

8

සමඟ වැරදි දේ git merge masterමත featureශාඛා? මෙය ඔබ කළ කාර්යය ප්‍රධාන ශාඛාවෙන් වෙන්ව තබා ගනී.

A--B--C------F--G
       \         \
        D--E------H

සංස්කරණය කරන්න: සමාවෙන්න ඔබේ ගැටළු ප්‍රකාශය කියවා නැත. ඔබ සිදු කළ පරිදි ඔබට බලය අවශ්‍ය rebaseවේ. ඉතිහාසය වෙනස් කරන සියලුම විධානයන්ට --forceතර්කය අවශ්‍ය වේ. මෙය ඔබට රැකියාව අහිමි වීම වැළැක්වීමට අසමත් වීමකි (පැරණි Dහා Eනැති වී යනු ඇත).

ඔබ සිදු ඒ නිසා git rebase(අර්ධ වශයෙන් ලෙස සඟවා වුවත් වැනි ගස පෙනුම සිදු කරන Dහා Eඑය නම් ශාඛාව තවදුරටත්):

A--B--C------F--G
       \         \
        D--E      D'--E'

ඒ නිසා, ඔබගේ නව තල්ලු කිරීමට උත්සාහ කරන විට feature(සමග ශාඛා D'හා E'එය), ඔබ අහිමි Dහා E.


3
එහි කිසිදු වරදක් නැත, එය ක්‍රියාත්මක වන බව මම දනිමි. එය මට අවශ්‍ය දේ පමණක් නොවේ. මා කීවාක් මෙන්, ප්‍රශ්නය ප්‍රායෝගිකව වඩා සංකල්පීය ය.
යුවල් ඇඩම්

4

මට පහසු පියවර අනුගමනය කිරීම සඳහා:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

ඉහත සියල්ල කළ පසු, අපට පහත දැක්වෙන විධානය මඟින් myFeature ශාඛාව මකා දැමිය හැකිය:

git push origin --delete myFeature

3

පහත සඳහන් දේ මට ප්‍රයෝජනවත් වේ:

git push -f origin branch_name

එය මගේ කේත කිසිවක් ඉවත් නොකරයි.

නමුත්, ඔබට මෙය වළක්වා ගැනීමට අවශ්‍ය නම් ඔබට පහත සඳහන් දෑ කළ හැකිය:

git checkout master
git pull --rebase
git checkout -b new_branch_name

එවිට ඔබට ඔබගේ සියලු කැපවීම් නව ශාඛාවට චෙරි-තෝරා ගත හැකිය. git cherry-pick COMMIT ID ඉන්පසු ඔබේ නව ශාඛාව තල්ලු කරන්න.


5
-fසඳහා අන්වර්ථයකි --force, හැකි නම් එය වළක්වා ගැනීමට ප්‍රශ්නය උත්සාහ කරයි.
epochengine

1

OP ගැටලුව තේරුම් ගෙන ඇති පරිදි, වඩා හොඳ විසඳුමක් සොයයි ...

මෙය පුරුද්දක් ලෙස කෙසේද?

  • සැබෑ අංග-සංවර්ධන ශාඛාවෙහි සිටින්න (ඔබ කිසි විටෙකත් ප්‍රතිප්‍රහාර එල්ල නොකරන අතර බලහත්කාරයෙන් තල්ලු කරයි, එබැවින් ඔබේ සෙසු විශේෂාංග සංවර්ධකයින් ඔබට වෛර නොකරයි). මෙන්න, නිතිපතා ඒකාබද්ධයෙන් ප්රධාන සිට එම වෙනස්කම් අල්ලා ගන්න. අවුල් සහගත ඉතිහාසය , ඔව්, නමුත් ජීවිතය පහසු වන අතර කිසිවෙකු ඔහුගේ කාර්යයට බාධා නොකරයි.

  • දෙවන අංග සංවර්ධනය කිරීමේ ශාඛාවක් තබා ගන්න, එහිදී එක් අංග කණ්ඩායම් සාමාජික රෙගුලාසියක් සියළුම අංගයන් තල්ලු කරයි, සැබවින්ම ප්‍රතික්ෂේප කරනු ලැබේ, සැබවින්ම බල කෙරෙයි. ඒ නිසා තරමක් මෑත කාලීන මාස්ටර් කැපවීමක් මත පාහේ පිරිසිදු ලෙස පදනම් වේ. විශේෂාංගය සම්පුර්ණ වූ පසු, එම ශාඛාව මාස්ටර් මතට තල්ලු කරන්න.

මෙම ක්‍රමය සඳහා දැනටමත් රටා නමක් තිබිය හැකිය.


0

නවතම මාස්ටර්ට ඉහළින් මාස්ටර් සහ රීබේස් විශේෂාංග ශාඛාවේ නව වෙනස්කම් ලබා ගන්න

git checkout master
git pull
git checkout feature
git pull --rebase origin master
git push origin feature
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.