Git හි අදියර දෙකේ කැපවීමේ ක්‍රියාවලියේ (වේදිකාගත කිරීමේ) වාසිය කුමක්ද?


180

මම git ඉගෙන ගන්නා අතර එයට පියවර දෙකක කැපවීමේ ක්‍රියාවලියක් ඇති බව මම දුටුවෙමි.

  1. git add <files>
  2. git commit

පළමු පියවර "වේදිකා ප්‍රදේශයක්" හෝ "දර්ශකය" ලෙස හැඳින්වෙන දේට සංශෝධන සිදු කරයි.

මා උනන්දු වන්නේ මෙම සැලසුම් තීරණය ගන්නේ ඇයි සහ එහි ප්‍රතිලාභ මොනවාද?

එසේම, git භාවිතා කරන්නෙකු ලෙස ඔබ මෙය කරන්නේද නැතහොත් භාවිතා git commit -aකරන්නේද?

මෙම අංගය නොමැති bzr (Bazaar) වෙතින් පැමිණි බැවින් මම මෙය අසමි.


3
ඉල්ලීම සඳහා +1. මම ඉබ්බන් එස්වීඑන් භාවිතා කරමි, එය එකම ප්‍රවේශයක් ඇති අතර එයට හේතුව මට කිසි විටෙකත් වැටහී නැත.
ඩීපීඩී

3
වේදිකා ප්‍රදේශය එතරම් අසාමාන්‍ය දෙයක් නොවේ. TFS හි ඇතුළත් කිරීමට සමාන වන්නේ, පරීක්ෂා කිරීමට පෙර ගොනුවක් අසල ඇති කොටුව පරීක්ෂා කිරීම හෝ සලකුණු නොකිරීම ය. Git සමඟ ඇති වෙනස නම්, ඔබ භාවිතා කරන්නේ නම් git add -p, එකම ගොනුවේ තවත් කොටසක් සිදු නොකොට එක් ගොනුවක් කැපීමට තෝරා ගත හැකිය .
Kyralessa

මෙම සබැඳිය මෙහි පිළිතුරු දී ඇති බොහෝ දේ සාරාංශ කරන බවත් වේදිකාගත කිරීමේ අවශ්‍යතාවය සාධාරණීකරණය කිරීම සඳහා තවත් භාවිත අවස්ථා කිහිපයක් එකතු කරන බවත් මම සොයා ගතිමි .
වෙවර්කේ

2
මෙම ප්‍රශ්නයට ඇත්ත වශයෙන්ම දැනටමත් පිළිතුරු ලැබී ඇත, නමුත් මෙහි එක් හොඳ පැහැදිලි කිරීමක් ද ඇත: stackoverflow.com/questions/4878358/…
kit_freak

1
අමතක කරන්න එපා git statusහැකි හා git push. Git පිළිබඳ සියලු උපකල්පනයන් සඳහා, (සහ GitHub බෙදාගැනීමේ කේතය අපූරු ය) කොටස් ඉතා කරදරකාරී ය
user949300

Answers:


83

වැඩ වෙනම කොමිස් වලට බෙදන්න. තනි පේළි විසඳුමක් ලිවීම සඳහා ඔබ බොහෝ විට ගොනුවක් විවෘත කර ඇත, නමුත් ඒ සමඟම හැඩතල ගැන්වීම වැරදියි, සමහර ලියකියවිලි වැඩිදියුණු කළ හැකිය, නැතහොත් වෙනත් සම්බන්ධයක් නැති විසඳුමක්. වෙනත් RCS සමඟ ඔබට එය ලිවීමට හෝ මතකයට කැප කිරීමට සිදු වේ, ඔබ පැමිණි නිවැරදි කිරීම අවසන් කරන්න, එය සිදු කරන්න, ඉන්පසු අනෙක් දේවල් නිවැරදි කිරීමට ආපසු යන්න (හෝ සම්බන්ධයක් නැති දේවල් සමඟ මඩ බෝලයක් සාදන්න) . Git සමඟ ඔබ ඒ සියල්ල එකවර සවි කර, අදියර + තනි පේළිය වෙන වෙනම, සමඟ git add -iහෝ git-gui.

ගොඩනැගීම බිඳ නොදමන්න. ඔබ සංකීර්ණ වෙනස් කිරීමක වැඩ කරමින් සිටී. ඒ නිසා ඔබ වෙනස් දේවල් උත්සාහ කරන්න, සමහර ඒවා අනෙක් ඒවාට වඩා හොඳින් ක්‍රියා කරයි, සමහර ඒවා දේවල් බිඳ දමයි. නවීකරණය මඟින් දේවල් වඩා හොඳ වූ විට checkout(හෝ තවත් සමහරක් වෙනස් කරන්න) Git සමඟ ඔබ දේවල් වේදිකා ගත කරයි. ඔබට සංස්කාරකයේ අහෝසි කිරීමේ ක්‍රියාකාරිත්වය මත විශ්වාසය තැබිය යුතු නැත, ඔබට checkoutගොනුව-ගොනුව වෙනුවට සම්පූර්ණ ප්‍රතිමූර්තිය කළ හැකිය , සහ ඕනෑම ගොනු මට්ටමේ වැරදි (කැපවී නැති ගොනුවක් ඉවත් කිරීම හෝ සුරැකීම + වසා දැමීම වැනි නරක වෙනස් කිරීම) බොහෝ වැඩ අහිමි වීමට හේතු නොවේ.


3
මෙම අංගය නොමැති DVCS (bzr) වෙතින් පැමිණීම, මගේ සංස්කාරකයේ "අහෝසි කරන්න" බෆර, "ප්‍රතිවර්තනය <file>" විධානය සහ තෝරාගත් කොමිස් (" <file> ") කරන්න. Git හි මෙම අංගය වඩාත් විධිමත් වීමට විභවයක් ඇති බව පෙනේ.
thomasrutter

1
"වෙනත් RCS" සම්බන්ධයෙන්, එය අනිවාර්යයෙන්ම සත්‍ය නොවේ. ඇත්ත වශයෙන්ම, ඔබට පැච් භාවිතා කරමින් මර්කුරියල් හි එම ක්‍රියාකාරීත්වයන් සාක්ෂාත් කරගත හැකිය .
ලුසියෝ පයිවා

1
second l0b0, ඔබේ දෙවන කරුණ ගැන. තනි අදියර කැපවීමක් තිබුනේ නම්, ඔබට සෘජුවම කැපවීමක් ලෙස වෙනස්කම් (git add සමඟ භාවිතා කරන) සිදු කළ හැකිය. ඔබ යම්කිසි වැරැද්දක් කර ඇති බව ඔබ දැනගත්තේ නම්, ඔබ එම බැඳීම මකා දමා, ඔබ එම කැපවීමට පෙර ඔබ සිටි ස්ථානයට ආපසු යනු ඇත. වේදිකා සංකල්පය සමඟ, ඔබ එය කරන්නේ පමණක් නොව, වඩාත් සංකීර්ණ බවක් එකතු කරන්නේ ද?
alpha_989

2
-1 මන්දයත් වේදිකා ගත වන ප්‍රදේශයට මෙහි පළමු කරුණ සමඟ කිසිදු සම්බන්ධයක් නැති බැවිනි. @ ඇල්ෆා_989 හි ප්‍රශ්නය නිරාකරණය වේ: පරිශීලකයාට ඔවුන්ගේ වැඩ කරන නාමාවලියෙහි වෙනස්කම් කිහිපයක් එකවර සිදු කිරීමට ඉඩ දීම සඳහා අදියර දෙකක කැපවීමක් අවශ්‍ය නොවේ hg commit --interactive.
මාර්ක් අමරි

1
මෙම භාවිත අවස්ථා දෙකම වේදිකා සංකල්පයකින් තොරව මර්කුරියල් හි හසුරුවනු ලැබේ. මේ දක්වා වේදිකාගත කිරීමේ කාරණය පැහැදිලි කිරීමට උත්සාහයන් දහයක් පමණ කියවා ඇති අතර සියල්ල අසාර්ථක වේ.
cja

65

මට ලැබෙන එක් ප්‍රතිලාභයක් නම් ක්‍රමානුකූලව ලිපිගොනු “එකතු” කිරීමේ හැකියාවයි. සිදු කිරීමට පෙර මම එක් එක් ගොනුව සමාලෝචනය කරමි. ගොනුව සමාලෝචනය කළ පසු, මම එය එකතු කරමි. මා git statusහෝ git diff, git මට පෙන්වන්නේ වෙනස් කරන ලද සහ තවම එකතු කර නොමැති ගොනු පමණි. මම සියලු ලිපිගොනු සමාලෝචනය කර ඒවා එකතු කළ විට, මට කැපවිය හැකිය.

ඉතින් ඔව්, වේදිකා ගත කරන ප්‍රදේශය ඉතා ප්‍රයෝජනවත් බව මට පෙනේ.

මම කවදාවත් පාවිච්චි කරන්නේ නැහැ git commit -a. කෙසේ වෙතත්, මම බොහෝ විට භාවිතා කරමි git add -u. මේ ආකාරයෙන් මට කැපවිය යුතු දේ දෘශ්‍යමාන කළ හැකිය.


2
හරියටම. වාසිය නම් ඔබ ඉදිරිපත් කරන දෙය හරියටම පාලනය කිරීමයි.
ජොෂ් කේ

ඔබ එක් ගොනුවක් කිහිප වතාවක් වේදිකා ගත කළ විට කුමක් සිදුවේද? එය වේදිකාගත වන ස්ථානයේ "ඒකාබද්ධ" වේද?
m4l490n

21

ප්‍රතිලාභය ඉතා සරල ය: එය ඔබට කුමන ගොනු කිරීමට අවශ්‍ය ද යන්න පිළිබඳ පූර්ණ පාලනය ලබා දෙයි. එම කාරණය සඳහා, ඔබට කැපවීමට අවශ්‍ය රේඛාgit add -p පාලනය කිරීමට ඔබට භාවිතා කළ හැකිය .


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

3
E රයින්හෙන්රිච්ස්, එක් එක් සංවර්ධකයා විසින් වෙනස් කළ යුතු වින්‍යාස ගොනු ගැන සිතන්න.
ඉයන්

1
AnIan ඉතින් ගොනුවේ කොටසක් කලාතුරකින් වෙනස් වන අතර එය බෙදාගෙන ඇති අතර ගොනුවේ කොටසක් බොහෝ විට නොගැලපෙන ආකාරයෙන් වෙනස් වන අතර බෙදා නොගනීද? මෙම ව්‍යාජ සම්බන්ධතාවයට සහය දැක්වීම අනිවාර්යයෙන්ම ප්‍රති-අංගයක් සේ පෙනේ.
රයින් හෙන්රිච්

1
E රයින්හෙන්රිච්ස්, ඔව්, ගොනුවේ දත්ත සමුදා සේවාදායකයේ නම අඩංගු වන අතර සෑම ඩිව් එකකටම තමන්ගේම දත්ත සමුදායක් ඇත.
ඉයන්

4
An ඔබගේ ගැටලුව ඇත්ත වශයෙන්ම තිබේ, ඔබ සතුව ගොනුවක් ඇති අතර එය යෙදුම සඳහා වින්‍යාසය විය යුතු යැයි සිතිය හැකි යන්ත / යන්ත්‍ර විශේෂිත වින්‍යාසයන් ද අඩංගු වේ. මා දන්නා සියලුම වින්‍යාස පද්ධති ඔබට එය ගොනු කිහිපයකට බෙදීමට ඉඩ දෙයි. උදාහරණයක් ලෙස ඔබට app.confබෙදා ගැනීමට අවශ්‍ය දේවල් අඩංගු වන අතර පසුව db.confඔබ .gitignore ලැයිස්තුවට ඇතුළත් කර ඇත. ගැටළුව විසඳා ඇත. ඔබ හිමිකාර යමක් භාවිතා කරන්නේ නම් එතැන එතරම් සරල දෙයක් ලබා ගැනීම ගැන සොයා බැලිය යුතුය. නැතහොත් පෙර සැකසුම් සිදුවීමක පෙර සැකසුම් යන්ත්‍රයක් හරහා එය දමන්න. එහි බොහෝ විසඳුම්.
අයිඩියාකාපි

1

මා කැමති එක් ප්‍රතිලාභයක් වන්නේ වෙනසක කොටසක් කිරීමට ඇති හැකියාවයි. එනම්, git add -e භාවිතා කිරීමෙන්. සමහර විට මා කළ යුතු වාර ගණනක් මම බැඳී නොසිටින අතර, git add -e විධානය මඟින් මගේ වෙනස්කම් යම් දුරකට නිරාවරණය කිරීමට ඉඩ ලබා දේ.


1
මර්කුරියල් මෙය කරන්නේ වේදිකා සංකල්පයකින් තොරව ය. පියවර දෙකක් අනවශ්‍යයි
cja
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.