ធ្វើការជាមួយ Remote

មាតិកា

1. ច្បាប់ចម្លងបីនៃ Project តែមួយ
2. origin/main៖ ការមើល GitHub លើកចុងក្រោយរបស់អ្នក
3. Push ពីកុំព្យូទ័រទីពីរ
4. git fetch៖ មើលសិន មុននឹងធ្វើ
5. git pull៖ Fetch ហើយ Merge
6. កែប្រែនៅលើ GitHub ផ្ទាល់
7. នៅពេល Push របស់អ្នកត្រូវបានបដិសេធ
8. កុំ Force-Push លើ Branch ដែលប្រើរួមគ្នាជាដាច់ខាត
9. ទម្លាប់ប្រចាំថ្ងៃ
10. សាកល្បងដោយខ្លួនឯង

1. ច្បាប់ចម្លងបីនៃ Project តែមួយ

បន្ទាប់ពីជំពូកមុន project របស់អ្នកមាននៅកន្លែងបី៖

        ~/my-site  ──push──►  GitHub (origin)  ◄──push──  ~/my-site-laptop
                   ◄──pull──                   ──pull──►

នីមួយៗគឺជា repository ពេញលេញមួយដែលមាន history ផ្ទាល់ខ្លួន។ ពួកវាមិនធ្វើសមកាលកម្ម (sync) ដោយស្វ័យប្រវត្តិទេ។ commit ដែលអ្នកធ្វើនៅកន្លែងមួយ នៅតែនៅទីនោះរហូតដល់អ្នក push វា ហើយគ្មាននរណាម្នាក់ផ្សេងទៀតឃើញវាទេ រហូតដល់ពួកគេ pull វា។

នោះហើយជារបៀបដែលក្រុមមួយធ្វើការ៖ អ្នកអភិវឌ្ឍន៍ម្នាក់ៗមាន clone ផ្ទាល់ខ្លួន ហើយ GitHub គឺជាចំណុចជួបជុំរួមនៅកណ្តាល។ នៅក្នុងជំពូកនេះ ~/my-site-laptop ដើរតួជា «កុំព្យូទ័រមួយទៀត» — laptop របស់អ្នកនៅផ្ទះ ឬសមាជិកក្រុមម្នាក់។

2. origin/main៖ ការមើល GitHub លើកចុងក្រោយរបស់អ្នក

នៅក្នុង ~/my-site រត់៖

git log --oneline --all -3

e2c4a91 (HEAD -> main, origin/main) Add README
a7f2c19 Merge branch 'new-title'
4d81e0b Use full name in page title

អ្នកធ្លាប់ស្គាល់ main រួចហើយ។ origin/main គឺជារបស់ថ្មី៖ វាជា ការចងចាំ របស់ repository អ្នកអំពីទីតាំងដែល main ស្ថិតនៅ លើ GitHub នៅពេលចុងក្រោយដែលអ្នកបានទាក់ទងជាមួយ GitHub។ វាត្រូវបានគេហៅថា remote-tracking branch។

ពាក្យសំខាន់គឺ ការចងចាំ។ origin/main មិនធ្វើបច្ចុប្បន្នភាពដោយខ្លួនឯងទេ — វាប្តូរតែនៅពេលអ្នក push, fetch ឬ pull ប៉ុណ្ណោះ។ ឥឡូវនេះ ស្លាកទាំងពីរចង្អុលទៅ commit តែមួយ ដូច្នេះច្បាប់ចម្លងរបស់អ្នក និង GitHub ដូចគ្នា។

3. Push ពីកុំព្យូទ័រទីពីរ

ប្តូរទៅ «កុំព្យូទ័រមួយទៀត»៖

cd ~/my-site-laptop

បន្ថែមបន្ទាត់មួយនៅខាងចុង README.md៖

Built in Phnom Penh while learning Git.

Commit ហើយ push៖

git commit -am "Mention where the site was built"
git push

ឥឡូវនេះ GitHub មាន commit មួយដែល ~/my-site មិនធ្លាប់ឃើញសោះ។

4. git fetch៖ មើលសិន មុននឹងធ្វើ

ត្រឡប់ទៅច្បាប់ចម្លងចម្បងរបស់អ្នកវិញ៖

cd ~/my-site
git status

On branch main
Your branch is up to date with 'origin/main'.

«Up to date» (ទាន់សម័យ) — ប៉ុន្តែនោះខុសហើយ! វាកំពុងប្រៀបធៀបជាមួយ ការចងចាំ របស់វាអំពី GitHub ហើយការចងចាំនោះចាស់ហើយ។ ដើម្បីធ្វើឲ្យការចងចាំនោះថ្មីឡើងវិញ សូម fetch៖

git fetch
git status

On branch main
Your branch is behind 'origin/main' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)

git fetch ទាញយក commit ថ្មីៗពី GitHub ហើយផ្លាស់ទី origin/main ប៉ុន្តែ មិនប៉ះពាល់ file ឬ branch main របស់អ្នកទេ។ វាតែងតែមានសុវត្ថិភាព។ អ្នកអាចមើលអ្វីដែលបានមកដល់ មុននឹងសម្រេចចិត្តថាត្រូវធ្វើអ្វី៖

git log --oneline main..origin/main

b81d3f6 (origin/main) Mention where the site was built

(main..origin/main មានន័យថា «commit ដែលមាននៅលើ origin/main ប៉ុន្តែមិនទាន់មាននៅលើ main»។)

5. git pull៖ Fetch ហើយ Merge

ដើម្បីនាំ commit ទាំងនោះចូលទៅក្នុង branch និង file របស់អ្នក៖

git pull

Updating e2c4a91..b81d3f6
Fast-forward
 README.md | 2 ++
 1 file changed, 2 insertions(+)

git pull គឺជា git fetch បន្តដោយ git merge។ វាទាញយក commit ថ្មីៗ បន្ទាប់មក merge origin/main ចូលទៅក្នុង main របស់អ្នក — ដូចគ្នាបេះបិទនឹងការ merge branch នៅក្នុងជំពូកទី 6។ នៅទីនេះវាជា fast-forward ព្រោះអ្នកមិនមាន commit ថ្មីផ្ទាល់ខ្លួនទេ។

បើក README.md៖ បន្ទាត់ថ្មីនៅទីនោះហើយ។ ឥឡូវនេះ កុំព្យូទ័រទាំងពីរដូចគ្នានឹង GitHub។

6. កែប្រែនៅលើ GitHub ផ្ទាល់

អ្នកក៏អាចធ្វើការផ្លាស់ប្តូរតូចៗដោយផ្ទាល់នៅលើគេហទំព័រ GitHub ដែរ ដែលងាយស្រួលសម្រាប់ការកែអក្ខរាវិរុទ្ធខុសនៅក្នុង README។ បើក README.md នៅលើ GitHub ចុច pencil icon (Edit this file) ធ្វើការផ្លាស់ប្តូរ ហើយចុច Commit changes…។ GitHub សួររក commit message ដូចនៅក្នុង terminal ដែរ — សរសេរ message ល្អមួយ ហើយបញ្ជាក់។

Commit នោះមាននៅតែលើ GitHub ប៉ុណ្ណោះ។ យកវាមកក្នុងកុំព្យូទ័ររបស់អ្នកតាមរបៀបធម្មតា៖

git pull

7. នៅពេល Push របស់អ្នកត្រូវបានបដិសេធ

ឥឡូវនេះ មកដល់ស្ថានភាពដែលកើតឡើងចំពោះគ្រប់គ្នា៖ មនុស្សពីរនាក់ commit ដោយមិនបាន pull ជាមុន។

នៅក្នុង ~/my-site-laptop — ដែលមិនទាន់បាន pull ការកែប្រែលើគេហទំព័រពីផ្នែកទី 6 — ផ្លាស់ប្តូរអ្វីមួយនៅក្នុង about.html commit ហើយសាកល្បង push៖

cd ~/my-site-laptop
git commit -am "Add hobbies to about page"
git push

To https://github.com/dara-sok/my-site.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'https://github.com/dara-sok/my-site.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. ...
hint: ... use 'git pull' before pushing again.

GitHub បានបដិសេធ ហើយនោះជារឿងល្អ។ GitHub មាន commit មួយដែលអ្នកមិនមាន (ការកែប្រែលើគេហទំព័រ)។ បើវាទទួលយក push របស់អ្នក commit នោះនឹងត្រូវបោះចោល។ Git មិនដែលអនុញ្ញាតឲ្យ push ធម្មតាបំផ្លាញការងាររបស់អ្នកដទៃឡើយ។

ដំណោះស្រាយគឺដូចអ្វីដែល hint និយាយ — pull ជាមុនសិន បន្ទាប់មក push៖

git pull

Branch របស់អ្នក និង branch របស់ GitHub បានទៅមុខរៀងៗខ្លួន ដូច្នេះ pull នេះបង្កើត merge commit មួយ (editor របស់អ្នកបើកឡើងជាមួយ message ដូចជា Merge branch 'main' of https://github.com/...; រក្សាទុក ហើយបិទ)។ នេះហើយជាករណីដែល pull.rebase false ពីជំពូកទី 2 ត្រូវបានរៀបចំឡើងសម្រាប់៖ Git ធ្វើការ merge ដូចដែលអ្នកបានអនុវត្តរួចមកហើយ ជំនួសឲ្យការឈប់សួរថាត្រូវបញ្ចូលពួកវាចូលគ្នាដោយរបៀបណា។

git push

ទទួលយកហើយ។ បើភាគីទាំងពីរបានផ្លាស់ប្តូរបន្ទាត់ដូចគ្នា git pull នឹងឈប់ជាមួយ merge conflict ជំនួសវិញ — ហើយអ្នកដឹងរួចហើយពីរបៀបដោះស្រាយវាពីជំពូកទី 7។ ដោះស្រាយ git add git commit បន្ទាប់មក git push។

8. កុំ Force-Push លើ Branch ដែលប្រើរួមគ្នាជាដាច់ខាត

មិនយូរមិនឆាប់ អ្នកនឹងឃើញ command នេះនៅលើអ៊ីនធឺណិត៖

git push --force

វាប្រាប់ GitHub ថា «ជំនួស branch របស់អ្នកដោយ branch របស់ខ្ញុំ មិនថាវាមានអ្វីនោះទេ»។ វាកម្ចាត់ push ដែលត្រូវបានបដិសេធ ដោយលុប commit ដែលអ្នកមិនមាន។ នៅលើ branch ដែលមនុស្សផ្សេងប្រើ នោះមានន័យថា លុបការងាររបស់ពួកគេ។

នេះគឺជាច្បាប់ពីជំពូកទី 5 ដែលកំពុងអនុវត្តជាក់ស្តែង៖ បើអ្នក --amend ឬ reset commit ដែលមាននៅលើ GitHub រួចហើយ history របស់អ្នកលែងដូចនឹង history របស់ GitHub ហើយ push បន្ទាប់របស់អ្នកនឹងត្រូវបានបដិសេធ។ ចម្លើយមិនមែនជា --force ទេ — គឺត្រូវជៀសវាងការសរសេរ commit ដែលបាន push រួចឡើងវិញតាំងពីដំបូង ហើយប្រើ git revert ជំនួសវិញ។

(អ្នកអភិវឌ្ឍន៍ដែលមានបទពិសោធន៍ ពេលខ្លះ force-push លើ feature branch ផ្ទាល់ខ្លួន របស់ពួកគេដែលគ្មាននរណាម្នាក់ផ្សេងប្រើ។ នោះជាប្រធានបទសម្រាប់ពេលក្រោយ។ នៅលើ main ឬ branch ណាមួយដែលប្រើរួមគ្នា៖ កុំធ្វើជាដាច់ខាត។)

9. ទម្លាប់ប្រចាំថ្ងៃ

ទម្លាប់មួយចំនួនដែលធ្វើឲ្យការធ្វើការជាមួយ remote មិនលំបាក៖

• Pull មុនពេលអ្នកចាប់ផ្តើមធ្វើការ។ ចាប់ផ្តើមរាល់ពេលធ្វើការដោយ git pull ដើម្បីឲ្យអ្នកសាងសង់លើកំណែចុងក្រោយបំផុត។
• Commit តូចៗ push ញឹកញាប់។ រាល់ការ push ក៏ជាការបម្រុងទុក (backup) ផងដែរ។ បើ laptop របស់អ្នកខូច អ្វីដែលបាន push រួចគឺមានសុវត្ថិភាព។
• អាន git status បន្ទាប់ពី fetch។ «Behind», «ahead» និង «diverged» ប្រាប់អ្នកយ៉ាងច្បាស់ថាត្រូវធ្វើអ្វីបន្ទាប់។
• Push ដែលត្រូវបានបដិសេធគឺជារឿងធម្មតា។ Pull ដោះស្រាយបើចាំបាច់ ហើយ push ម្តងទៀត។

10. សាកល្បងដោយខ្លួនឯង

1. Push ពីច្បាប់ចម្លងមួយ ហើយ pull ពីច្បាប់ចម្លងមួយទៀត។ Commit នៅក្នុង ~/my-site-laptop push បន្ទាប់មករត់ git fetch និង git status នៅក្នុង ~/my-site មុននឹងរត់ git pull។
2. កែប្រែនៅលើ GitHub។ កែអ្វីមួយនៅក្នុង README.md នៅលើគេហទំព័រ បន្ទាប់មក pull វាចូលទៅក្នុងច្បាប់ចម្លងទាំងពីរនៅលើកុំព្យូទ័រ។
3. ធ្វើឲ្យត្រូវបានបដិសេធដោយចេតនា។ Commit នៅក្នុងច្បាប់ចម្លងទាំងពីរដោយមិន pull push មួយ បន្ទាប់មកសាកល្បង push មួយទៀត។ ជួសជុលវាដោយ git pull និង git push។
4. ធ្វើឲ្យវា conflict។ ធ្វើជំហានទី 3 ម្តងទៀត ប៉ុន្តែផ្លាស់ប្តូរ បន្ទាត់ដូចគ្នា នៃ file ដូចគ្នានៅក្នុងច្បាប់ចម្លងទាំងពីរ។ ដោះស្រាយ conflict ដែល git pull រាយការណ៍ បន្ទាប់មក push។
5. អានក្រាហ្វ។ រត់ git log --oneline --graph --all -10 ហើយរក merge commit ដែល pull របស់អ្នកបានបង្កើត។

ឥឡូវនេះ អ្នកអាចរក្សាច្បាប់ចម្លងប៉ុន្មានក៏បានឲ្យដូចគ្នាជានិច្ច។ បន្ទាប់មកទៀត តោះប្រើ GitHub សម្រាប់អ្វីដែលវាពូកែបំផុត៖ ការធ្វើការជាមួយមនុស្សផ្សេងទៀត។