المحتوى عن 'سير العمل'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • التجارة الإلكترونية
  • الإدارة والقيادة
  • مقالات ريادة أعمال عامة

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML
    • HTML5
  • CSS
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • Sass
    • إطار عمل Bootstrap
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات برمجة عامة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • التسويق بالرسائل النصية القصيرة
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 3 نتائج

  1. لا ترتبط ثقافة الشركة بامتلاك مكان عملٍ فاخر؛ بل ترتبط بامتلاك فريق عمل منتج ينسجم أعضاؤه مع بعضهم بعضًا ويعملون تجاه تحقيق هدفٍ مشترك. يختار العديد من الموظفين في وقتنا الحالي العمل عن بعد لكي يستمتعوا بحياتهم ويحصلوا على المزيد من الحرية؛ فمع تطور التكنولوجيا، أصبح من السهل على الناس أن يعملوا من المكان الذي يريدونه وفي الوقت الذي يرغبونه مع حفاظهم على مستوى عالٍ من الإنتاجية. يذكر كتاب Remote: Office Not Required: «تتمثل النقلة النوعية المتعلقة بوجود قوة عاملة موزَّعة في التحوِّل من أسلوب التعاون المتزامن إلى التعاون غير المتزامن، إذ إلى جانب عدم وجود ضرورة في أن يتواجد الجميع في نفس البقعة الجغرافية لكي يعملوا سويًا، فليس هناك -أيضًا- ضرورةً في أن يعملوا سويًا في وقتٍ واحد.» مزايا وعيوب العمل عن بعد إنّ العمل عن بعد ليس حلًا مثاليًا لا عيب فيه، ولكن له مزايا عديدة منها: 1. سهولة تحقيق التوازن بين الحياة المهنية والحياة الشخصية يمنح العمل عن بعد الموظفين إحساسًا بالحرية التي تجعلهم قادرين على تنفس الحياة خارج جدران العمل، إذ يمكنهم تنظيم يومهم بحيث يشمل قضاء وقت مع العائلة، وحضور المواعيد، وأمور شخصيّة أخرى. الوقت الذي يقضيه الناس للذهاب إلى العمل في الوظائف الاعتيادية (والتوتر الذي ينشأ عنه) لا يجعل الموظفين يتمتّعون بتوازن جيّد بين الحياة المهنية والحياة الشخصية. 2. مُحصِّلة عدد الساعات التي يعملها الموظفون عن بعد أكبر بيّنت تجربة أجراها باحثون من جامعة ستانفورد أنّ الأفراد الذين يعملون من المنزل سجَّلوا عدد ساعاتٍ أكثر من أولئك الذين يعملون في المكاتب أثناء فترة مناوبتهم المعتادة، كما أنّهم أخذوا إجازات مَرَضية أقل؛ وهذا يعني أنّهم استطاعوا العمل لساعاتٍ أكثر بالمجمل. وقد أظهرت دراسة أجرتها شركة غالوب (Gallup) أنّ عدد ساعات العمل التي يقضيها الموظفون عن بعد أكثر بمعدل أربع ساعات في الأسبوع من تلك التي يقضيها نظراؤهم الذين يعملون في المكاتب. 3. الموظفون عن بعد أكثر إنتاجية لا يعمل الموظفون عن بعد لساعاتٍ أكثر فحسب؛ بل إنّهم –أيضًا- يكونون عادةً أكثر إنتاجيّة نتيجة وجودهم في بيئة أكثر هدوءًا، كما أنّ طاقتهم لا تُستنزف بسرعة لأنّهم قادرون على تحقيق التوازن في حياتهم على نحوٍ أفضل، وهذا يُمكِّنهم من الحفاظ على معدل إنتاجيّتهم لمدة أطول. 4. معدل دوران الموظفين عن بعد أقل يُقصد بدوران الموظفين: ترك الموظفين لوظائفهم الحاليّة والانتقال إلى وظائف أخرى. في تجربة جامعة ستانفورد سابقة الذكر، تبَيَّن أيضًا أنّ معدل دوران العاملين من المنزل كان أقل بنسبة 50% تقريبًا مقارنةً بالمجموعة الضابطة. إنّ هذه الإحصائية مهمّة للغاية إذا ما توقفت للتفكير بها. رغم أنّ كلّ ما سبق يبدو رائعًا، إلا أنّه ليس مثاليًا تمامًا، إذ هناك بعض العيوب المتعلِّقة بالسماح للموظفين بالعمل من المنزل منها: 1. ضرورة أن يكون الموظفون عن بعد منظمين بدرجة كبيرة من السهل جدًا أن يتشتّت انتباهك أو أن تفتر همَّتك عندما تعمل عن بعد (ألا ترغب في الاسترخاء ومشاهدة بعض مقاطع الفيديو عبر Netflix؟). معظم الناس ليس لديهم التركيز أو التنظيم الكافي الذي يؤهِّلهم لكي يكونوا من ضمن الموظفين الجيّدين العاملين عن بعد، ولذلك يقع على عاتقك -بصفتك مديرًا- التأكّد من أنّ الموظفين عن بعد لديهم كل ما يؤهّلهم لإنجاز عملٍ جيّد. 2. صعوبة بناء ثقافة مشتركة لا شكّ أنّ بناء ثقافة مشتركة مع الموظفين عن بعد أمرٌ ممكن، ولكنّه أصعب من عملية بنائها مع الذين يعملون في المكاتب التقليدية. وبطبيعة الحال، كلّما اجتمع أعضاء الفريق مع بعضهم بعضًا، توطَّدت علاقاتهم وزادت الثقافة المشتركة بينهم. صحيحٌ أنّ الأدوات والبرامج يمكنها أن تُبقيَ الجميع على اتصال وأن تخلق شعورًا بوجود غاياتٍ مشتركة، ولكنّها حتمًا تتطلّب الكثير من الجهد والالتزام. 3. عملية التواصل أصعب هناك حاجة إلى وجود أفراد يجيدون التواصل؛ بل وحتى أفراد يجيدون الكتابة ضمن فريق العمل. ينبغي -برأيّي- أن تكون الكتابة هي المهارة الأولى التي يبحث عنها المديرون عند توظيف أحد الموظفين عن بعد. الكثير من عمليات التواصل ستتم عبر المحادثات المكتوبة أو البريد الإلكتروني، لذلك أنت في حاجة إلى التعامل مع أشخاص يستطيعون توضيح أفكارهم ويمتلكون سرعة في الفهم، كما أنّك في حاجة إلى التواصل بطريقة أفضل وأوضح حتى يفهم أي أحد قد ينضم للمحادثة لاحقًا الموضوع بالضبط. إذا كنت تعتقد أنّ مزايا العمل عن بعد تفوق عيوبه، وكنت لا تمانع من أن يكون لديك موظفون عن بعد، فإنّ السؤال الذي قد يتبادر إلى ذهنك هو: كيف أبني ثقافة مشتركة مع الموظفين عن بعد؟ نصائح لبناء ثقافة مشتركة مع الموظفين عن بعد إنّ أساس بناء ثقافة مشتركة مع الموظفين عن بعد هو التواصل المستمر. لذا، ينبغي عليك أن تبذل جهدًا إضافيًا للتأكد من أنّ جميع الأفراد يشعرون أنّهم جزءٌ لا يتجزأ من فريق العمل، ومن المهم أيضًا أن تدرك أنَّ الامتيازات الرائعة ومكاتب العمل الفاخرة وملابس العمل ليست هي ما يؤدي إلى بناء ثقافة عظيمة للشركة؛ بل إنّ الأهداف السامية والقيم الأساسية المؤثّرة ووجود الكثير من الثقة والاحترام هي الأمور التي تؤدي إلى وجود ثقافة جيّدة للشركة. فيما يلي بعض النصائح التي تساعد في تفاعل الموظفين عن بعد واندماجهم: 1. الثقة هي المفتاح الأساسي إنّ المفتاح الأساسي للنجاح في توطيد العلاقات مع الموظفين عن بعد هو الثقة بهم. لكن، إذا وجدت موظفيك «غير متصلين بشبكة الإنترنت» لمدة ساعةٍ أو ساعتين وبدأت تفكّر فيما إذا كانوا يعملون بالفعل أم أنهّم يلعبون ألعاب الفيديو، فهذا يعني أنّك لا تثق بهم ثقةً تامة. إذا كنت قد وثقت بهؤلاء الأشخاص لدرجة جعلتك تقوم بتوظيفهم وبدفع المال لهم، فعليك أيضًا أن تثق بهم بدرجة كافية في إنجاز الأعمال المطلوبة منهم. إنّ الثقة طريق ذو اتجاهين؛ فإذا أظهرت للموظفين أنّك تثق بهم، سيثقون هم بك وسيكافئونك من خلال اجتهادهم في العمل. 2. الاستثمار في الأدوات والبرامج المناسبة يجب التأكد من أنّ جميع أعضاء فريق العمل يشاركون في اتخاذ القرارات وقادرون على التعاون والعمل بكفاءة، ومن الرائع أيضًا أن يستمتعوا ببعض المرح. من الأدوات والبرامج التي تساعد في ذلك: Slack Skype Google Drive Trello IDoneThis Join.me 3. الاجتماع وجهًا لوجه يجتمع أفراد عدد من الشركات كشركة Buffer وجهًا لوجه بضعة مرّات في السنة «اجتماعات لإعادة شحن الطاقة» لضمان تواصل جميع الموظفين عن بعد مع بعضهم بعضًا، وهذا الأمر يجعل عملية إقامة العلاقات بين أعضاء الفريق ممكنة حتى لو لم يتواجدوا دائمًا في مكانٍ واحد. قد يبدو هذا الامر مكلِّفًا، ولكنّ من المؤكد أنّ توفير هذه الفرصة للجميع يستحق تلك التكلفة. 4. إجراء عدد أكبر من الاجتماعات يجب أن تتأكد من أنّ الجميع يشارك في اتخاذ القرارات، لذلك ينبغي عليك إجراء عددًا أكبر من الاجتماعات مع فريق العمل، ومن الأفضل أن تتم هذه الاجتماعات عبر الفيديو. ينبغي عليك أيضًا أن تعقد على نحوٍ دوريّ اجتماعاتٍ فردية مع كل موظف على حدة، وأن تسألهم عن حياتهم الشخصيّة. إحدى الأفكار الجيّدة هي أن تجتمع فرديًا مع كل موظف مرةً في الأسبوع، ثمّ تعقد اجتماعًا للفريق كلّه مرةً كل أسبوعين. 5. تعزيز مشاركة فريق العمل يجب أن تكون واضحًا وصريحًا مع أعضاء فريق العمل الخاص بك، وأن تحرص على مشاركتهم في اتخاذ أكبر عددٍ من القرارات. إنّ العمل عن بعد قد يجعل الأفراد يشعرون بالوحدة، لذلك من المهم أن تبذل قصارى جهدك لكي تُشعِر الموظفين عن بعد أنّهم جزءٌ لا يتجزأ من فريق العمل. حان دورك الآن لتترك تعليقًا تخبرنا من خلاله عمّا إذا كان لديك أية نصائح أخرى تساعد في بناء ثقافة مشتركة مع الموظفين عن بعد. ترجمة -وبتصرف- للمقال Building Culture On Remote Teams لصاحبته Alison Robins
  2. نتحدّث كثيرًا في Techstars حول الإنتاجية وإدارة البريد الإلكتروني وإنجاز المهام، والأمور الأساسية في تطوير الشركة، وثقافة الحصول على التمويل. فيما يلي مجموعة من النصائح العامة التي نقدّمها إلى مؤسّسي الشركات التي تنضمّ إلى Techstars، وقد تكون مفيدة لك ولشركتك الناشئة، خصوصًا إن كانت هذه هي المرة الأولى التي تخوض فيها هذه التجربة. الإنتاجية حدّد أولوياتك، وأنجز ما هو ضروري فقط. تجنب العمل الفوضوي، وتعلم رفض الأمور التي لن تجني منها أي فائدة. إذا أصبح كل شيء مهمًّا فهذا يعني أنّ كل هذه الأشياء ليست مهمّة. عوّد نفسك على تقسيم أولوياتك في العمل إلى عدّة مستويات. المستوى الأول أولى، ثم الثاني، ثم الثالث وهكذا... ومن الناحية العملية أنجز المهام التي تكون في المستوى الأولى فقط. حدّد أولوياتك والتزم بها دون أدنى تنازل. تجنب قبول الأهداف المبهمة. اجعل أهدافك واضحة ثم ابدأ التنفيذ. لا تقم بإضافة المهام الجديدة إلى بداية قائمة المهام، فمكانها في نهاية القائمة. لا تترك أبدًا ما أنت عاكف على إنجازه. يمكنك الاطلاع مقالة قوائم الأعمال والأفكار لمزيد من المعلومات. اصنع جدول أعمالك وتحكم به من خلال التقويم. استخدم الكتل الزمنية Time Blocks لتنظيم وقتك في كل ما يخصّ المكالمات الهاتفية، واللقاءات، والعمل الذي يحتاج إلى تركيز، وغير ذلك من الأمور، بل وحتى متابعة البريد الإلكتروني وقضاء الوقت مع العائلة وممارسة التمارين الرياضية. إن لم تكن المهمة التي ترغب في إنجازها مدرجة في التقويم فلا تقم بإنجازها على الإطلاق. أجر التعديلات اللازمة على الوقت الذي يستغرقه كل نشاط تنجزه خلال اليوم، وابحث عن الطريقة الأنسب بالنسبة إليك. راجع التالي: 7 نصائح لإدارة جدول أعمالك، قوائم الأعمال والأفكار. راجع جدول أعمالك قبل أن يبدأ الأسبوع لتكون متهيّئًا للعمل. تجنب استخدام قنوات التواصل المتزامن، واستبدلها بالقنوات غير المتزامنة. لا تستخدم برامج الدردشة أو برامج التراسل النصي، فهذه البرامج تدمّر الإنتاجية وتقطع سير العمل. احترم وقتك ووقت فريق العمل. تجنّب عقد الاجتماعات مع أعضاء الفريق دون التخطيط لذلك. لا بأس في دعوة فريق العمل إلى الاجتماع لتبادل الأفكار ومناقشتها، ولكن أخبرهم بأنّ الاجتماع يقتصر على هذا الهدف، واجعل هذه الاجتماعات قصيرة. حدّد المدّة المتوقعة لجميع الاجتماعات بشكل مسبق، عادة ما تكون ساعة كاملة الحدّ الأقصى لمثل هذه الاجتماعات، أما 30 دقيقة فهي فترة مناسبة جدًّا، إلا إن كان الاجتماع يتضمن جلسة تبادل أفكار مطوّلة فيمكن حينها زيادة مدة الاجتماع مع الحرص على تقسيمها إلى عدة أقسام. احترم إنتاجية بقية أعضاء الفريق، ولا تقم بإضافة مهام جديدة إلى قائمة مهامهم الأصلية. يحدث هذا عادة مع المدراء التنفيذيين، حيث يطلبون من أحد الأشخاص تأدية مهمّة مستعجلة من أجلهم. قد تؤدي مجموعة من المهام السريعة إلى التشويش على أعضاء الفريق، خصوصًا المهندسين منهم والمبرمجين. اعتن بنفسك وبصحتك، وخذ قسطًا من الراحة خلال اليوم لتستعيد نشاطك. ممارسة التمارين الرياضية بشكل منتظم أمر ضروري للغاية. خصّص كتلًا زمنية للتمارين الرياضية في تقويمك، وإلا فإنّك لن تمارسها على الإطلاق. احرص على أن تنام لمدة كافية كل يوم (ولكن أقل من المعتاد) وتجنب حالات الإرهاق الشديد. البريد الإلكتروني إنه وحش مفترس، إن لم تسيطر عليه فسيسيطر عليك. لا تتفقد صندوق بريدك الإلكتروني وتفتح الرسائل الواردة إليه بشكل متواصل، فهذا سيضعف من إنتاجيتك. خصّص وقتًا ثابتًا للتعامل مع البريد الإلكتروني بجميع أنواعه. تعلّم استخدام خانة (نسخة إلى CC) ولا ترسل نسخًا من رسائلك الإلكترونية إلى الآخرين إن لم يكن ذلك ضروريًا، واطلب من الآخرين كذلك أن لا يرسلوا إليك نسخًا من رسائلهم الإلكترونية إن لم تكن مهمّة بالنسبة إليك. ينطبق هذا بشكل خاص على المدراء التنفيذيين، إذ أنّهم يرغبون في معرفة كل شيء يدور في الشركة، وهذا قد يكون مربكًا. تعلّم كيفية استخدام النسخ المخفية من الرسائل (BCC). انقل إلى هذا الحقل مثلًا الأشخاص الذين لا يحتاجون إلى مُتابعة سير المُحادثة الحالية (كشخص قام بتقديمك إلى شخص آخر). علّم بقية أعضاء الفريق كيف يستخدمون هذا الحقل عند إرسال الرسائل إليك وحسبما تقتضيه الحاجة، وينطبق الكلام نفسه عند الرد على جميع الرسائل Reply All. كذلك استخدم توقيع بريدك الإلكتروني Email signature بحكمة، واحرص على أن يتضمن معلومات مفيدة. تجنب استخدام الشعارات أو الصور لأنّها تثقل الرسالة وقد يتم إخفاءها عند عرض الرسالة في صندوق بريد المستلم. تعلم كتابة الرسائل القصيرة، والتي تتكوّن من جملتين/فقرتين أو ثلاث على الأكثر، وتأكد قبل إرسالها من عرضها وقراءتها على الهاتف النقّال؛ لأنّك لو اضطررت إلى تمرير الشاشة كثيرًا فهذا يعني أن الرسالة طويلة جدًّا. استخدم أقل عدد ممكن من الكلمات، وراجع الرسالة عدّة مرات قبل إرسالها. اكتب بأسلوبك الخاص، ولا تلجأ إلى قوالب النصوص الجاهزة. إرسال رسائل إلكترونية قليلة أفضل بكثير من إرسال رسائل كثيرة تحتوي على قوالب نصوص جاهزة. التعرف على الآخرين تجنب الرسائل الإلكترونية الباردة قدر الإمكان، واستخدم شبكة علاقاتك للتعرف على المزيد من الأشخاص. يمكنك الاستفادة من بعض الأدوات مثل goconspire.com و LinkedIn. تواصل مع الآخرين بشكل مستمر، واحرص دائمًا على توسيع شبكة علاقاتك في LinkedIn. تعلّم كيفية قراءة حسابات مستخدمي موقع LinkedIn. حاول الاطلاع على مجالات عمل مختلفة مثل التوظيف، أو تطوير المشاريع التجارية، أو رؤوس أموال مخاطرين، أو أي مجال آخر. من المفيد جدًّا أن تتكوّن لديك فكرة حول هؤلاء الأشخاص وذلك بالاطلاع على هذه الحسابات بشكل جيّد. ابحث دائمًا عن الشخص (أو الأشخاص) المناسب، ولا تطلب إجراء مقابلة مفتوحة على الإطلاق. لا تطلب إجراء مقابلات مفتوحة غير واضحة الأهداف مع المستثمرين الجريئين والمستثمرين الملائكة، حاول أن تدرس وتستوعب بشكل جيّد ما يرغبون في الاستثمار فيه، وألق نظرة إلى أعمالهم ونشاطاتهم السابقة. إن كنت ستطلب إجراء مقابلة مع مسؤول علاقات خارجية Biz Dev في إحدى الشّركات، فتأكد من أن يكون ذلك الشخص مناسبًا لهذه المهمّة. ابحث عن عدد من الأشخاص الذين تعتقد أنّهم مناسبون لهذه المهمّة ثم ألق نظرة على حساباتهم في LinkedIn. لنائب رئيس الشركة تأثير كبير فيها، فقد يكون قادرًا على اتخاذ القرارات، أو سيوجّهك إلى الشخص المناسب؛ لذا إن كنت راغبًا في عقد صفقات أو شراكات مع شركات أخرى، حاول التعرّف على هذه الشريحة. عليك إتقان فن كتابة رسائل إلكترونية تعريفية قابلة لإعادة التوجيه. إن كنت ترغب في تقديم نفسك إلى جهة معينة عن طريق أحد الأشخاص، أرسل إليه رسالة إلكترونية مختصرة وواضحة تخاطب فيها تلك الجهة، ليتسنى للوسيط إضافة بعض الكلمات أو العبارات ليعيد توجيهها بعد ذلك، وهكذا يصبح تقديمك إلى تلك الجهة أكثر سهولة. مع أن تقديم نفسك عن طريق الرسائل الإلكترونية هو الأفضل، إلا أنّ استخدام LinkedIn قد يكون مفيدًا أيضًا، ولكن تبقى الرسائل الإلكترونية الوسيلة الأفضل في هذا المجال. جدولة اللقاءات قم بجدولة لقاءاتك بشكل فعّال وذلك من خلال إنشاء عدد من الخانات المعرفة مسبقًا في تقويمك لكل نوع من أنواع اللقاءات. على سبيل المثال: الإثنين، الأربعاء، الجمعة 9ص - 10ص مكالمات هاتفية مدتها 15 دقيقة لتقديم نفسي إلى الآخرين. الإثنين، الأربعاء، الجمعة، 2م-4م لقاء لمتابعة المستشارين.. الخ. حدّد دائمًا 3 إلى 4 مواعيد مخصّصة للقاء معين وذلك بالاعتماد على طبيعة ذلك اللقاء، ثم ضعها في خانات الوقت الشاغرة في التقويم. إن كان الشخص الذي تحاول التواصل معه شديد الانشغال، فتحلَّ بشيء من المرونة، وحاول إعادة ترتيب الكتل الزمنية الخاصّة بك لتتلائم مع وقته. حاول التقليل من عدد الرسائل الإلكترونية الخاصّة باختيار موعد اللقاء. إن وافق الطرف المقابل على مقابلتك، اقترح مباشرة عددًا من المواعيد، ولا تطلب منه اقتراح تلك المواعيد. نصائح عامة حول مدة اللقاء في حالة المكالمات الهاتفية التعريفية: حاول أن لا تزيد المدة عن 15 دقيقة، وسيقدّر الناس دعوتهم إلى مكالمة تمتدّ لـ 15 دقيقة والالتزام بهذه المدة. في حالة اللقاءات التعريفية: فلا تتجاوز الـ 30 دقيقة. قد تكون ساعة كاملة طويلة جدًّا خصوصًا إن كنت أنت الضيف، إلا إذا طلب المضيف منك البقاء لفترة أطول. إن لم تكن متأكدًا من أن هذه الفترة كافية أم لا، يمكنك سؤال الطرف المقابل عن ذلك، وينطبق هذا الأمر كذلك عند إجراء مقابلات العمل أو مقابلة المستثمرين الملائكة أو الجريئين. ولكن هناك بعض الحالات الاستثنائية، فقد يُضطّر أحدهم للسفر لمقابلتك فيتوقّع أن تمتدّ المقابلة لفترة زمنية أطول. أثناء اللقاء لا تصل متأخّرًا، فهذا تصرف غير لائق، بل حاول الحضور مبكّرًا. لا تأخذ وقتًا أكثر من الوقت الذي تحتاجه المقابلة. احترم أوقات الآخرين ولا تضيعها في أمور غير مهمّة. تجنب الأحاديث غير المرتبطة بالموضوع. لا بأس بالقليل منها ولكن لا تكثر. يجب أن تعرف الهدف من هذا اللقاء، وعليك أن تدخل إلى صلب الموضوع مباشرة. لا تترد في طرح الأسئلة، ولكن لا تبالغ في ذلك. حاول الانسجام مع الطرف المقابل وتعرّف إلى اهتماماته. اقرأ الطرف المقابل جيدًا، وتعرّف جيدًا إلى نشاطاته وأعماله، أو ما يرغب في الاستثمار فيه، أو ... الخ. لا تقدّم عروضك فقط، بل استمع إلى الطرف المقابل أيضًا. تُعقد معظم الصفقات التجارية بعد الاستماع المطوّل للطرف المقابل وليس بعد الحديث المطوّل. استمع إلى ما يقوله الآخرون، واطرح الأسئلة. إن واجهك الطرف المقابل بالرفض، فلا بأس في ذلك، تفهّم الأمر وتجاوزه أو حاول مرة أخرى في وقت لاحق. اعرض على الطرف المقابل الأمور التي يحتاجها، ولا تكتف بالارتقاء بالصفقة فقط. بيّن دائمًا الفوائد التي سيجنيها العميل من المنتج الذي تقدّمه. احرص دائمًا على أن يكون لديك ملخّص واضح عن اللقاء، واقترح الخطوات التالية. يمكنك إرسال رسالة إلكترونية أو إجراء مكالمة هاتفية أو إجراء لقاء آخر، أو يمكن الاتفاق على إرسال المزيد من المواد، أو التعارف بشكل أكبر... الخ. مهما كانت الخطوة التالية عليك تلخيص اللقاء عند الختام. أتمنى أن تكون هذه النصائح مفيدة لك، ولا تترد بمشاركتنا أي نصيحة ترى أنّها كانت مفيدة بالنسبة إليك. ترجمة -وبتصرّف- للمقال Quick productivity and business tips for startups لصاحبه Alex Iskold.
  3. سنقوم في هذا الدرس بتغطية الأوامر الأساسية التي لا يُمكنك الاستغناء عنها إن أردت أن تستخدم 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.