يوغرطة بن علي

أنصحك بالاطّلاع على الجزء السّابق قبل مواصلة قراءة هذا المقال. يُمكنك الوصول إليه من هنا. الدليل إلى ربط النطاقات إذا كنتَ تستضيف مواقع للعملاء، فمن المحتمل جدًا أن يرغب أن يحصل كلٌ منهم على نطاقٍ فريدٍ خاصٍ به. ربما تظن أنَّ الأمر صعبٌ عند استخدامك لشبكة متعددة المواقع، وتحسب أنَّك تستطيع أن توفر نطاقًا أو مجلدًا فرعيًا فقط. لكن استخدام نطاقات فريدة لكل موقع من مواقع الشبكة هو أمرٌ سهلٌ جدًا عبر إضافة Domain Mapping؛ حيث تسمح لك بإضافة أي عدد من النطاقات الإضافية لكل موقع من مواقع الشبكة ومن ثم انتقاء أحدها لجعله نطاقًا «أساسيًا» (primary) والذي سيظهر في متصفح الزوار. وهذا يعني للزائر أنَّ الموقع يبدو وكأنه مستضافٌ بمفرده على ذاك النطاق. هذه الإضافة تسمح لك أيضًا بأخذ أجر من مستخدمين لقاء ربط النطاقات بشبكتك أو لقاء بيع النطاقات – وهذه طريقةٌ رائعةٌ لكي تربح من شبكتك. ربط نطاق إلى موقع في شبكتك هو أمرٌ تستطيع القيام به كمدير للشبكة، أو تستطيع أن تتركه لعملائك أو مستخدميك. إذا كنتَ تتوقع من عملائك أو مستخدميك أن يفعلوا ذلك، فعليك أن توفِّر لهم دليلًا يشرح تلك العملية. أسمح للمستخدمين في إحدى شبكاتي أن يربطوا النطاقات بمواقعهم، بينما أضبطها بنفسي في شبكةٍ أخرى. هنالك ميزات ومساوئ لكلٍ منها: السماح لمستخدميك أن يضبطوا ربط النطاقات يوفِّر عليك بعض العمل، لكنه يعطيهم تحكمًا أكبر. ملاحظة: ربط النطاقات ليس خاصًا لمواقع العملاء. إذا أنشأتَ شبكةً تسمح للآخرين فيها بتسجيل مواقع خاصة بهم، فربما أرادوا أن يربطوا نطاقًا خاصًا بهم بالموقع. يمكنك أن تتقاضى مالًا لقاء ذلك، ويمكنك أيضًا بيع النطاقات. هنالك ست خطوات لربط النطاقات في شبكتك: تثبيت إضافة Domain Mapping. نسخ ملف من مجلد الإضافة إلى مجلد content في ووردبريس. إجراء تعديل بسيط على ملف wp-config.php. ربط النطاقات في شبكتك باستخدام DNS. هنالك طريقتان لفعل ذلك، وسأشرحها بالتفصيل بعد قليل. إضافة النطاقات إلى إعدادات المواقع المختلفة في شبكتك. اختيار النطاق الرئيسي (primary domain) إن لم يكن النطاق مساويًا للنطاق الافتراضي. سأريك هذه العملية بالتفصيل، لكن دعنا أولًا نشرح بعض المفاهيم الأساسية. النطاقات الرئيسية والثانوية النطاق الرئيسي هو النطاق الذي يراه الزوار في متصفحهم عندما يزوروا الموقع. أما النطاق الثانوي فهو نطاقٌ آخر الذي يُشير إلى نفس الموقع. يمكنك أن تحصل على نطاق رئيسي وحيد، وأي عدد تريده من النطاقات الفرعية. لنتخيل أنَّ لديك شبكة في http://mynetwork.com، ولديك موقع فيها (باستخدام المجلدات الفرعية) في http://mynetwork.com/mysite، وتريد أن توجِّه نطاقين إلى ذاك الموقع: http://mysite.com و http://mysite.org. النطاق الرئيسي هو http://mysite.com الذي هو النطاق الذي تريد أن يراه زوارك في متصفحهم. أي بعبارةٍ أخرى، أنت تريد أن يعمل الموقعع كما لو أنَّه موقع مستقل مُستضاف على http://mysite.com. عليك أولًا أن تُثبِّت الإضافة، النطاق الرئيسي لموقعك هو المجلد الفرعي على الشبكة، الذي هو http://mynetwork.com/mysite. ثم ستتمكن من الإشارة إلى النطاقين الآخرين إليه وإضافتهما إلى إعدادات الموقع. وهذا سيضبطهما على أنهما نطاقات فرعية؛ أي أنهما سيشيران إلى موقعك، لكن الزوار سيرون http://mynetwork.com/mysite في متصفحهم. في النهاية،، عليك أن تختار http://mysite.com نطاقًا رئيسيًا في إعدادات موقعك (أو في إعدادات الشبكة كمدير للشبكة). وهذا يعني أنَّ لو كتب أحدهم http://mynetwork.com/mysite أو http://mysite.com أو http://mysite.org في متصفحهم فسيؤخذون إلى http://mysite.com وسيتصفحون الموقع الموجود في http://mynetwork.com/mysite، إلا أنهم لن يعلموا أنَّ هذا الموقع جزءٌ من الشبكة. هل ازدادت حيرتك؟ نأمل أن تُزال حيرتك عندما ترى العملية أمامك! خدمة DNS: سجلات A و CNAME مفهوم آخر عليك أن تعيه قبل أن تستعمل ربط النطاقات هو خدمة DNS، التي تشير إلى «Domain Name Service» (خدمة أسماء النطاقات)، ستستخدم هذا النظام لكي تخبر اسم النطاق ما هو الخادوم أو الموقع الذي يجب أن يُشير إليه. وللقيام بذلك، يمكنك أن تستخدم إحدى الطريقتين: سجلات A التي تربط نطاقًا إلى عنوان IP، الذي هو مُعرِّف فريد للخادوم. على سبيل المثال، موقع WPMU DEV مُستضافٌ على عنوان 104.16.24.10. وهذا هو العنوان الأساسي لمواقع الويب، وأي اسم نطاق سيتحول في نهاية المطاف إلى عنوان IP. إذا كنت تطلب من عملائك أن يضبطوا ربط النطاقات بأنفسهم، فأفضل طريقة هي أن يكون لشبكتك عنوان IP خاص بها (والذي تستطيع شراءه من مزود خدمة الاستضافة) ثم تسمح لهم بإنشاء سجلات A تابعة للنطاقات الخاصة بهم. سجلات CNAME تربط نطاقًا إلى نطاقٍ آخر. ففي المثال أعلاه، ربما لدى http://mysite.com سجل من نوع CNAME ليشير إلى http://mynetwork.com/mysite. هذه السجلات توفر عليك الحاجة إلى استخدام عنوان IP فريد. سيصبح الأمر أكثر وضوحًا عندما ترى طريقة تنفيذ ما سبق عمليًا. ضبط ربط النطاقات لن تأخذ عملية ربط النطاقات وقتًا طويلًا، على الرغم من أنَّ تحديث سجلات DNS قد يأخذ بعض الوقت لكي تنتشر (propagate) أسماء النطاقات التي تُشير إلى موقعك. عملية الانتشار (propagation) هي عملية تُجرى على سجلات DNS لكي تأخذ مفعولها على الإنترنت. يمكنك أن تُراقِب عملية الانتشار عبر استخدام DNS checker إن كان لديك وقتٌ فارغٌ لتملأه. ستحتاج إلى وصول FTP إلى شبكتك ومحررٍ نصيّ، وستحتاج أيضًا إلى نسخ ملف وتعديل آخر. تثبيت إضافة ربط النطاقات أول خطوة هي تثبيت الإضافة. وذلك إما عبر لوحة التحكم أو عبر رفع الإضافة إلى مجلد wp-content/plugins. ثم عليك تفعيلها. اذهب الآن في لوحة تحكم مدير الشبكة إلى «Settings > Domain Mapping» وسترى رسالة خطأ تخبرك ما الذي عليك فعله في الخطوة القادمة: في عميل FTP، اعثر على المجلد wp-content/plugins/domain-mapping وستجد بداخله ملفًا باسم sunrise.php انسخ هذا الملف (لا تنقله) إلى مجلد wp-content. افتح الآن ملف الضبط wp-config.php، الذي ستجده في مجلد الجذر لتثبيت ووردبريس، واعثر على السطر الآتي: /* That's all, stop editing! Happy blogging. */ افتح سطرًا جديدًا قبل السطر السابق والصق فيه السطر الآتي: define('SUNRISE', 'on'); احفظ الآن ملف wp-config.php. عُد الآن إلى الموقع وحدِّث صفحة إضافة Domain Mapping التي كنتَ فيها؛ وستجد أنَّ رسالة الخطأ قد اختفت: يمكنك الآن إعداد ضبط النطاقات. ضبط ربط النطاقات لشبكتك ستكتشف الإضافةُ عنوانَ IP الخاص بك تلقائيًا وستظهره لك في صفحة Domain Mapping في لوحة التحكم. انسخ ذاك العنوان إلى حقل «Server IP Address» في أسفل المربع الأزرق الذي يُظهِر عنوان IP. إن لم يظهر عنوان IP الخاص بك عبر الإضافة، فاستعمل DNS checker أو اسأل شركة الاستضافة عن عنوان IP الخاص بك… مرِّر إلى الأسفل لتصل إلى قسم «Allow multiple mappings per site». إذا أردتَ أن تجعل عدد النطاقات التي يستطيع مدراء المواقع إضافتها محدودًا إلى نطاقٍ وحيد، فاترك هذا الخيار معطلًا. لكنني أحب عادةً استخدام أكثر من نطاق، لذا سأفعِّل هذا الخيار. القسم التالي هو قسم «Administrative mapping»، وهو يتعلق بالنطاق الذي سيُستخدَم للوحة التحكم. فلو كان الموقع مربوطًا بالنطاق http://mysite.com لكنه مستضاف علىى http://mynetwork.com/mysite، فيمكنك أن تختار استخدام http://mysite.com/wp-admin أو http://mynetwork.com/mysite/wp-admin للوحة التحكم. استخدام النطاقق المنفصل أفضل لعملائك، لأنها سيتعاملون مع الموقع كما لو أنَّه مستقل، لكن للمستخدمين الذين يُنشِئون مواقعهم والذين سيعلمون أنَّهم جزءٌ من شبكتك، فقد تُفضِّل استخدام النطاق التابعع للشبكة. الخيار البديل هو أن تعطي مدراء المواقع القدرة على اختيار أيُّ الخيارات يفضلون. الخيارات المطروحة هي: «Domain entered by the user» (النطاق مُدخَل من قِبل المستخدم): سيختار مدير الموقع ما هو النطاق الذي سيستعمله للوصول إلى لوحة التحكم. «Mapped domain» (النطاق المربوط): النطاق المربوط سيُستخدَم دومًا لجميع المواقع التي تربط نطاقات خارجية فيها. «Original domain» (النطاق الأصلي): سيُستخدَم نطاق الشبكة لجميع المواقع. سأختار أول خيار، لأنه يعطي مرونة أكبر. عليك بعدئذٍ أن تنتقي خيارًا مشابهًا في قسم «Login mapping»، لكنه يتعلق بصفحة wp-login. حتى لو كانت مواقعك تستعمل نطاق الشبكة للوصول إلى لوحة التحكم، إلا أنَّها ستبدو أكثر احترافية لو استخدمت النطاقات المربوطة لصفحة تسجيل الدخول، وهذا يعني أنَّه لو كان الموقع على شبكةٍ تملك مستخدمين يستطيعون تسجيل الدخول إلى ذاك الموقع لكنهم لا يعلموا أنَّ ذاك الموقع مربوطٌ بنطاقٍ خاري، فلن تؤدي صفحة تسجيل الدخول إلى إرباكهم؛ ولهذا السبب سأختار الخيار الثاني: «mapped domain». القسم التالي هو قسم «Cross-domain autologin»، والذي سيتيح لك السماح للمستخدمين بتسجيل الدخول إلى جميع المواقع على شبكتك التي يملكون وصولًا إليها بتسجيل الدخول مرة واحدة. أجد هذا الخيار مفيدًا للمستخدمين الذين يتعاملون مع أكثر من موقع ومفيدًا لي أيضًا –كمدير للشبكة– عندما أعمل على أكثر من موقع، لذا أختار «Yes»، لكن إن كنتَ تريد أن تُجبِر مستخدميك على تسجيل الدخول لكل موقع على حدة، فاختر «No». مرِّر الآن إلى الأسفل إلى قسم «Check domain propagation before mapping». إذا اخترتَ «Yes» هنا، فستتحقق الإضافة من أنَّ النطاق قد رُبِطَ بشكلٍ سليم إلى الشبكة قبل إتمام عملية الربط. وهذا مفيدٌ إذا سمحتَ لمستخدميك بضبط نطاقاتهم حيث سيؤدي تفعيل هذا الخيار إلى منعهم من ارتكاب خطأ. لكن إن كنتَ تُجري عملية الربط بنفسك، فربما تفضِّل اختيار «No». شخصيًا، أضبط عادةً ربط النطاقات بنفس الوقت الذي أضبط فيه خدمة DNS، وهذا يعني أن سجلات DNS لن تكمل انتشارها عندما أضبط إعدادات ربط النطاقات، لكنها ستكتمل مع مرور الوقت، لذا أختار «No». القسمان التاليان مرتبطان ببروتوكول HTTPS، وستفيدانك إذا اشتريت شهادة SSL لشبكتك، مما يزيد من أمانها. يمكنك أن تضبط هنا إذا ما كنتَ تريد إجبار المستخدم على استخدام بروتوكول https لتسجيل الدخول ولصفحات الإدارة ولصفحات الموقع العادية. سأترك هذين الخيارين مضبوطين إلى «No» لأنَّ شبكتي لا تملك شهادة SSL. الآن في قسم «Prohibited mappings»، أضف أيّة نطاقات لا تريد للمستخدمين أن يربطوها مع شبكتك. لن أحتاج إلى إضافة أي شيء هنا لأنني أتعامل مع نطاقات معروفة للعملاء، لكن قد تستعمل هذا الحقل إذا أردت تفادي النطاقات المزعجة التي توجَّه إلى موقعك، أو تلك التي تتضارب مع اسم منظمتك أو شركتك التجارية. القسم التالي يسمى «Enable excluded/forced URLs»، وهذه هي خياراته: «Allow site admins to set map-excluded pages» (السماح لمدراء المواقع بضبط صفحات لا تتأثر بربط النطاقات): سيتمكن المدراء من تحديد صفحات معيّنة التي لن تستخدم النطاقات المربوطة. «Allow site admins to set map-excluded URLs» (السماح لمدراء المواقع بضبط روابط URL لا تتأثر بربط النطاقات): سيتمكن المدراء من تحديد روابط URL معيّنة التي لن تستخدم النطاقات المربوطة. «Allow site admins to set https-forced pages» (السماح لمدراء المواقع بضبط صفحات لا تعمل إلا ببروتوكول HTTPS): سيتمكن المدراء من تحديد صفحات معيّنة ستحتاج إلى استخدام بروتوكول https، وهذا مفيد لصفحات التسجيل أو لصفحات التسوق الإلكتروني. «Allow site admins to set https-forced urls» (السماح لمدراء المواقع بضبط روابط URL لا تعمل إلا ببروتوكول HTTPS): سيتمكن المدراء من تحديد روابط URL معيّنة ستحتاج إلى استخدام بروتوكول https. سأعطِّل الخيارين الثالث والرابع لعدم استخدامي لشهادةSSL على الشبكة. عليك الآن بعد إجراء جميع الخطوات السابقة أن تضغط على زر «Save Changes» لتحفظ التغييرات التي أجريتها. في صفحة «Domain Mapping» هنالك ثلاثة ألسنة (tabs)، أكملنا ضبط الخيارات الموجودة في أول لسان «Mapping options». أما اللسان الثاني «Reseller options» فله صلة بالخيارات التي يجب ضبطها إن كنت تبيع النطاقات عبر موقعك، وسيعطيك وصولًا إلى مزودي خدمة يمكنك استخدامهم لفعل ذلك. ولمّا كنتُ أتعامل مع العملاء، فسأشتري أسماء النطاقات بنفسي، ولن أحتاج إلى استخدام هذا اللسان. اللسان الثالث هو «Mapping Domains»، وهناك سترى ما هي النطاقات التي رُبِطَت إلى المواقع الموجودة في شبكتك، وستتمكن من إدارتها. حتى لو كنتُ مديرًا للشبكة، فأميل عادةً إلى إضافة النطاقات في لوحة تحكم الموقع لكل موقع على حدة، لذا لا أستعمل عادةً هذا اللسان. لكن إن كان لديك موقعٌ في شبكتك ولم يكن متاحًا لأنَّ النطاق الرئيسي لا يعمل (وكانت لوحة التحكم مربوطةً بالنطاق الرئيسي أيضًا)، فهذا هو المكان الوحيد الذي ستتمكن فيه من إيقاف عملية الربط لذاك النطاق، أو تحويلها إلى نطاقٍ فرعي. هذا اللسان مفيدٌ جدًا إن حدث ذلك. بعد إتمامك لضبط ربط النطاقات، فستحتاج إلى إضافة نطاق. وهذا يتألف من خطوتين: جعل النطاق يُشير إلى شبكتك، وإضافته إلى الموقع. جعل النطاق يشير إلى شبكتك عليك أن تستعمل لوحة التحكم الإدارية في الجهة التي سجلتَ فيها النطاق لجعله يشير إلى شبكتك. يمكنك إما أن تستعمل سجل CNAME أو A. وفي بعض الأحيان قد تجد أنَّ أحد تلك السجلات لا يعمل، فعندها جرِّب الخيار الآخر. تذكر أنَّ: سجل A يتألف من عنوان IP لشبكتك، الذي هو قيمة رقمية مفصولة بنقط. سجل CNAME هو اسم النطاق الخاص بموقعك. لدى مدراء المواقع صفحة لربط النطاقات التي توفِّر لهم المعلومات التي يحتاجوا لها لفعل ذلك. في لوحة تحكم الموقع، اذهب إلى «Tools > Domain Mapping»: استخدم الأدوات التي يوفرها لك مزود خدمة النطاقات لضبط سجل CNAME أو A مع المعلومات الصحيحة. ملاحظة: بعض مزودي خدمة تسجيل DNS لا يوفرون لك أدوات لأنهم يريدون منك استخدام الخواديم الخاصة بهم أو سيطلبون منك دفع مبلغ إضافي لخدمة DNS. إذا كانت هذه هي حالتك، فتواصل معهم وانظر إن كانوا يستطيعون فعل ذلك لك. أو أنصحك أن تبحث عن خدمة أخرى لتسجيل النطاقات. النطاقٌ ملكٌ لك، وأنت حر في كيفية استخدامه. إضافة النطاقات إلى موقع بعد أن تجعل نطاقك يُشير إلى موقعك، فستحتاج إلى تعديل ضبط ربط النطاقات لذاك الموقع. اذهب إلى صفحة «Tools > Domain Mapping» في لوحة تحكم الموقع. في حقل «Map new domain name» اكتب اسم النطاق الذي تريد أن يُربَط بالموقع ثم اضغط على زر «Map domain». سترى في الصورة التالية أنَّني فعلتُ ذلك مع اسم نطاق من اختراعي: وأظهرت الإضافة أنَّ ذاك النطاق غير صحيح، لأنه لا يُشير إلى موقعي، أما لو كان ضبط DNS صحيحًا، فستظهر رسالة تفيد بذلك. ملاحظة: لن تستفيد شيئًا بإضافة نطاق لا يُشير إلى موقعك. لذا لا يمكنك استخدام هذه الإضافة للحصول على الكثير من النطاقات التي لا تملكها لتشير إلى موقعك! يمكنك إضافة أي عدد من النطاقات إذا فعّلتَ ذلك في إعدادات الشبكة. لاختيار أحد النطاقات نطاقًا رئيسيًا، اضغط على أيقونة النجمة على يمين الاسم. يمكنك فعل ذلك فقط للنطاقات المربوطة ربطًا سليمًا إلى موقعك، فإذا لم يكن ممكنًا استبيان (resolve) اسم النطاق بعد، فلن تتمكن من الوصول إلى موقعك. إن احتجتَ إلى تنزيل رتبة موقع إلى نطاقٍ ثانوي، فاضغط مرةً أخرى على النجمة (إما في الصفحة السابقة، أو في لوحة تحكم مدير الشبكة). ستظهر أيّة نطاقات أُضيفتَ إلى الموقع في لوحة تحكم مدير الشبكة، وهذا يعني أنَّ مدير الشبكة يستطيع إدارتها أيضًا. اذهب إلى Settings > Domain Mapping في لوحة تحكم مدير الشبكة واختر لسان Mapped Domains: ستُظهِر الصفحة السابقة جميع النطاقات المربوطة وتسمح لك بإدارتها؛ ستتمكن من هنا أيضًا أن تحذف النطاقات المربوطة، وتجعلها رئيسية (أو تنزل رتبتها إلى ثانوية) وتبدِّل بين http و https باستخدام أيقونة المفتاح. هذا كل ما في الأمر! بمجرد إضافتك للنطاقات السابقة، فلن تحتاج إلى فعل شيءٍ آخر. إذا أضفتَ نطاقًا أساسيًا إلى موقعٍ واستخدمته للوصول إلى لوحة التحكم وللواجهة الأمامية التي ستظهر لزوار الموقع، فستحتاج إلى تسجيل الدخول مرةً أخرى. ربط النطاقات الخارجية يجعل الشبكة متعددة المواقع أكثر فائدةً بالنسبة لي، أجد أنَّ ميزة ربط النطاقات تُطيح بالنقد الموجَّه لشبكات ووردبريس متعددة المواقع. فلِمَن يقلق أنَّ موقعه المُستضاف على شبكة لن يسلك نفس سلوك المواقع المفردة، فكل ما عليه فعله هو ضبط ربط النطاقات. باستخدام ربط النطاقات وباتباع الممارسات المستحسنة للحماية، ستتمكن من استخدام شبكة ووردبريس متعددة المواقع لاستضافة مواقع العملاء (أو المواقع التي أنشأتها لنفسك أو لمستخدميك) التي تسلك سلوك المواقع المفردة ذات النطاق المنفصل. وهذا يُعطيك الميزات التي تحصل عليها من الشبكة متعددة المواقع دون أن تخسر المظهر الاحترافي لموقعك أو أن يؤثر ذلك في SEO. في الجزء القادم من هذه السلسلة، سنستكشف جانبًا مفيدًا من ميزات تعدد المواقع في ووردبريس، ألا وهو إنشاء مجتمع. سأريك كيف تستعمل شبكتك لكل تجعل مستخدميها على تواصل ولتسمح لهم بمشاركة المحتوى، وأن يتابعوا بعضهم بعضًا والمزيد. ترجمة –وبتصرّف– للمقال WordPress Multisite Masterclass: Client Sites and Domain Mapping لصاحبته Rachel McCollin

سنقوم في هذا الدرس بتغطية الأوامر الأساسية التي لا يُمكنك الاستغناء عنها إن أردت أن تستخدم Git بكفاءة عالية والتي ستقضي وقتك على Git في استخدامها. يُفترض بك بعد إنهاء قراءة هذا الدرس أن تصبح قادرًا على إعداد وتهيئة مُستودع، الشروع في وإيقاف تتبع التغييرات في ملفات مُعينة، إرسال التغييرات إلى منطقة الإدراج وإيداعها. سنشرح لك أيضا كيف ستقوم بتجاهل ملفات مُعينة أو التي تتبع أنماطا خاصة، فيما ستتحدث الدروس التي تلي هذا عن كيفية التراجع عن أخطاء قُمت بها بشكل سريع وسهل، كيفية تصفح تاريخ المشروع والاطلاع على كافة التعديلات التي حدثت ما بين كل إيداعين، وكيف تقوم بدفع التغييرات إلى مُستودع في خادوم بعيد أو سحب البيانات منه. الحصول على مستودع وحفظ التغييرات فيه يُمكنك الحصول على مُستودع Git بطريقتين مُختلفتين. تتمثل الأولى في إنشاء مُستودع لمشروع أو مُجلد مُعد سلفا، وتتم الثانية عبر استنساخ مُستودع موجود على خادوم بعيد. إنشاء مستودع جديد لمشروع موجود مسبقا إن أردت الشروع في تتبع إصدارات وتغييرات مشروع راهن فكل ما عليك القيام به هو الذهاب إلى مُجلد المشروع (بسطر الأوامر طبعا) ومن ثم تنفيذ الأمر التالي: $ git init سيقوم هذا الأمر بإنشاء مُجلد فرعي داخل مُجلد المشروع يحمل الاسم git. والذي سيحتوي جميع ملفات المُستودع الأساسية التي ستشكل هيكل المستودع. بطبيعة الحال لن يتم تتبع أية تغييرات بُمجرد تنفيذ هذا الأمر لوحده. إن أردت الشروع في إدارة نسخ الملفات الراهنة (يعني لن تبدأ بمُجلد فارغ) فإنه يجب عليك أولا الشروع في تتبع هذه الملفات والقيام بأول عملية إيداع. يُمكن القيام بذلك عبر تنفيذ بضعة أوامر git add التي ستحدد فيها أسماء هذه الملفات ثم تُتبعها بأمر للإيداع: $ git add README $ git commit -m "initial project version" بعد تنفيذك لهذه الأوامر (سنشرح ما تقوم به هذه الأوامر بعد قليل) سيكون لديك مُستودع Git يقوم بتتبع التغييرات التي ستطرأ على مجموعة ملفات، إضافة إلى إيداع أولي. نسخ مستودع موجود مسبقا إن أردت استنساخ مُستودع Git راهن -وليكن مُستودعا لمشروع ترغب في المُساهمة فيه- فإن الأمر الذي ستحتاجه للقيام بذلك هو git clone. إن كانت لديك دراية مُسبقة بباقي أنظمة إدارة النُسخ مثل Subversion فإنك ستلحظ بأن الأمر الذي نستعمله هنا هو clone وليس checkout، حيث أن ما سيستقبله Git هو نُسخة من جميع البيانات (أو تقريبا) الموجودة على الخادوم. يعني بأنك ستحصل على كل نسخة من كل الملفات منذ أن تم الشروع في تتبع المُستودع الموجود على الخادوم لدى تنفيذ الأمر git clone. بعبارة أخرى، لو تعرض القرص الصلب لخادومك لعطب ما فإنه بإمكانك استعادة المشروع الذي كنت تعمل عليه كما كان (أو تقريبا) بفضل النُسخ الموجودة في جميع الأجهزة التي تعمل على نفس المشروع. يتم استنساخ المُستودعات باستخدام الأمر التالي: git clone [url] حيث يتم استبدال بعُنوان المُستودع المُراد استنساخه. فعلى سبيل المثال لو أردت استنساخ مُستودع "الدليل البسيط لاستخدام Git" فسيكون الأمر على النحو التالي: git clone git://github.com/arabicgit/simple-guide.git سيتم إنشاء مُجلد يحمل الاسم simple-guide يتم إنشاء مُجلد git. بداخله، ومن ثم سيتم استنساخ جميع البيانات الموجودة في مستودع الدليل على Github التي يُمكن الشروع في العمل عليها. إن أردت أن يتم استنساخ المُستودع داخل مُجلد باسم مُخالف فيُمكن تحديد اسم المُجلد الذي ترغب فيه (وليكن MyGuide) في أمر الاستنساخ على النحو التالي: git clone git://github.com/arabicgit/simple-guide.git MyGuide يدعم Git عدة بروتوكولات للتحويل. استعملنا في المثال السابق بروتوكول git://، لكنه بإمكانك أيضا استخدام (http(s:// أو user@server:/path.git والتي تعتمد على بروتوكول SSH. تسجيل التغييرات الحاصلة في المستودع الآن وبعد أن حصلت على مُستودع يقبل تتبع التغييرات الحاصلة على ملفاته، إضافة إلى جُملة من الملفات التي ستعمل عليها، ستحتاج بطبيعة الحال إلى إحداث تغييرات عليها ومن ثم إيداع تلك التغييرات في كل مرة يصل فيها مشروعك إلى مرحلة ترغب في تسجيلها. تذكر بأن الملفات تكون في إحدى الحالتين التاليتين: مُتتبع tracked أو غير مُتتبع untracked. الملفات المُتتبعة هي التي سبق وأن سجلت حضورا في اللقطة snapshot السابقة. يُمكن لهذه الملفات أن تكون في حالات ثلاثة: مُعدّلة غير مُعدلة مُدرجة staged (أي موجودة في منطقة الإدراج). أما الملفات غير المُتتبعة فهي ما سوى ذلك، ويشمل ذلك أي ملف في مجلد العمل لم يكن موجودًا في اللقطة السابقة وغير موجود في منطقة الإدراج. لدى قيامك باستنساخ مُستودع فإن جميع ملفاته ستكون مُتتبّعة وغير مُعدّلة لأنه -وبكل بساطة- قمت لتوك بسحبها ولم تحدث أية تغييرات عليها. بمُجرد أن تدخل تغييرات على أحد الملفات فسيعتبره Git ملفا مُعدّلا، حيث أن هذه الملفات قد طرأت عليها تغييرات منذ آخر إيداع. ما هي الخُطوة القادمة في هذه الحالة؟ ستقوم أولا بإدراج هذه التغييرات stage (أي وضع الملفات المعنية بالأمر في منطقة الإدراج) ومن ثم تقوم بإيداع تلك التغييرات commit، وستكرر هذه العملية طيلة استخدامك لـ Git، مثلما هو مُوضح في الصورة التالية: التحقق من حالة ملفاتك للتحقق من حالة ملفات مستودعك ستحتاج إلى استخدام الأمر git status. إن قمت بتنفيذ هذا الأمر مُباشرة بعد قيامك باستنساخ مُستودع فإنه يُفترض بهذه النتيجة أن تظهر: $ git status On branch master nothing to commit, working directory clean وهو ما يعني بأنك أمام مُجلد عمل نظيف. بعبارة أخرى لم يتم إحداث تغييرات على أي ملف مُتتبَّع. في هذه الحالة أيضا لا يُظهر Git أي ملفات غير مُتتبعة، لأنه لو كان الأمر غير كذلك فسيقوم حتما بإعلامك بالأمر. يُخبرك هذا الأمر بالفرع branch الذي تتواجد فيه، ومثلما هو ظاهر من النتيجة السابقة فإننا حاليا في الفرع الرئيسي master وهو الفرع الذي يتم استعماله بشكل قياسي. لنفرض الآن بأنك قُمت بإضافة ملف جديد إلى مشروعك، ولنفرض بأنه ملف README. إذا لم يكن هذه الملف موجودا من قبل داخل هذا المُستودع ولدى قيامك بتنفيذ الأمر git status فإن اسم هذا الملف سيظهر في قسم الملفات غير المُتتبعة على النحو التالي: $ vim README $ git status On branch master Untracked files: (use "git add <file>..." to include in what will be committed) README nothing added to commit but untracked files present (use "git add" to track) عدم التتبع عنها يعني بأن git قد عرف بأن الملف لم يكن في اللقطة السابقة لمشروعك (أي آخر إيداع)، لكنه لن يشرع في تتبعه بشكل آلي ما لم تقم أنت بطلب ذلك بشكل صريح، وستجد بأن ذلك مُفيد جدا خاصة لما تعمل على مشروع يُنتج الكثير من الملفات المُوقتة التي لا ترغب في تتبعها. تتبع الملف الجديد الآن وللشروع في تتبع الملف الجديد فإننا سنحتاج إلى الأمر git add على النحو التالي: $ git add README وإذا قمت بتنفيذ الأمر git status من جديد فإن الملف سيظهر مُتتبعا ومُدرجا: $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README بإمكانك معرفة أن الملف في منطقة الإدراج لأنه يظهر في قسم التغييرات التي سيتم إيداعها "Changes to be committed". إذا قمت بإدراج الملف في هذه المرحلة فإن حالة الملف لدى تنفيذك للأمر git add هي التي ستتم إضافتها إلى اللقطة. يُمكنك تحديد مسار ملف أو مُجلد لدى تنفيذك لأمر git add، ولدى تحديد مُجلد فإنه ستتم إضافة جميع مُحتوياته. إدراج الملفات المعدلة لنقم الآن بتعديل ملف سبق وأن شرعنا في تتبع التغيرات الطارئة عليه. لو أدخلنا تغييرات على الملف benchmark.rb ومن ثم نفذنا الأمر status من جديد لحصلنا على نتيجة مُماثلة لهذه النتيجة: $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: benchmarks.rb أين يظهر ملف benchmark.db تحت قسم "Changes not staged for commit" (تعديلات لم يتم إدراجها لإيداعها).ومثلما هو ظاهر من هذا الوصف فأننا قمنا بإدخال تعديلات على ملف مُتتبع ولم يتم إدراج تلك التغييرات بعد. ولإدراج هذه التغييرات يكفي أن نُنفذ الأمر git add الذي لديه عدة استخدامات كالشروع في تتبع الملفات مثلما سبق وأن شاهدناه، إدراج الملفات وللقيام بأمور أخرى كتعليم ملفات الدمج المُتضاربة merge-conflicted files كمحلولة. $ git add benchmarks.rb $ git status On branch master Changes to be committed: > (use "git reset HEAD <file>..." to unstage) new file: README modified: benchmarks.rb مثلما نلاحظه الآن، تم إدراج كلا الملفين وسيتم أخذ التغييرات الطارئة عليهما في الحسبان في عملية الإيداع القادمة. لكن لنفرض بأنك تذكرت تغييرا آخرًا تود إدخاله على ملف قبل أن تقوم بعملية الإيداع، وعليه فإنك ستقوم بالتعديل عليه قبل إيداعه. لكن لو قمت الآن بتنفيذ أمر git status من جديد فستظهر هذه النتيجة: $ vim benchmarks.rb $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README modified: benchmarks.rb Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: benchmarks.rb غريب؟ أليس كذلك؟ يظهر ملف benchmark.rb على أساس أنه مُدرج وغير مُدرج في آن واحد. هل هذا ممكن؟ نعم هذا مُمكن حيث يقوم git بإدراج الملف في حالته التي كان عليها لدى تنفيذ الأمر git add وبالتالي لو قمت بالإيداع الآن فإنه سيتم إيداع ملف benchmark.rb في حالته التي كان عليها لدى تنفيذ الأمر git add وليس على الحال التي هو عليها الآن، وبالتالي فإنه يجب تنفيذ الأمر git add لإدراج تلك التغييرات في كل مرة تقوم بإدخال التعديلات على الملف: $ git add benchmarks.rb $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README modified: benchmarks.rb تجاهل ملفات عادة ما تكون لديك في المشروع الذي تعمل عليه جُملة أو صنف من الملفات التي لا ترغب من Git أن يقوم بإضافتها بشكل آلي أو حتى في إظهارها كملفات غير مُتتبعة، وعادة ما تكون هذه الملفات تلك التي يتم توليدها بشكل آلي مثل ملفات log أو الملفات التي تنتج عن نظام البناء الخاص بك build system. في مثل هذه الحالات فإن الحل يكمن في استخدام ملف gitignore. الذي يحتوي أنماط أسماء هذه الملفات غير المرغوب فيها: $ cat .gitignore *.[oa] *~ يطلب السطر الأول في الملف (ولا أعني بذلك الأمر cat) من Git أن يتجاهل جميع الملفات التي تنتهي بـ o. أو a. (الكائنات وملفات الأرشيف التي يُحتمل أن تنتج عن عملية بناء شفرتك البرمجية). أما السطر الثاني فيطلب من Git أن يتجاهل جميع الملفات التي تنتهي أسماؤها بمحرف ~ والتي تستخدمها بعض محررات النصوص كمُحرر Emacs لحفظ الملفات المؤقتة. بإمكانك أيضا أن تُضمن في هذا الملف ملفات log ،tmp أو مجلد pid والتوثيق التي يتم توليده بشكل آلي وما إلى ذلك. الشروع في إعداد ملف gitignore. قبل الشروع في العمل على المشروع من شأنه أن يُجنبك إيداع ملفات لا ترغب أن تظهر في مستودعك لاحقا. القواعد العامة التي تتبعها أنماط أسماء الملفات المُضمنة في ملف gitignore. هي على النحو التالي: يتم تجاهل الأسطر الفارغة والأسطر التي تبدأ بمحرف # يتم أخذ الأنماط المبسطة للتعابير القياسية Standard glob patterns في الحسبان بإمكانك إنهاء النمط بـ / للدلالة على المجلدات. بإمكانك عكس النمط بتسبيقه بعلامة تعجب ! الأنماط المبسطة للتعابير القياسية Standard glob patterns هي نسخة مُبسطة من التعابير القياسية التي يُمكن استخدامها على سطر الأوامر. فـ * تدل على 0 أو أكثر من محرف، و [abc] تتوافق مع أي حرف ضمن هذه القائمة (في هذه الحالة: a ،b و c). أما علامة الاستفهام فتتوافق مع محرف واحد. أما لو استخدمنا هذه الصيغة [0-9] فإنها ستوافق أي محرف يقع ما بين 0 و 9. إليكم مثالا آخر عن ملف gitignore.: # a comment - this is ignored # no .a files *.a # but do track lib.a, even though you're ignoring .a files above !lib.a # only ignore the root TODO file, not subdir/TODO /TODO # ignore all files in the build/ directory build/ # ignore doc/notes.txt, but not doc/server/arch.txt doc/*.txt # ignore all .txt files in the doc/ directory doc/**/*.txt النمط **/ مُتوفر بداية من الإصدار 1.8.2 إظهار التغييرات المدرجة وغير المدرجة إذا كانت النتيجة التي يُظهرها الأمر git status غير دقيقة بالنسبة إليك أو إن كنت ترغب في معرفة التغييرات التي حصلت بدقة وليس مجرد معرفة قائمة الملفات التي تم تغييرها فإنه بإمكانك الاستعانة بالأمر git diff للقيام بذلك. لسنا هنا بصدد تفصيل الأمر git diff (سنقوم بذلك في مقال لاحق) لكنك ستحتاجه للإجابة على سؤالين مُحددين: ما الذي قُمت بالتعديل عليه ولم تقم بإدراجها بعد، وما الذي قمت بإدراجه لكن لم تقم بإيداعه بعد. بالرغم من أنه بإمكان git status الإجابة على هذين السؤالين، إلا أن الأمر git diff كفيل بالإجابة عنها بشكل أدق، حيث سيخبرك عن أي سطر تمت إضافته وعن أي سطر تمت إزالته. لنفرض بأنك قمت بتحرير وإيداع ملف README من جديد ومن ثم قمت بتحرير ملف benchmarks.rb من دون إدراجه. لو قمت بتنفيذ الأمر status فإنك ستحصل على نتيجة مُشابه للنتيجة التالية: $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: benchmarks.rb لكن لو رغبت في معرفة التغييرات التي حصلت والتي لم يتم إدراجها فاستعن بالأمر git diff: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb index 3cb747f..da65585 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -36,6 +36,10 @@ def main @commit.parents[0].parents[0].parents[0] end + run_code(x, 'commits 1') do + git.commits.size + end + run_code(x, 'commits 2') do log = git.commits('master', 15) log.size يقوم هذا الأمر بمقارنة مُحتوى مُجلد العمل بما هو موجود في منطقة الإدراج، وبالتالي فإن النتيجة ستُخبرك بالتغييرات التي قُمت بها والتي لم تقم بإدراجها بعد. أما إذا أردت رؤية التغييرات المُدرجة التي سيتم أخذها في الحسبان في الإيداع القادم فما عليك سوى استخدام الأمر git diff --cached (في الإصدار 1.6.1 والإصدارات التي تليه أصبح بالإمكان استخدام الأمر git diff --staged بدلا عنه، حيث يُعتبر هذا الأمر أسهل للتذكر من سابقه). يقوم هذا الأمر بمقارنة مُحتوى منطقة الإدراج بآخر إيداع قمت به: $ git diff --cached diff --git a/README b/README new file mode 100644 index 0000000..03902a1 --- /dev/null +++ b/README2 @@ -0,0 +1,5 @@ +grit + by Tom Preston-Werner, Chris Wanstrath + http://github.com/mojombo/grit + +Grit is a Ruby library for extracting information from a Git repository تجدر الإشارة إلى أن الأمر git diff بدون أية معاملات إضافية لا يقوم بإظهار كل التغييرات التي قُمت بها منذ آخر إيداع، حيث تكتفي بإظهار التغييرات التي لم يتم إدراجها. هذا الأمر قد يكون مُربكا بعض الشيء بحكم أنه لو قمت بإدراج جميع التغييرات التي قمت بها فإن أمر git diff لن يُظهر أية نتيجة. مثال آخر، لو قمت بإدراج الملف benchmarks.rb ومن ثم قمت بالتعديل عليه فإنه بإمكانك استخدام الأمر git diff لرؤية التغييرات التي تمت على الملف والتي تم إدراجها وتلك التغييرات التي لم يتم إدراجها أيضا: $ git add benchmarks.rb $ echo '# test line' >> benchmarks.rb $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: benchmarks.rb Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: benchmarks.rb الآن يُمكنك استخدام الأمر git diff لمعرفة ما الذي لم يتم إدراجه بعد: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb index e445e28..86b2f7c 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -127,3 +127,4 @@ end main() ##pp Grit::GitRuby.cache_client.stats +# test line والأمر git diff --cached لمعرفة ما الذي قُمت بإدراجه إلى حد الآن: $ git diff --cached diff --git a/benchmarks.rb b/benchmarks.rb index 3cb747f..e445e28 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -36,6 +36,10 @@ def main @commit.parents[0].parents[0].parents[0] end + run_code(x, 'commits 1') do + git.commits.size + end + run_code(x, 'commits 2') do log = git.commits('master', 15) log.size إيداع التغييرات الآن وبعد أن قمت بإعداد منطقة الإدراج على النحو الذي ترغب فيه، بإمكانك الآن القيام بإيداع التغييرات التي قمت بها. تذكر دائما بأن أي تغيير لم تم بإيداعه -أي ملف قمت بإنشائه أو التعديل عليه والذي لم تقم بإضافته بتنفيذ الأمر git add عليه منذ إنشائه أو منذ آخر تحديث عليه- لن يتم أخذه بالحسبان في الإيداع القادم، بل سينظر إليه النظام كملف تم تعديله. في هذه الحالة، ولدى تنفيذك للأمر git status آخر مرة فإنك لاحظت بأنه تم إدراج جميع التغييرات وبالتالي فإنك جاهز لإيداع التغييرات. يتم ذلك باستخدام الأمر git commit على النحو التالي: git commit تنفيذ هذا الأمر سيقوم بفتح مُحرر النصوص المُفضل لديك (والذي يتم تحديده عبر قيمة مُتغيرالنظام EDITOR$ والذي يُمكن أن يكون vim ،emacs أو أي مُحرر نصوص آخر، كما أنه يُمكنك تحديد عبر الأمر git config --global core.editor مثلما سبق وأن تطرقنا إليه في درس إعداد Git للمرة الأولى. سيقوم المُحرر بإظهار النص التالي (المثال التالي مأخوذ من مُحرر النصوص Vim): # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # new file: README # modified: benchmarks.rb # ~ ~ ~ ".git/COMMIT_EDITMSG" 10L, 283C مثلما نلاحظه هنا فإن نص/رسالة الإيداع القياسية تحتوي مُخرجة الأمر git status على هيئة تعليق، إضافة إلى سطر فارغ يسبق ذلك. بإمكانك حذف هذا التعليق وكتابة النص الذي ترغب فيه، كما أنه بإمكانك الإبقاء عنها لتتذكر الملفات التي تم تعديلها في هذا الإيداع ( للحصول على تذكير أدق يُمكنك تمرير المُعامل v- لأمر git commit سابق الذكر، وستحصل حينها على تفاصيل التغييرات التي حدثت على الملفات لما يتم فتح المُحرر المفضل لديك). لدى إغلاقك لمحرر النصوص سيقوم Git بإنشاء الإيداع ويقوم بإرفاق ذلك النص/الرسالة به مع التخلص من التعليقات وتفاصيل التغييرات التي أدخلت على الملفات. يُمكنك أيضا كتابة نص الإيداع مُباشرة مُرفقا بأمر الإيداع وذلك بتسبيقه بـ m- على النحو التالي: $ git commit -m "Story 182: Fix benchmarks for speed" [master 463dc4f] Story 182: Fix benchmarks for speed 2 files changed, 3 insertions(+) create mode 100644 README كما تلاحظ فإنك قمت بعمل أول عملية إيداع لك وحصلت على بعض المعلومات حوله، كاسم الفرع الذي ينتمي إليه (master) وما هي قيمة هاش SHA-1 الخاصة به 463dc4f، عدد الملفات التي تم تحديثها، إضافة إلى عدد الأسطر التي تمت إضافتها أو حذفها. يجب التذكير بأن عملية الإيداع تقوم بأخذ صورة عن البيانات التي تم إدراجها وأي تغييرات لم تقم بإرسالها إلى منطقة الإدراج لن يتم أخذها بالحسبان، وعليه يجب إضافتها من جديد إلى منطقة الإدراج قبل إيداعها من جديد. كل مرة تقوم فيها بعملية إيداع فإنك تأخذ صورة عن حالة مشروعك في اللحظة التي تم التقاط تلك الصورة فيها وبإمكانك الرجوع إلى تلك الحالة لاحقا إن رغبت في ذلك. تجاوز منطقة الإدراج بالرغم من أن منطقة الإدراج في غاية الأهمية لتمكيننا من "بناء" إيداعات على الشكل الذي نرغب فيه، إلا أنها تُعتبر في بعض المرات مرحلة إضافية لا نرغب فيها. إذا رغبت في تجاوز منطقة الإدراج ما بين الحين والآخر فإن Git يسمح لك بالقيام بذلك، حيث يكفي إضافة خيار a- إلى أمر git commit ليقوم git بإضافة جميع الملفات التي كنت تتبعها سابقا قبل عملية الإيداع الحالية (يعني يقوم باختصار أمر git add). $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: benchmarks.rb no changes added to commit (use "git add" and/or "git commit -a") $ git commit -a -m 'added new benchmarks' [master 83e38c7] added new benchmarks 1 files changed, 5 insertions(+) لاحظ كيف أننا لم نحتج إلى تنفيذ الأمر git add على الملف benchmarks.rb في هذه الحالة قبل أن تقوم بعملية الإيداع. حذف الملفات لحذف ملف من مشروع Git فإنه يجب عليك أن تحذفه من قائمة الملفات المُتتبّعة (أو بالأحرى من قائمة الملفات المُدرجة) قبل أن تقوم بعملية إيداع. يُمكّن أمر git rm من القيام بذلك ويقوم بحذف الملف من مُجلد العمل مما سيُجنّب ظهوره في قائمة الملفات غير المُتتبعة. إذا قمت بحذف الملف يدويا من المشروع فإن اسمه سيظهر في قائمة التغييرات التي لم يتم إدراجها لما تقوم بتنفيذ الأمر git status: $ rm grit.gemspec $ git status On branch master Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) deleted: grit.gemspec no changes added to commit (use "git add" and/or "git commit -a") ومن ثم إذا قمت بتنفيذ الأمر git rm فإنه سيتم "إدراج" الملف للحذف: $ git rm grit.gemspec rm 'grit.gemspec' $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) deleted: grit.gemspec وفي المرة القادمة التي تقوم فيها بالإيداع فإن الملف سيختفي كُليّة. إذا كنت قد عدّلت على الملف وقمت بإضافته إلى الفهرس index فإنه يجب فرض إزالته عبر تمرير الخيار -f. يتم الاستعانة بذلك لتجنب حذف بيانات لم يتم تسجيلها في سجلات Git عن طريق الخطأ (وبالتالي لن يُصبح بالإمكان استرجاعها). أمر آخر قد ترغب في القيام به والمُتعلق بحذف الملف من git مع إبقائه في مُجلد العمل الخاص بك. بعبارة أخرى قد تكون أضفت ملفا مُعينا عن طريق الخطأ ولكن لا ترغب في مواصلة تتبعه عبر git، وعادة ما يكون الأمر مُتعلقا بملفات نسيت إضافتها إلى gitignore. كملفات log كبيرة الحجم أو ملفات a. الناتجة عن ترجمة المشروع. كل ما تحتاج إلى القيام به هو إضافة خيار cached-- على الشكل التالي: $ git rm --cached readme.txt بإمكان تمرير أسماء ملفات، مُجلدات أو حتى أنماطا مُبسطة للتعابير القياسية file-glob patterns لأمر git rm. يعني يُمكن القيام مثلا بالتالي: $ git rm log/\*.log لاحظ وجود محرف \ الذي يسبق * والذي يُعتبر ضروريا لأن git يستعمل نظامه الخاص لتفسير هذه الأنماط إضافة إلى النظام الخاص بسطر الأوامر الذي تستخدمه. أما على نظام Windows فإنك لن تحتاج إلى إضافته. يقوم هذا الأمر بحذف جميع الملفات التي تملك المُلحق log. في مُجلد log/. بإمكانك أيضا تنفيذ الأمر التالي لحذف جميع الملفات التي تنتهي أسماؤها بـ ~: $ git rm \*~ نقل الملفات على عكس ما هو مُتداول عليه باقي أنظمة إدارة الإصدارات فإن Git لا يقوم بتتبع حركة الملفات بشكل مُباشر. إن قمت بتغيير اسم ملف مثلا فإن git لا يحتفظ بأية بيانات حول الأمر، إلا أن النظام يملك مقدارا مُعينا من "الذكاء" يسمح له باستنتاج ذلك لاحقا. سنقوم بالتطرق لتتبع حركة الملفات في مقال لاحق. قد يبدو الأمر غامضا نوعا ما خاصة وأن git يملك الأمر mv. إن أردت إعادة تسمية ملف فإنه يُمكن القيام بذلك على النحو التالي: $ git mv file_from file_to وسيتم ذلك على النحو المُتوقّع، حيث يظهر ذلك واضحا على النحو التالي: $ git mv README README.txt $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) renamed: README -> README.txt في المقابل، الأمر السابق مُماثل في نتيجته للتالي: $ mv README README.txt $ git rm README $ git add README.txt حيث سيعرف git بأنك تقوم بإعادة تسمية الملف، وبالتالي لا يهم الآلية التي تتبعها للقيام بذلك. الاختلاف الوحيد ما بين الطريقتين هو أن mv عبارة عن أمر واحد بدل الأوامر الثلاثة في الطريقة الثانية. الأهم من ذلك يُمكن الاستعانة بأية طريقة ترغب فيها لإعادة تسمية الملفات، كل ما يهمك أن تقوم بتنفيذ أوامر add/rm اللازمة قبل أن تقوم بعملية الإيداع. ترجمة -وبتصرف- للفصلين: Git Basics – Getting a Git Repository و Git Basics – Recording Changes to the Repository من كتاب Pro Git لصاحبه Scott Chacon.

وأخيرا اقتنعت بفلسفة المصادر المفتوحة، أو أنك أخيرا وجدت الوقت للمُساهمة في أحدها، وربما ما دفعك إلى الأمر هو استفادتك من مشروع مفتوح المصدر وأردت أن ترد الجميل بالمساهمة فيه بدورك، لكن لا تدري كيف تقوم بذلك؟ الأمر بسيط، كل ما تحتاجه هو جهاز محلي يكون Git مُنصبا عليه، حساب على Github وبعض الوقت، ومن ثم اتباع بضع خُطوات بسيطة. تجدر الإشارة إلى أنك لا تحتاج إلى أن تكون مُبرمجا للمُساهمة في المشاريع مفتوحة المصدر، يُمكنك المُساهمة في إنشاء أو تحسين توثيق المشروع، حيث يُعتبر التوثيق الجيد أحد أهم عوامل نجاح المشاريع مفتوحة المصدر، وانتشار بعضها على حساب الآخر. لنفرض أن المشروع الذي تود المُساهمة فيه هو "git – الدّليل البسيط". 1. قم باستنساخ المشروع إلى حسابك الخاص وذلك بالنقر على زر Fork الموجود في الزاوية العُلوية اليُمنى لصفحة المشروع. هذه العملية من شأنها أن تُنشئ نُسخة مُطابقة للمُستودع الأصلي على حسابك على Github. 2. بعد ذلك قم باستنساخ هذا المُستودع الجديد على جهازك المحلي. ادخل إلى المجلد الذي تود استنساخ المُجلد فيه (cd path/to/folder) وقم بتنفيذ الأمر git clone متبوعا بعُنوان المُستودع. ستجد العُنوان أسفل القائمة اليُمنى في صفحة المُستودع. بالنسبة لي سيكون الأمر على النحو التالي: git clone https://github.com/djug/simple-guide.git 3. الآن وبعد أن حصلت على هذه النُسخة، قم بإدخال التعديلات التي ترغب فيها واحفظ تلك التعديلات. قبل أن نقوم بإيداع تلك التعديلات، يُنصح دائما التحقق من حالة المُستودع، وإن تم أخذ التعديلات بالحسبان أو إن قمنا بتعديل ملف لم نكن نرغب في تعديله، حيث يكفي أن ننفذ الأمر git status لمعرفة حالة المُستودع (النسخة المحلية): git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: index.ar.html4. تبدو الأمور طبيعية. لنقم بإرسال التغييرات إلى منطقة الإدراج: git add .ومن ثم إيداعها (commit): git commit -m "Your commit Message Here"بطبيعة الحال ستحتاج إلى وضع وصف مُناسب للتغييرات التي قمت بها. بإمكانك أيضا تنفيذ الأمر commit لوحده من دون أية رسائل: git commitوسيقوم git بفتح مُحرر النصوص المُفضل لديك لكتابة الوصف (في حال ما إذا قمت بتحديد اسم هذا المُحرر في إعدادات git). سنحتاج الآن إلى إرسال هذه التغييرات إلى المُستودع (الشخصي وليس مُستودع المشروع الذي نشارك فيه) على Github عبر تنفيذ الأمر: git push origin masterسيطلب منك Git اسم المُستخدم الخاص بك على Github وكلمة السر، وبمُجرد أن يتم التحقق منهما سيتم دفع التغييرات إلى مُستودعك الخاص. 5. الآن لو عدنا إلى صفحة المُستودع الشخصي على Github سيظهر لنا تاريخ آخر تحديث للملفات المُعدلة ووصف له. وكل ما نحتاج إلى فعله الآن هو إرسال "طلب سحب" pull request -أي سحب التغيرات- إلى المُستودع الأصلي للمشروع وذلك بالنقر على الزر الأخضر الذي يظهر في الزاوية العُلوية اليُمنى للمُستودع ستظهر لك صفحة لتلخص من جديد التغييرات التي تمت 6. الخطوة الأخيرة هي النقر على زر Create Pull request، إضافة أية تعليقات ترغب فيها على الطلب، ومن ثم النقر على زر Send pull request: ستصل صاحب المشروع رسالة بخصوص التغييرات التي قمت بها، وفي حال قبولها سيصلك إشعار بها وستظهر تغييراتك على المستودع الأصلي: هذا كل ما في الأمر. أنت الآن بطريق… أقصد مُشارك في مشاريع مفتوحة المصدر بشكل رسمي. نصائح عامة لدى المساهمة في المشاريعاجعل نص الإيداع commit معبّرا أو ملخصا للتغيرات التي قمت بها، لا تجعله مبهما أو عاما.افصل طلبات السحب "pull request" حسب الغرض، أو اجعل لكل تغير تقترحه في branch لوحده حسب الغرض، مثال: لا ترسل طلب سحب يحتوي تغيرات مرئية في الـ html و css وفيه أيضا ترجمة النصوص إلى العربية، هكذا تصعب المهمة على من يقوم بعملية الدمج في حال كان يريد قبول الترجمة لكنه غير راض عن التغيرات التي طرأت في الـ html/css. في هذه الحالة سيكون من الأنسب:طلب سحب للتغيرات المرئية لوحده.طلب سحب آخر للملفات الترجمة إلى العربية.في حال كانت مساهمتك تحل علة ما تم التبليغ عنها في قسم الـ issues في مستودع المشروع على github، أو لها علاقة به، فإنه يمكنك الإشارة إلى تلك العلة في نص الإيداع فقط بوضع رقم العلة مسبوقا بعلامة #، مثال:git commit -m "fix for some bug (issue #23)"ستلاحظ عند زيارة واجهة Github أن الرقم 23# في نص الإيداع، قد أصبح رابطا يحول مباشرة إلى صفحة تلك العلة. في حال قمت بعمل Fork وساهمت في المشروع، وأردت مرة أخرى أن تساهم في ذاك المشروع مجددا، فلا تنس أن تجعل مستودعك الشخصي من ذاك المشروع محدّثا، يعني اجلب التغيرات الجديدة التي طرأت على المستودع الأصلي، قبل المساهمة مجددا وعمل أي commit أو pull request، هذا يخفض من نسبة التعارض conflicts، ويسهّل عليك وعلى القائمين على المشروع عمليات الدمج، قد تكون التغيرات التي قمت بها، قد قام بها آخر، أو ربما تم حذف الملف الذي تعمل عليه أصلا من المشروع الأصلي، فيضيع جهدك هباءا منثورا.من المحبذ أيضا، استعمال صيغة الأمر في نص الإيداع، مثال، استعمل "add something to file x" عوض "adding|added something to file x".

يأتي Git مُرفقا بأداة تُدعى git config والتي تسمح لك بقراءة إعدادات النظام وتغييرها والتحكم في كامل جوانب عمل Git. يتم حفظ هذه الإعدادات في الأماكن الثلاثة التالية: etc/gitconfig/: يحتوي هذا الملف على الإعدادات الخاصة بجميع المُستخدمين على نفس النظام/الجهاز أيّا كان المُستودع الذي يعملون عليه. في حال ما إذا قمت بتمرير خيار system-- إلى أمر git config فسيكون بإمكانك قراءة وتعديل الإعدادات الموجودة في هذا الملف.gitconfig./~: هذا الملف خاص بإعدادات المُستخدم الحالي فقط. بإمكانك قراءة الإعدادات من هذا الملف أو التعديل عليها عبر تمرير خيار global-- إلى الأمر git config.git/config.: هذا الملف المتواجد داخل كل مُستودع يحتوي الإعدادات الخاصة بالمستودع الذي يحتويه فقط. في حال ما إذا قمت بحفظ الإعدادات في مُستوى مُعين فإنه سيتم تجاهل إعدادات المُستوى الذي يعلوه. بعبارة أخرى، سيتم أخذ إعدادات ملف git/config. بالحسبان لو وُجدت وتجاهل إعدادات ملف etc/gitconfig/.على أنظمة Windows يقوم Git بالبحث عن ملف gitconfig. داخل مُجلد HOME$ أي داخل مُجلد C:\Documents and Settings\$USER أو C:\Users\$USER حسب إصدار نظام التشغيل المُستخدم. كما أنه يبحث أيضا عن ملف etc/gitconfig/ والذي يكون داخل المُجلد الذي قررت تنصيب Git فيه. هويتك على Gitمن بين الأمور التي يجب عليك القيام بها بمُجرد تنصيبك لنظام Git هو تحديد هويتك عليه ونقصد بذلك اسمك وعنوان بريدك الإلكتروني. هذه الخُطوة مُهمة لأن Git سيقوم بربط أي عملية تقوم بها بهذه الهوية، كما أن كل عملية إيداع ستقوم بها ستحمل هذه البيانات معها. يتم تحديد هوية المُستخدم عبر الأمرين التاليين: $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.comمن جديد، لن تحتاج إلى القيام بها الأمر سوى مرة واحد في حال ما إذا قمت بتمرير الخيار global-- للأمرين السابقين لأنه في هذه الحالة سيقوم Git باستخدام هذه الهوية مع جميع العمليات التي تتم على النظام/الجهاز الحالي. إذا رغبت في استخدام هوية مُختلفة مع مشاريع مُعينة فما عليك سوى تنفيذ الأمرين السابقين من دون تمرير الخيارglobal--. محرر النصوص الافتراضيالآن وبعد أن حددت هويتك على Git حان الأوان لاختيار مُحرر النصوص الذي ستستعمله لما يطلب منك Git كتابة رسالة أو تعليق على العمليات التي تقوم بها. في حال لم تقم باختيار مُحرر نصوص خاص فإن Git سيقوم باستخدام مُحرر النصوص الافتراضي لنظام التشغيل الخاص بك والذي عادة ما يكون Vi أو Vim. إن رغبت في استخدام مُحرر نصوص آخر وليكن Emacs فما عليك سوى تنفيذ الأمر التالي: $ git config --global core.editor emacsأداة Diff Toolخاصية أخرى تحتاج إلى إعداداها هي أداة diff tool والتي سيتم استخدامها لحل المشاكل المُتعلقة بعمليات الدمج. في حال ما إذا أردت استخدام vimdiff مثلا فما عليك سوى تنفيذ الأمر التالي: $ git config --global merge.tool vimdiffيستطيع Git التعامل مع جُملة من الأدوات بشكل قياسي وهي كالتالي: kdiff3tkdiffmeldxxdiffemergevimdiffgvimdiffecmergeopendiffالتحقق من الإعداداتإذا رغبت في التحقق من الإعدادات التي قمت بها فما عليك سوى تنفيذ الأمر: git config --list والذي يقوم بعرض النتائج على الشكل التالي: $ git config --list user.name=Scott Chacon user.email=schacon@gmail.com color.status=auto color.branch=auto color.interactive=auto color.diff=auto ...في حال ما إذا ظهرت قيم مُختلفة لنفس الخيار فهذا راجع إلى قراءة Git للإعدادات من أماكن مُختلفة ( /etc/gitconfigو ~/.gitconfig على سبيل المثال). في هذه الحالة فإن Git سيأخذ بالحسبان آخر قيمة في هذه القائمة. بإمكانك أيضا التحقق من الإعدادات بشكل فردي على باستخدام الأمر git config {key} مع استبدال ما يجب استبداله في الأمر: $ git config user.name Scott Chaconالحصول على المساعدةإن احتجت إلى أية مساعدة لدى استخدامك لنظام Git فيُمكنك الاستعانة بأحد الأوامر الثلاثة التالية للحصول على طريقة استخدام أي من أوامر Git: $ git help $ git --help $ man gitعلى النحو التالي (للحصول على شرح لأمر config): $ git help configهذه الأوامر مُفيدة جدا خاصة وأنها مُتوفرة دون الحاجة إلى اتصال إنترنت. إن كانت المصادر التي في حوزتك غير كافية وكنت تحتاج إلى مُساعدة شخصية ومباشرة فُيمكن زيارة قناتي git# و github# على خادوم Freenode IRC (على العنوان irc.freenode.net)، ستجد فيهما مجموعة كبيرة من خبراء Git والذين لديهم الرغبة في مساعدة من يطلبون المُساعدة. خلاصةبعد قراءتك لهذا المقال والمقالات السابقة التي نشرناها هنا فسيكون لديك فهم لأساسيات Git وفهم الاختلافات الموجودة بينه وبين باقي أنظمة إدارة النُسخ. سيكون لديك أيضا نظام Git جاهز للعمل على جهازك وإعدادات تضمن تضمين بياناتك الشخصية في كل عملية ستقوم بها. حان الآن الأوان للشروع في استخدام Git. ترجمة -وبتصرف- للفصل First-Time Git Setup من كتاب Pro Git لصاحبه Scott Chacon.

كما سبق ذكره فإن أحد أهم الاختلافات ما بين Git وأنظمة إدارة النُسخ هو الطريقة التي ينظر ويتعامل فيها Git مع البيانات. مبدئيا تقوم أغلب أنظمة إدارة النُسخ بحفظ البيانات على شكل قائمة من التغيرات التي طرأت على الملفات. هذه الأنظمة (CVS, Subversion، Perforce، Bazaar وهلم جرا) تنظر إلى البيانات التي تقوم بإدارتها على أساس أنها ملفات إضافة إلى التغييرات الحاصلة في كل ملف مع مرور الوقت، مثلما هو مُوضح في الشكل 1. الشكل 1: تقوم مُعظم الأنظمة بحفظ البيانات على هيئة الاختلافات الطارئة عليها مُقارنة بنسخة أولية من الملف. لا يتعامل Git مع البيانات على هذا النحو، بل يعتبر البيانات مجموعة من اللقطات Snapshots لنظام ملفات مُصغر. كل مرة تقوم فيها بإيداع البيانات (commit) أو تحفظ حالة مشروعك باستخدام Git، فإن ما يقوم به النظام هو التقاط صورة لما هي عليه الملفات في تلك اللحظة ويحفظها. ولجعل هذه الآلية فعالة فإنه لا يتم حفظ صور أخرى لنفس الملف ما إذا لم يتم إحداث تغييرات على الملف، بل يتم فقط الربط على الصورة السابقة. ينظر Git إلى البيانات التي يحفظها مثلما هو مُبين في الشكل 2. الشكل 2: يلتقط Git صورا على المشروع مع مرور الوقت. يُعتبر هذه الاختلاف في مبدأ العمل جوهريا، حيث يُعيد Git بشكل جذري تعريف كامل المفاهيم المُتعلقة بإدارة النُسخ التي توارثتها باقي الأنظمة عن الأنظمة التي سبقتها. هذا الاختلاف في مبدأ العمل يجعل Git أقرب ما يكون من نظام ملفات مُصغر منه إلى أنظمة إدارة النُسخ التقليدية، وهو ما مكّن من بناء أدوات في غاية القوة اعتمادا عليه. سنقوم باستعراض الفوائد المُترتبة عن مبدأ عمل Git المُختلف عن باقي الأنظمة لدى الحديث عن تفريعات Git في مقال لاحق. أغلب العمليات تتم بشكل محلي أغلب العمليات التي يقوم بها Git تحتاج فقط إلى ملفات محلية ليتم تنفيذها وذلك من دون الحاجة إلى أية بيانات من خواديم بعيدة. هذه الخاصية تُعطي الانطباع بأن Git سريع جدا مُقارنة بغيره من أنظمة إدارة النُسخ نظرا لكون كامل ملفات وتاريخ المشروع الذي تعمل عليه مُتوفرة بشكل محلي على خلاف باقي الأنظمة التي تحتاج إلى الاتصال بأجهزة وخواديم أخرى. فعلى سبيل المثال فحتى ولو احتجت إلى إلقاء نظرة على تاريخ المشروع أو مقارنة نسخ قديمة منه فإنك لن تحتاج إلى الاتصال بخادوم بعيد للقيام بذلك حيث يقوم Git بقراءته والاحتفاظ به كاملا على جهازك المحلي. هذه الخاصية تسمح لك أيضا بمواصلة العمل على مشروعك حتى ولو لم يكن لديك اتصال إنترنت، حيث يُمكنك إيداع البيانات commit في انتظار أن يكون بمقدورك الاتصال بالإنترنت من جديد. على باقي أنظمة إدارة الإصدارات، مواصلة العمل لدى انقطاع الإنترنت هو إما أمر مُستحيل أو معقد جدا. على نظام Perforce لا يُمكن القيام بأي شيء ما لم تكن مُتصلا بالخادوم الذي يدار عليه المشروع، أما Subversion وCVS فيسمحان لك بتحرير الملفات لكن لا يُمكن إدراج التغييرات ما لم تكن متصلا بخادوم مشروعك. قد لا تبدو هذه الخاصية مُهمة جدا لكن تأثيرها كبير. المحافظة على سلامة الملفات يتم التحقق من الملفات عبر عمليات checksum قبل حفظها، ومن ثم يتم استخدام ناتج هذه العملية (Cheksum) كمُعرف للملفات، يعني ذلك بأنه يستحيل تغيير مُحتوى ملف أو مُجلد من دون أن يعلم Git بذلك. هذه الخاصية هي إحدى الخواص التي بُني عليها Git والتي يعتمد عليها في الطبقات السُفلى من النظام، كما أنها جزء لا يتجزأ من المبادئ الأساسية التي بُني عليها. بفضل هذه الخاصية فإنه من غير المُمكن أن تفقد أية بيانات لدى نقلها أو أن يُصاب ملف ما بالعطب من دون أن يكون هناك لدى Git علم مُسبق بالأمر. يُطلق على الآلية التي يعتمد عليها Git للتحقق من الملفات اسم SHA-1 hash، تنتج عنها سلسلة نصية مُتكونة من 40 محرف ستعشري (الأرقام من 0 إلى 9 والحروف من a إلى f) ويتم حسابها اعتمادا على مُحتوى الملف أو المُجلد. سلاسل SHA-1 hash تكون مُشابهة للسلسلة التالية: 24b9da6552252987aa493b52f8696cd6d3b00373 لدى استخدامك لنظام Git ستشاهد هذه السلاسل في كل مكان بحكم أنه يتم استخدامها كثيرا حيث أن Git يحفظ كل شيء اعتمادًا على Hash مُحتوى كل ملف وليس اعتمادًا على أسمائها. لا يقوم Git عادة سوى بإضافة بيانات أغلب العمليات التي تقوم بها على Git تقوم بإضافة بيانات إضافية إلى قاعدة بيانات Git. من الصعب جدا أن تجعل النظام يقوم بعمليات لا يُمكن التراجع عنها أو حذف بيانات لا يُمكن استرجاعها. لدى استخدام باقي أنظمة إدارة النسخ فإنه من المُمكن أن تخسر أو تعبث ببيانات لم تقم بإدراجها بعد، لكن لدى القيام بعملية إدراج فإنه من الصعب جدا أن تفقدها خاصة ما إذا كنت تقوم بدفع البيانات إلى مستودع موجود على خادوم بعيد. هذا الأمر يجعل استخدام Git مُمتعا في حد ذاته، حيث أنه بإمكاننا القيام بأية تجارب نودها على مشاريعنا دون أن نعرض بياناتها للخطر. الحالات الثلاث للبيانات على Git إن قرأت ما سبق ذكره على عجل، فيجب أن تركز جيدا في هذه الفقرة حيث أننا سنناقش المبدأ الأساسي الذي لا يُمكن لك استخدام Git ما لم تستوعبه جيدا. لدى استخدام Git فإن الملفات تملك إحدى الحالات الثلاث التالية: مرحلة الإيداع (ملفات تم إيداعها committed)، مرحلة التعديل (ملفات أجريت تعديلات عليها modified) ومرحلة الإدراج (ملفات تم إدراجها staged). المقصود بالإيداع commit هو أن حفظ البيانات بشكل آمن في قاعدة البيانات المحلية. الملفات التي تم تعديلها هي التي تم إدخال تغييرات عليها لكنه لم يتم حفظ تلك التغييرات إلى قاعدة البيانات المحلية بعد. أما الإدراج فهو تعليم الملفات التي تم تعديلها في حالتها الحالية ليتم تضمينها في الإيداع القادم. هذه الحالات الثلاث تُقسم مشاريع Git إلى 3 أقسام: مُجلد Git، مُجلد العمل، ومنطقة الإدراج. الشكل 3: مُجلد Git، مُجلد العمل ومنطقة الإدراج مُجلد Git هو المكان الذي يقوم النظام فيه بتخزين البيانات الوصفية metadata وقاعدة بيانات مشروعك، ويُعتبر الجزء الأهم من Git حيث أنه المُجلد الذي يتم نسخه لدى القيام بعملية استنساخ المُستودعات الموجودة على أجهزة أخرى. مُجلد العمل عبارة عن إصدار المشروع الحالي والذي يحتوي ملفات تم استخراجها من قاعدة بيانات Git ووضعها تحت تصرفك لإدخال التعديلات التي ترغب فيها عليها. منطقة الإدراج عبارة عن ملف واحد يتم الاحتفاظ به عادة داخل مُجلد Git والذي يحفظ معلومات حول المُحتوى الذي سيتم إرساله في الإيداع القادم. عادة ما تتم الإشارة إليه باسم الفهرس index لكن استخدام مُصطلح “منطقة الإدراج” staging area أصبح الأكثر شيوعا. سير عمل مشاريع Git يتم عادة على النحو التالي: التعديل على الملفات الموجودة في مُجلد العمل. إضافة الملفات إلى منطقة الإدراج إيداع الملفات commit، أي التقاط صورة عن الملفات الموجودة في منطقة الإيداع وحفظها بشكل دائم داخل مُجلد Git. لتلخيص الأمر: إذا كان الملف موجودا داخل مُجلد Git فهذا يعني بأنه تم إيداعه committed. إذا تم إدخال تغييرات عليه وتم وضعه في منطقة الإيداع فهذا ملف مُدرج staged. أما إذا تم إحداث تغييرات عليه ولم يتم نقله إلى منطقة الإدراج فيُعتبر مُعدّلا. في مقال قادم سنتحدث بشكل أوسع حول الحالات الثلاث هذه وكيفية الاستفادة منها بشكل جيد، إضافة إلى كيفية تجاوز منطقة الإدراج بشكل كامل. ترجمة -وبتصرف- لـ Git Basics من كتاب Pro Git لصاحبه Scott Chacon.