මා කරන සෑම බැරෑරුම් ගිතුබ් රිපෝ එකක්ම මගේ කැපවීම් තනි කැපවීමකට ලක් කිරීමට අවශ්‍ය යැයි ඉල්ලා සිටින්නේ ඇයි?

මම සිතුවේ git ලොගය එහි ඇති බැවින් ඔබට ඔබේ ඉතිහාසය පරීක්ෂා කර බලා සිදු වූ වෙනස්කම් හරියටම දැක ගත හැකි වනු ඇත, නමුත් එය කොටු කිරීම ඉතිහාසයෙන් ඉවතට ඇද දමා ඒ සියල්ල එක කැපවීමකට ඇද දමයි. කාරණය කුමක්ද?

මෙය "කල් ඇතිව කැපවීම සහ බොහෝ විට කැපවීම" යන මන්ත්‍රයට පටහැනි බව පෙනේ.

එවිට ඔබට පැහැදිලි හා සංක්ෂිප්ත git ඉතිහාසයක් ඇති අතර එමඟින් සිදු කරන ලද වෙනස්කම් සහ එයට හේතු පැහැදිලිව හා පහසුවෙන් ලේඛනගත කළ හැකිය.

උදාහරණයක් ලෙස මා සඳහා සාමාන්‍ය 'නොකැඩූ' git ලොග් එකක් පහත පරිදි විය හැකිය:

7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
787g8fgf78... hotfix for #5849564648
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

මොන අවුලක්ද!

එහෙත් මේ සඳහා වන පණිවිඩ කෙරෙහි මඳක් වැඩි අවධානයක් යොමු කරමින් වඩාත් ප්‍රවේශමෙන් කළමනාකරණය කරන ලද සහ ඒකාබද්ධ කරන ලද git ලොග් එකක් මෙන් පෙනේ:

7hgf8978g9... 8483948393 Added new slideshow feature
787g8fgf78... 5849564648 Hotfix for android display issue
9080gf6567... 6589685988 Implemented pop-up to select language

සාමාන්‍යයෙන් ස්කොෂ් කිරීමේ කාරණය ඔබට දැකිය හැකි යැයි මම සිතමි. ඉල්ලීම් අදින්නට ද එම මූලධර්මයම අදාළ වේ - ඉතිහාසයේ කියවීමේ හැකියාව. ඔබ දැනටමත් සිය ගණනක් හෝ දහස් ගණනක් කොමිස් ඇති බැඳීම් ලොගයකට එකතු කරමින් සිටින අතර මෙය වර්ධනය වන ඉතිහාසය කෙටියෙන් හා සංක්ෂිප්තව තබා ගැනීමට උපකාරී වේ.

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

විශේෂිත ක්‍රියාකාරී අවධීන් නියෝජනය කරන ප්‍රධාන සන්ධිස්ථාන තිබේ නම්, එක් අංගයක් / කාර්යයක් / දෝෂයක් සඳහා එකකට වඩා කැපවීම තවමත් හරි ය. කෙසේ වෙතත්, මෙය බොහෝ විට ඉස්මතු කර දැක්විය හැක්කේ සංවර්ධනය වෙමින් පවතින ටිකට් පත 'ඉතා විශාල' වන අතර එය තනිවම කළ හැකි කුඩා කැබලිවලට බෙදිය යුතුය.

8754390gf87... Implement feature switches

"වැඩ 1 කෑල්ලක්" වගේ. එක්කෝ ඒවා පවතී හෝ නැත! එය බිඳ දැමීම අර්ථවත් බවක් නොපෙනේ. කෙසේ වෙතත් අත්දැකීම් මට පෙන්වා දී ඇත්තේ (සංවිධානාත්මක ප්‍රමාණය හා සංකීර්ණත්වය අනුව) වඩාත් කැටිති මාර්ගයක් විය හැකි බවයි:

fgfd7897899... Add field to database, add indexes and a trigger for the dw group
9458947548g... Add 'backend' code in controller for when id is passed in url.
6256ac24426... Add 'backend' code to make field available for views.
402c476edf6... Add feature to UI

කුඩා කෑලි වලින් අදහස් කරන්නේ පහසු කේත සමාලෝචන, පහසු ඒකක පරීක්ෂාව, qa සඳහා වඩා හොඳ අවස්ථාව, තනි වගකීම් මූලධර්මයට වඩා හොඳ පෙළගැස්වීම යනාදියයි.

එවැනි ස්කොෂ් සැබවින්ම කළ යුත්තේ කවදාද යන්න පිළිබඳ ප්‍රායෝගිකත්වය සඳහා, මූලික වශයෙන් එකිනෙකට වෙනස් වූ අදියර දෙකක් තිබේ

• ඔබේ සංවර්ධනය, උදා
• ඔබගේ කාර්යය ප්‍රධාන ශාඛාවට එකතු කරන ලදි, උදා

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

--no-ffමාස්ටර් සමඟ ඒකාබද්ධ කිරීමේදී භාවිතා කිරීම ඒකාබද්ධ කිරීම සඳහා එක් කැපවීමක් භාවිතා කරන අතර ඉතිහාසය (ශාඛාවේ) ආරක්ෂා කරයි. සමහර සංවිධාන මෙය හොඳම භාවිතයක් ලෙස සලකයි. ඊට වැඩි බලන්න https://stackoverflow.com/q/9069061/631619 දී ප්රායෝගිකව ඔබ ද දකිනු ඇත git logඑය එහිදී --no-ffසිදු තොරව බැවින්ද, (පමණක් සිදු කළ විට) හිස මුදුනේ, සිදු නවතම වනු ඇත --no-ffඑය විය හැකිය දිනයන් සහ වෙනත් කොමිස් මත පදනම්ව ඉතිහාසයේ තව දුරටත් පහත වැටේ.

බොහෝ විට PR එකක් අදින පුද්ගලයා "එකතු කරන ලද විශේෂාංග X" වල ශුද්ධ බලපෑම ගැන සැලකිලිමත් වන අතර "මූලික සැකිලි, දෝෂ නිරාකරණ X, ක්‍රියාකාරීත්වය එක් කිරීම, අදහස්වල ස්ථාවර යතුරු ලියනය, සකස් කළ දත්ත පරිමාණ පරාමිතීන්, හැෂ්මැප් වඩා හොඳින් ක්‍රියා කරයි ලැයිස්තුව "... විස්තර මට්ටම

ඔබේ කොමිස් 16 වඩාත්ම නිරූපණය කරන්නේ 1 "එකතු කරන ලද විශේෂාංග X, X භාවිතා කිරීම සඳහා නැවත සාදනු ලැබූ Z" වෙනුවට කොමිට් 2 කින් බව ඔබ සිතන්නේ නම්, එය කොමිස් 2 ක් සහිත PR එකක් යෝජනා කිරීම හොඳය, නමුත් එය යෝජනා කිරීම වඩාත් සුදුසුය. එම අවස්ථාවේ දී වෙනම prs 2 ක් (repo තවමත් තනි කැපවීම් pr හි අවධාරනය කරන්නේ නම්)

මෙය ඔබේ රෙපෝ හි මෙන් “කල් ඇතිව හා බොහෝ විට කරන්න” යන මන්ත්‍රයට පටහැනි නොවේ, ඔබ සංවර්ධනය කරමින් සිටියදී ඔබට තවමත් කැටිති තොරතුරු ඇත, එබැවින් ඔබට වැඩ අහිමි වීමේ අවම අවස්ථාවක් ඇති අතර අනෙක් අයට සමාලෝචනය / අදින්න / යෝජනා කළ හැකිය නව PR සංවර්ධනය කරන අතරතුර pr ඔබේ කාර්යයට විරුද්ධයි.

මට පෙනෙන දෙයින් ප්‍රධාන හේතුව පහත පරිදි වේ:

• අදින්න ඉල්ලීම් ඒකාබද්ධ කිරීම සඳහා වන GitHub UI (2015 ඔක්තෝබර්) බැඳීම් පණිවිඩයේ පළමු පේළිය සංස්කරණය කිරීමට ඔබට ඉඩ නොදේ. Merge pull request #123 from joebloggs/fix-snafoo
• මෙම සිදු ඉතිහාසය පිරික්සීමේදී සඳහා GitHub UI දැනට ඔබ ශාඛාව ඉතිහාසය බැලීමට ඉඩ දෙන්නේ නැහැ --first-parentසහජීවන
• ගොනුවක ඇති දෝෂය දෙස බැලීමේ GitHub UI මඟින් ඔබට ගොනුවේ දොස් පැවරීම දෘෂ්ටි කෝණයෙන් බැලීමට ඉඩ නොදේ --first-parent(මෙය ස්ථාවර කර ඇත්තේ Git 2.6.2 හි පමණක් බව සලකන්න, එබැවින් අපට එය නොතිබීම ගැන GitHub ට සමාව දිය හැකිය. පවතින)

එබැවින් ඔබ ඉහත අවස්ථා තුනම ඒකාබද්ධ කළ විට, නොකැඩූ බැඳීම් ඒකාබද්ධ කරන ලද තත්වයක් ඔබට ලැබෙනුයේ GitHub UI වෙතින් අවලස්සන ලෙසය.

චතුරස්රාකාර කොමිස් සමඟ ඔබගේ ඉතිහාසය සමාන වනු ඇත

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... Hotfix for android display issue
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... Implemented pop-up to select language

කොටු නොවී ඉතිහාසය කෙසේ වෙතත් පෙනෙනු ඇත

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... hotfix for #5849564648
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

ඔබ PR හඹා යාමේ බොහෝ කැපවීම් ඇති විට, වෙනසක් සිදු වූ තැන ඔබ GitHub UI භාවිතා කිරීම සීමා කළහොත් එය බියකරු සිහිනයක් විය හැකිය .

නිදසුනක් ලෙස, ගොනුවක කොතැනක හෝ ශුන්‍ය දර්ශකයක් යොමු කර ඇති බව ඔබට පෙනේ ... එබැවින් ඔබ පවසන්නේ "කවුද මෙය කළේ, කවදාද? කුමන නිකුතු අනුවාද වලට බලපාන්නේ?". එවිට ඔබ GitHub UI හි දෝෂාරෝපණය වෙත ඇවිද යන අතර පේළිය වෙනස් කර ඇති බව ඔබට පෙනේ789fdfffdf... "ඔහ්, නමුත් තත්පරයක් රැඳී සිටින්න, එම රේඛාව එහි කේතයේ ඉතිරි කේතයට ගැලපෙන පරිදි වෙනස් කර ඇත", එබැවින් දැන් ඔබ එම ගොනුව සඳහා ගස් තත්වයට යා යුතු අතර මවුපියන්ගේ කැපවීම සහ නැවත බැලීම දොස් පැවරීමේ පිටුව ... අවසානයේදී ඔබ බැඳීම සොයා ගනී ... එය මාස 6 කට පෙර සිදු වූ කැපවීමකි ... "ඔහ් **** මෙය මාස 6 ක් තිස්සේ පරිශීලකයින්ට බලපානු ඇත" ඔබ කියනවා ... ආ, නමුත් රැඳී සිටින්න, එම කැපවීම ඇත්ත වශයෙන්ම පුල් ඉල්ලීමක වූ අතර එය ඊයේ පමණක් ඒකාබද්ධ කරන ලද අතර කිසිවෙකු තවමත් නිකුතුවක් කපා නැත ... "ඉතිහාසය නාස්ති නොකර කොමිස් ඒකාබද්ධ කිරීම ගැන ඔබට කණගාටුයි" යනු සාමාන්‍යයෙන් කේත පුරාවිද්‍යා ගවේෂණ 2 ක් හෝ 3 ක් පමණ ඇසීමෙන් පසුව ඇසෙන හ cry යි. GitHub UI

දැන් අපි Git විධාන රේඛාව භාවිතා කරන්නේ නම් මෙය ක්‍රියාත්මක වන්නේ කෙසේදැයි සලකා බලමු (සහ නිවැරදි කිරීම සඳහා අතිවිශිෂ්ට 2.6.2 git blame --first-parent)

• ඔබ Git විධාන රේඛාව භාවිතා කරන්නේ නම්, ඔබට ඒකාබද්ධ කිරීමේ පණිවිඩය මුළුමනින්ම පාලනය කිරීමට හැකි වන අතර එමඟින් ඒකාබද්ධ කිරීමේ බැඳීමට හොඳ සාරාංශ රේඛාවක් තිබිය හැකිය.

ඉතින් අපේ කැපවීමේ ඉතිහාසය වගේ

$ git log
1256556316... #423 Added new slideshow feature
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... #324 Hotfix for android display issue
787g8fgf78... hotfix for #5849564648
f56556316e... #28 Implemented pop-up to select language
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

නමුත් අපටද එය කළ හැකිය

$ git log --first-parent
1256556316... #423 Added new slideshow feature
56556316ad... #324 Hotfix for android display issue
f56556316e... #28 Implemented pop-up to select language

(වෙනත් වචන වලින් කිවහොත්: Git CLI ඔබට ඔබේ කේක් තබා එය අනුභව කිරීමට ඉඩ දෙයි)

දැන් අපි ශුන්‍ය දර්ශක ගැටලුවට පහර දුන් විට ... හොඳයි, අපි දැන් භාවිතා කරන git blame --first-parent -w dodgy-file.cඅතර සරල හිස් අවකාශයේ වෙනස්කම් නොසලකා ප්‍රධාන ශාඛාවට ශුන්‍ය දර්ශක යොමු කිරීම හඳුන්වා දුන් ස්ථානය අපට වහාම ලබා දේ.

ඇත්ත වශයෙන්ම ඔබ GitHub UI භාවිතා කරමින් ඒකාබද්ධ කිරීම් කරන්නේ නම් git log --first-parent, ඒකාබද්ධ කිරීමේ පණිවිඩයේ පළමු පේළියට බල කිරීම සඳහා GitHub ට ස්තූතියි.

1256556316... Merge pull request #423 from jrandom/add-slideshows
56556316ad... Merge pull request #324 from ahacker/fix-android-display
f56556316e... Merge pull request #28 from somwhere/select-lang-popup

එබැවින් දිගු කතාවක් කෙටි කිරීමට:

GitHub UI (2015 ඔක්තෝබර්) හි ඉල්ලීම් ඒකාබද්ධ කරන ආකාරය, එය බැඳීම් ඉතිහාසය ඉදිරිපත් කරන්නේ කෙසේද සහ එය දොස් පවරන තොරතුරු ආරෝපණය කරන්නේ කෙසේද යන්න සමඟ අඩුපාඩු ගණනාවක් තිබේ. GitHub UI හි ඇති මෙම අඩුපාඩු මඟහරවා ගත හැකි හොඳම ක්‍රමය නම්, ඒකාබද්ධ වීමට පෙර ඔවුන්ගේ කැපවීම් ඉවත් කරන ලෙස ජනතාවගෙන් ඉල්ලා සිටීමයි.

Git CLI සතුව මෙම ගැටළු නොමැති අතර ඔබට දැකීමට අවශ්‍ය දෘෂ්ටිය ඔබට පහසුවෙන් තෝරා ගත හැකි වන අතර එමඟින් යම් වෙනසක් සිදු කිරීමට හේතුව (සොයා නොගත් කොමිස් වල ඉතිහාසය දෙස බැලීමෙන්) මෙන්ම දෙදෙනාම සොයා ගත හැකිය. squ ලදායී ලෙස කොටු කළ කොමිස් බලන්න.

පිටපත

ස්කොෂ් කිරීම සඳහා බොහෝ විට සඳහන් කර ඇති අවසාන හේතුව වන්නේ පසුපෙළ ප්‍රවාහනය පහසු කිරීමයි ... ඔබට පිටුපස වරාය සඳහා එක් කැපවීමක් පමණක් තිබේ නම් (එනම් ස්කොෂ් කළ කැපවීම) එවිට චෙරි තෝරා ගැනීම පහසුය ...

හොඳයි, ඔබ git ඉතිහාසය දෙස බලන්නේ git log --first-parentනම්, එවිට ඔබට චෙරි ඒකාබද්ධ කිරීමේ කොමිස් තෝරා ගත හැකිය. බොහෝ අය ව්‍යාකූලත්වයට පත්වන්නේ චෙරි අච්චාරු ඒකාබද්ධ කිරීමේ කොමිසම නිසා ඔබට -m Nවිකල්පය නියම කළ යුතු නමුත් ඔබට ඒ සඳහා කැපවීමක් ලැබුනේ git log --first-parentනම් ඔබ අනුගමනය කළ යුතු පළමු මාපිය එය බව ඔබ දන්නවා.git cherry-pick -m 1 ...

එකතු කරන ලද විශේෂාංග සහ දෝෂ නිවැරදි කර ඇති ආකාරය පිළිබඳ පැහැදිලි හා සංක්ෂිප්ත ඉතිහාසයක් පෙන්වීම පිළිබඳව මෙම ත්‍රෙඩ් එකේ වෙනත් පිළිතුරු වල දක්වා ඇති හැඟීම් සමඟ මම එකඟ වෙමි. කෙසේ වෙතත්, ඔබේ ප්‍රශ්නය මග හැරුණු නමුත් පැහැදිලිව සඳහන් නොකළ තවත් අංශයක් ඇමතීමට මට අවශ්‍ය විය. Git හි සමහර වැඩ කිරීමේ ක්‍රම පිළිබඳව ඔබට තිබිය හැකි Hangup හි කොටසක් නම්, එවැනි ක්‍රියාවන් කළ නොහැකි වෙනත් ප්‍රභව පාලන ක්‍රම භාවිතා කිරීමෙන් පසු git වෙත හඳුන්වා දීමේදී අමුතු යැයි පෙනෙන ඉතිහාසය නැවත ලිවීමට git ඔබට ඉඩ සලසයි. තවද, මෙය සාමාන්‍යයෙන් පිළිගත් ප්‍රභව පාලක මූලධර්මයට පටහැනි වන අතර, යම් දෙයක් ප්‍රභව පාලනයට බැඳී ඇති විට / පරීක්ෂා කළ විට, එම කැපවීම අනුගමනය කිරීමෙන් ඔබ කුමන වෙනස්කම් කළත් එම තත්වයට ආපසු යාමට ඔබට හැකි විය යුතුය. ඔබේ ප්‍රශ්නයට අනුව, මෙය එවැනි තත්වයන්ගෙන් එකකි. මම හිතන්නේ git යනු විශිෂ්ට අනුවාද පාලන පද්ධතියක්; කෙසේ වෙතත්, එය අවබෝධ කර ගැනීම සඳහා ඔබ එහි පිටුපස ක්‍රියාත්මක කිරීමේ විස්තර සහ සැලසුම් තීරණ කිහිපයක් තේරුම් ගත යුතු අතර, එහි ප්‍රති it ලයක් ලෙස එයට දැඩි ඉගෙනුම් වක්‍රයක් ඇත. මතක තබා ගන්න git යනු බෙදා හරින ලද අනුවාද පාලන පද්ධතියක් වන අතර එය නිර්මාණකරුවන් විසින් git ඉතිහාසය නැවත ලිවීමට ඉඩ දෙන්නේ ඇයිද යන්න පැහැදිලි කිරීමට උපකාරී වනු ඇත.

ඉදිරිදර්ශනය නිසා ... හොඳම පුරුද්ද වන්නේ <<issue-management-system>>හැකි නම් එක් නිකුතුවකට තනි කැපවීමක් කිරීමයි.

ඔබේම විශේෂාංග ශාඛාව / ගබඩාව තුළ ඔබට අවශ්‍ය තරම් කොමිස් ප්‍රමාණයක් තිබිය හැකිය, නමුත් එය ඔබගේ ඉදිරිදර්ශනය සඳහා ඔබ දැන් කරමින් සිටින දෙයට අදාළ වේ ... එය සමස්ත කණ්ඩායම / ව්‍යාපෘතිය හෝ ඔවුන්ගේ යෙදුම සඳහා ඉතිහාසය නොවේ. ඉදිරිදර්ශනය දැන් සිට මාස කිහිපයක් තබා ගත යුතුය ...

එබැවින් ඔබ පොදු විසඳුමකට දෝෂ නිරාකරණය හෝ අංගයක් කිරීමට කැමති විට (මෙම උදාහරණය සංවර්ධන ශාඛාව සමඟ ඇත) ඔබට එය කළ හැකි දේ පහත පරිදි වේ:

ඔබේ විශේෂාංග ශාඛාව ඉක්මනින් සංවර්ධනය කරන්නේ කෙසේද?

    # set your current branch , make a backup of it , caveat minute precision
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # squash all your changes at once 
    git reset $(git merge-base develop $curr_branch)

    # check the modified files to add 
    git status

    # add the modified files dir by dir, or file by file or all as shown
    git add --all 

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # add the single message of your commit for the stuff you did 
    git commit -m "<<MY-ISSUE-ID>>: add my very important feature"

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # make a backup once again , use seconds precision if you were too fast ... 
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # compare the old backup with the new backup , should not have any differences 
    git diff <<old-backup>>..<<new-backup-branch>>


    # you would have to git push force to your feature branch 
    git push --force 

කේතය පොදුද නැද්ද යන්න මම දකිමි.

ව්‍යාපෘති පුද්ගලිකව පවතින විට:

ස්කොෂ් නොකිරීමට සහ සොසේජස් සෑදීම බැලීමට මම නිර්දේශ කරමි. ඔබ හොඳ සහ කුඩා කොමිස් භාවිතා කරන්නේ නම්, git bisect වැනි මෙවලම් ඉතා පහසු වන අතර මිනිසුන්ට ඉක්මණින් ප්‍රතිගාමී ක්‍රියාකාරකම් හඳුනාගත හැකි අතර ඔබ එය කළේ මන්දැයි බලන්න (කැපවීමේ පණිවිඩය නිසා).

ව්‍යාපෘති පොදු වූ විට:

සමහර කොමිස් වල ආරක්ෂක කාන්දුවීම් අඩංගු විය හැකි නිසා සියල්ල ස්කොෂ් කරන්න. උදාහරණයක් ලෙස මුරපදයක් කැප කර නැවත ඉවත් කර ඇත.