حتى الآن يعيش موقعك الشخصي في مكان واحد، حاسوبك المحمول. إن تعطّل القرص ضاع كل شيء، ولا يستطيع أحد غيرك أن يراه أو يراجعه. الـ remote (المستودع البعيد) نسخة أخرى من الـ repository في مكان آخر، على GitHub في الغالب. ومهمّة Git أن يُبقي النسختين متزامنتين، وهو يفعل ذلك بأربعة أوامر أساسية: clone و fetch و pull و push.
على github.com، أنشئ repository جديدًا باسم portfolio. اترك “Add a README” وخيارات التهيئة الأخرى دون تحديد: فالـ repository المحلي لديك له سجلّ بالفعل، و commit إضافي على GitHub سيعطيك سجلّين لا علاقة بينهما عليك التوفيق بينهما. بعد ذلك يعرض GitHub الأوامر اللازمة لربط repository موجود. وخلاصتها:
git remote add origin https://github.com/maya-okafor/portfolio.git\ngit remote -v\ngit push -u origin maingit remote add يعطي عنوان URL اسمًا قصيرًا. و origin مجرد عُرف، الاسم الذي يستخدمه Git تلقائيًا حين تستنسخ، لكن الجميع يستخدمه، فاستخدمه أنت أيضًا. الرفع يحمّل الـ commits الخاصة بك وينشئ main على GitHub. في المرة الأولى سيطلب منك Git المصادقة؛ والدرس التالي يشرح إعدادها كما يجب بمفاتيح SSH أو بمدير بيانات اعتماد.
وإن كنت تستخدم GitHub CLI، فالأمر gh repo create portfolio --public --source=. --remote=origin --push يفعل كل ذلك دفعة واحدة.
أما إن بدأت من الجهة الأخرى، بـ repository موجود أصلًا على GitHub، فإنك تستنسخه (clone) بدلًا من ذلك:
\ngit clone https://github.com/maya-okafor/portfolio.gitالـ clone ينشئ المجلد، وينزّل كل commit، ويضيف remote اسمه origin، وينقلك إلى main مع إعداد التتبّع جاهزًا.
بعد الرفع، يعرض git branch -a شيئًا جديدًا:
* main\n remotes/origin/mainorigin/main فرع تتبّع بعيد (remote-tracking branch): ملاحظة يحتفظ بها الـ repository الخاص بك عن مكان main على origin في آخر مرة تواصلت معه. لا تنشئ عليه commits أبدًا. ولا يتحرّك إلا حين تنفّذ fetch أو pull أو push. لهذا يستطيع git status أن يقول “Your branch is up to date with ‘origin/main’” بينما رفع زميلك شيئًا قبل خمس دقائق: لم يسأل Git موقع GitHub منذ ذلك الحين.
الخيار -u في git push -u origin main (وصيغته الطويلة --set-upstream) يسجّل أن main المحلي لديك يتتبّع origin/main. ومن ثم:
git push أو git pull المجرّدان على main إلى أين يذهبان؛git status عبارات مثل “ahead 2” أو “behind 1” مقارنةً بـ origin/main؛git branch -vv كل فرع مع الـ upstream الخاص به وعدد الـ commits المتقدّمة والمتأخّرة.كل فرع جديد يحتاجه مرة واحدة، عند رفعه الأول: git push -u origin footer.
git fetch يسأل الـ remote عمّا هو جديد، وينزّل الـ commits، ويحرّك فروع التتبّع البعيدة لديك. لا يلمس أبدًا فروعك أو ملفاتك، لذا فهو آمن دائمًا:
git fetch\ngit status # \"Your branch is behind 'origin/main' by 1 commit\"\ngit log --oneline main..origin/main # what's new over theregit pull هو git fetch يتبعه دمج الـ upstream في فرعك الحالي. إن لم تكن لديك commits محلية خاصة بك، فهذا fast-forward. أما إن كان في الطرفين commits جديدة، فعلى Git أن ينفّذ merge أو rebase، والإصدارات الحديثة من Git ترفض التخمين:
fatal: Need to specify how to reconcile divergent branches.اتّخذ القرار مرة واحدة:
\ngit config --global pull.rebase true # replay my unpushed commits on top (my default)\n# or: git config --global pull.rebase false (create a merge commit)\n# or: git config --global pull.ff only (refuse unless it's a fast-forward)أنصح بـ pull.rebase true. فهو لا يعيد كتابة إلا الـ commits الخاصة بك التي لم تُرفع بعد، وهذا ما تسمح به القاعدة الذهبية، ويُبقي السجلّ خاليًا من commits من نوع “Merge branch ‘main’ of github.com:…” التي لا تقول شيئًا.
اجمع هذه الأوامر معًا وستبدو كل جلسة عمل على الموقع الشخصي متشابهة في كل مرة. ابدأ بالانتقال إلى main وتنفيذ pull، لتبدأ مما هو موجود فعلًا على GitHub لا مما كان موجودًا الأسبوع الماضي. أنشئ فرعًا للتغيير. أنشئ الـ commits أثناء العمل، وارفع الفرع مبكرًا، حتى لو لم يكتمل: الفرع المرفوع نسخة احتياطية، وهو مرئي لكل من يساعدك. وقبل أن تفتحه للمراجعة، نفّذ fetch مجددًا ثم rebase على origin/main المحدَّث إن كان قد تحرّك. هذه العادة وحدها تمنع معظم عمليات الرفع المرفوضة والتعارضات المفاجئة التي يلوم الناس Git عليها.
git switch main && git pull\ngit switch -c projects-filter\n# …work and commit…\ngit push -u origin projects-filterإن رفع أحدهم شيئًا إلى main منذ آخر fetch لك، يُرفض رفعك:
! [rejected] main -> main (fetch first)\nerror: failed to push some refs to 'https://github.com/maya-okafor/portfolio.git'في الـ remote commits ليست لديك. اسحبها، وحُلّ أي تعارض بالروتين الذي تعلّمته في القسم الثاني، وشغّل فحوصك، ثم ارفع مجددًا.
\n\n\nطلب منك رفعك الأول بيانات الاعتماد. في الدرس التالي ستُعدّ المصادقة كما يجب، فيتوقّف Git عن السؤال ويعرف GitHub أنك أنت فعلًا.
\n","toc":[{"id":"sec-1","text":"ضع الموقع الشخصي على GitHub","level":2},{"id":"sec-2","text":"فروع التتبّع البعيدة: ذاكرة Git عن الـ remote","level":2},{"id":"sec-3","text":"الـ upstream و git push -u","level":2},{"id":"sec-4","text":"الـ fetch أولًا، ثم الـ pull","level":2},{"id":"sec-5","text":"إيقاع يومي","level":2},{"id":"sec-6","text":"حين يُرفض الرفع","level":2}],"takeaways":["الـ remote عنوان URL مسمّى لنسخة أخرى من الـ repository؛ وorigin هو الاسم المتعارف عليه للنسخة التي استنسخت منها أو ترفع إليها.","origin/main هو سجلّك المحلي لمكان main على الـ remote عند آخر fetch؛ ولا يتحرّك إلا حين تنفّذ fetch أو pull أو push.","git push -u origin <branch> يرفع الفرع ويضبطه كـ upstream، فيعرف git push أو git pull المجرّدان لاحقًا إلى أين يذهبان.","git fetch ينزّل دون أن يلمس فروعك؛ و git pull ينفّذ fetch ثم merge أو rebase.","الرفع المرفوض يعني أن في الـ remote commits ليست لديك؛ اسحبها، ثم ارفع مجددًا، ولا تلجأ إلى القوة أبدًا."],"further":[{"title":"Working with Remotes (Pro Git)","url":"https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes"},{"title":"Remote Branches (Pro Git)","url":"https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches"},{"title":"Pushing commits to a remote repository","url":"https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository"},{"title":"git pull reference","url":"https://git-scm.com/docs/git-pull"}],"quiz":[{"q":"شغّلت git fetch فنزّل commitين جديدين على main. ما الذي تغيّر في الـ working tree لديك؟
git pull في خطوته الثانية. أما git fetch وحده فلا يلمس ملفاتك ولا فروعك أبدًا."},{"text":"تقدّم main المحلي لديك بـ commitين.","why":"الـ fetch يحدّث فروع التتبّع البعيدة مثل origin/main، ولا يحدّث main الخاص بك أبدًا."},{"text":"دُمج الـ commitان وأُنشئ merge commit.","why":"لا يحدث أي دمج عند الـ fetch. أنت من يختار متى وكيف يدمج."},{"text":"لا شيء؛ تحرّك origin/main فقط، وملفاتك و main لم تتغيّر.","why":"صحيح. الـ fetch آمن دائمًا. قارن بـ git log main..origin/main قبل أن تقرّر هل تدمج أم تنفّذ rebase."}],"answer":3},{"q":"يفشل git push بالرسالة: Updates were rejected because the remote contains work that you do not have locally. ما الإصلاح الصحيح؟
git pull لتجلب commits الـ remote، وحُلّ أي تعارض، ثم git push مجددًا.","why":"صحيح. في الـ remote commits تنقصك؛ ادمجها أولًا، فيصبح رفعك fast-forward."},{"text":"شغّل git push --force لتفوز نسختك.","why":"هذا سيحذف الـ commits التي رفعها شخص آخر. الرفع بالقوة ليس أبدًا الحلّ حين يكون الفرع المشترك متقدّمًا عليك."},{"text":"احذف الـ repository المحلي واستنسخه من جديد.","why":"ستخسر الـ commits التي لم ترفعها. أما الـ pull فيدمج الطرفين دون خسارة أي شيء."},{"text":"شغّل git push -u origin main لإعادة ضبط التتبّع.","why":"التتبّع ليس المشكلة. الفرع البعيد تقدّم، ورفعك لا يستطيع تقديمه بـ fast-forward."}],"answer":0},{"q":"ماذا يضيف -u إلى git push -u origin footer؟
-u اختصار لـ --set-upstream. ولا علاقة له بالسرعة أو الفحوص."},{"text":"يسجّل origin/footer كـ upstream لفرع footer المحلي، فلا يحتاج git push و git pull لاحقًا إلى أي وسائط.","why":"صحيح. تحتاجه مرة واحدة لكل فرع؛ وبعدها يعرض git status أيضًا عدد الـ commits المتقدّمة والمتأخّرة مقارنةً بـ origin/footer."},{"text":"يحدّث كل فرع على الـ remote، لا footer وحده.","why":"لا يُرفع إلا الفرع الذي تسمّيه. ويوجد الخيار --all لرفع كل الفروع."}],"answer":2},{"q":"في main المحلي لديك commit واحد لم ترفعه، وفي origin/main commitان لم تسحبهما. مع ضبط pull.rebase على true، ماذا يفعل git pull؟
pull.rebase false. أما مع true فينفّذ Git rebase بدل الدمج."},{"text":"ينفّذ fetch، ثم يعيد تشغيل الـ commit غير المرفوع فوق الـ commitين البعيدين.","why":"صحيح. يبقى السجلّ خطيًا، ولا تُعاد كتابة إلا الـ commit الخاص بك الذي لم يُرفع، وهذا يحترم القاعدة الذهبية."},{"text":"يرفض، لأن الفرعين تباعدا.","why":"هذا ما يفعله pull.ff only. أما pull.rebase true فيعالج التباعد بالـ rebase."}],"answer":1}],"exercise":{"kind":"fill","language":"bash","template":"git remote {{0}} origin https://github.com/maya-okafor/portfolio.git\ngit push {{1}} origin main # first push: also set the upstream\n\n# later: see what's new on GitHub without touching my files\ngit {{2}}\ngit log --oneline main..origin/main","blanks":[{"answers":["add"]},{"answers":["-u","--set-upstream"]},{"answers":["fetch","fetch origin"]}],"title":"اربط الموقع الشخصي وزامِنه","prompt":"املأ الفراغات: سجّل الـ repository الموجود على GitHub باسم origin، وارفع main للمرة الأولى بحيث يتتبّع origin/main، ثم تحقّق لاحقًا من وجود commits جديدة على GitHub دون تغيير فرعك أو ملفاتك.
git remote أمر فرعي يسجّل اسمًا جديدًا وعنوان URL.","خيار الرفع الذي يسجّل الـ upstream حرف واحد، اختصار لكلمة upstream.","أحد أوامر المزامنة الأربعة ينزّل دون أن يدمج."],"explanation":"git remote add origin <url> يسمّي عنوان GitHub باسم origin. و git push -u origin main يرفع main ويضبط origin/main كـ upstream له، فيعمل git push أو git pull المجرّد من ذلك الحين. و git fetch يحدّث origin/main دون أن يلمس main أو ملفاتك؛ ثم يسرد git log main..origin/main بالضبط ما ستحصل عليه لو نفّذت pull.