00:00:00أهلاً بالجميع، معكم سكوت، المدير التنفيذي لشركة GitButler.
00:00:02سأستعرض معكم اليوم بعض الميزات الرائعة في GitButler وسأعطيكم
00:00:05نظرة عامة وشاملة عما يمكن لعميل Git هذا القيام به.
00:00:07لدي هنا مشروع تجريبي؛ نسخة مصغرة من تويتر أو X، أسميتها Y.
00:00:12ما سأفعله هو إضافة بعض التعديلات التي أجريتها مسبقاً، وسنمر
00:00:16بخطوات إنشاء الالتزامات (commits)، الفروع (branches)، الفروع المتوازية،
00:00:20وكيفية إنشاء الفروع المتراكمة (stacked branches). إذا قمت بتعديل بعض الملفات، فسترى شيئاً
00:00:25مشابهاً لمخرجات Git status التي تخبرك بالملفات المعدلة حالياً في دليل عملك.
00:00:30ماذا تريد أن تفعل بها؟ كيف تريد توثيقها؟ هنا يمكننا فحصها.
00:00:34يمكنني النظر في ملف CSS الخاص بالتطبيق، والشريط الجانبي، والفهرس. هناك بعض التغييرات الطفيفة التي أجريتها.
00:00:39ما أريد فعله هو إنشاء فرع جديد وتوثيق هذه التغييرات في ذلك
00:00:45الفرع. هناك عدة طرق مختلفة للقيام بذلك.
00:00:49يمكنني ببساطة الضغط على “commit to new branch” أو إنشاء فرع جديد بشكل صريح هنا، وسأجعله فرعاً مستقلاً
00:00:54بدلاً من فرع تابع. سنصل إلى موضوع التراكم (stacking) بعد قليل.
00:00:57تختار اسماً، تنشئ الفرع، والآن هناك بضعة أشياء يمكنك القيام بها.
00:01:03يمكنك ببساطة توثيق بعض الأشياء، كأن أوثق ملف application.css
00:01:08إما بسحبه إلى المسار المخصص وإنشاء التزام، أو البدء بالتوثيق من هنا مباشرة.
00:01:15يمكنك كتابة رسالة توثيق قصيرة في هذا المربع الصغير، أو توسيعه وكتابة
00:01:19رسالة توثيق طويلة ومنظمة. دعونا نبقي الأمر بسيطاً الآن. الأمر الآخر الذي يمكنني فعله هو
00:01:27تحديد ما سيتم تضمينه في هذا الالتزام. لدي ثلاثة ملفات هنا على الجانب.
00:01:34لا يمكنني فقط استبعاد ملف معين، بل يمكنني الدخول للملف واختيار أسطر محددة فقط.
00:01:39لكن لنقم الآن بتوثيق كل التغييرات، أو في الواقع، لنقم بعمل
00:01:44التزامين منفصلين. لا أريد تضمين تغييرات الشريط الجانبي في هذا الالتزام، لذا سأسميه “إصلاحات الواجهة الأمامية”،
00:01:48ثم التزام آخر باسم “إصلاحات الشريط الجانبي”. الآن لدي التزامان في هذا الفرع الجديد.
00:01:55أشعر بالكسل قليلاً، لذا سأستخدم Claude Code للقيام بهذا العمل نيابة عني.
00:01:59سأغير السمة (theme) من الأزرق إلى الأحمر، ثم سنرى كيف نضيف فرعاً منفصلاً جديداً
00:02:04يحتوي على ذلك التغيير بعيداً عن إصلاحات الواجهة. يبدو أن العمل قد انتهى.
00:02:09هذا ما كان يبدو عليه الموقع سابقاً؛ يشبه تويتر قليلاً. إذا طبقت تلك التغييرات،
00:02:14سيصبح لدي سمة حمراء جميلة لكل شيء، واكتملت تغييرات الواجهة الأمامية هنا.
00:02:18وكما تلاحظون، هذه فروع مستقلة. فإذا اخترت إلغاء تطبيق (unapply) حزمة إصلاحات الواجهة،
00:02:25سيبقى اللون أحمراً لكن التغييرات الأخرى ستختفي. هذا ما فعلته هنا.
00:02:34ويمكنني أيضاً إلغاء تطبيق السمة الحمراء ليعود اللون كما كان، ثم أعيده مجدداً.
00:02:43لدينا الآن فرعان مختلفان. والميزة الرائعة هي أنني إذا رفعت (push) هذا إلى GitHub مثلاً،
00:02:48ستبقى هذه التغييرات منفصلة عن بعضها، رغم تطبيقها معاً في نفس الوقت.
00:02:52الأمر تماماً مثل فروع Git، إلا أنه يمكنك العمل على أكثر من فرع بشكل متزامن.
00:02:57إذا واصلت العمل على شيء في الشريط الجانبي، فسأراه هنا.
00:03:04ويمكنني القيام بعدة أمور، كأن أسحب الملف إلى هنا لتعديل (amend) هذا الالتزام إذا أردت.
00:03:10أو توثيقه كالتزام جديد في ذلك الفرع. الآن لدينا هذان الفرعان يعملان بالتوازي.
00:03:14دعونا نلقي نظرة على طريقة أخرى للقيام بذلك. لنفترض مثلاً
00:03:18أن السمة الحمراء تعتمد على التغييرات التي أجريناها في الواجهة الأمامية.
00:03:24لذا أريد دمج (merge) تغييرات الواجهة أولاً قبل النظر في السمة الحمراء، أو دمجها جميعاً.
00:03:29لذا لنلغِ هذا الالتزام (uncommit)، وسنجعله فرعاً متراكماً (stacked branch) بدلاً من ذلك.
00:03:37سنلغي الالتزام ونلغي تطبيق الحزمة. والآن سنضيف فرعاً تابعاً جديداً هنا.
00:03:42تضغط على إنشاء فرع جديد وتختار “فرع تابع”. الطريقة الأخرى هي
00:03:47أن تقول “إنشاء فرع تابع هنا” وتضيف إصلاحات الواجهة المتراكمة، وسأسميه
00:03:51sc_red_theme. والآن كما ترون، هذه الفروع متراكمة فوق بعضها.
00:03:58ويمكنني أخذ هذا التغيير وتوثيقه في هذا الفرع. فإذا كان لديك فروع متراكمة،
00:04:06يسهل جداً رفعها إلى GitHub. إذا قمت بإعداد التكامل مع GitHub،
00:04:11يمكنك أيضاً إنشاء “طلب سحب” (Pull Request). فإذا أنشأت طلب سحب للسمة الحمراء
00:04:16وهو فرع متراكم، فسيقوم النظام بإدراج تذييل في وصف الطلب يوضح
00:04:20أن هذا الفرع يعتمد في الواقع على فرع آخر يستهدفه. وسيتعين عليك
00:04:25إما دمجها معاً أو دمج إصلاحات الواجهة قبل السمة الحمراء.
00:04:30إنها طريقة رائعة للتعامل مع الفروع المتراكمة. إذا نظرت لطلب السحب الآن،
00:04:34ستجده يربط كلاهما في حزمة واحدة؛ هذا هو الجزء الثاني من الحزمة، وهذا هو الجزء الأول،
00:04:39وهما يعتمدان على بعضهما. الميزة الأخرى الرائعة هي ما يسمى
00:04:43بتخصيص التغييرات للفروع (assigning to branches). في هذه الحالة، لدي مساران وثلاثة فروع؛
00:04:48اثنان منها متراكمان وواحد مستقل. عندما أبدأ في إجراء التغييرات،
00:04:54يمكنني تخصيص أجزاء التعليمات البرمجية (hunks) لفرع معين ومواصلة العمل عليها.
00:05:00الأمر يشبه أن لكل مسار منطقة تحضير (staging area) مستقلة خاصة به.
00:05:05يشبه الأمر أمر git add في Git، لكن مع إمكانية وجود مناطق تحضير متعددة ومستقلة.
00:05:09لنجرب ذلك. سأضيف ميزة جديدة لإضافة قسم صغير لصفحة المسؤول (admin).
00:05:14سأضعه في فرعه الخاص، في نفس دليل العمل، ولكنه فرع
00:05:19مستقل غير متراكم، ويمكنني فتح طلب سحب لتلك التغييرات فقط.
00:05:24حسناً، هذه هي لوحة تحكم المسؤول قبل التعديل. لقد أجريت بعض التغييرات وأضفت
00:05:31قسم المشتركين الجدد. لدي هذان التغييران هنا، وما أريد فعله هو تخصيصهما
00:05:37لهذا المسار. وإذا أجريت المزيد من التغييرات، فسيتم وضعها في “غير المخصص” إذا لم يستطع النظام تحديد وجهتها.
00:05:43أما إذا كانت ضمن نفس الأجزاء البرمجية، فسيحتفظ بها تلقائياً في المسار المخصص.
00:05:47دعونا نجري بعض التغييرات على وحدة تحكم المسؤول (admin controller) هنا. مجرد تعليق بسيط،
00:05:55ولكن لنرَ ما سيحدث. نلاحظ أنه بما أن وحدة تحكم المسؤول كانت مخصصة بالفعل لهذا المسار،
00:06:00فلا داعي للاستمرار في تحضيرها يدوياً. النظام يقول: “هذا التغيير جزء من ذلك العمل أيضاً”
00:06:05ويضيفه هناك. لنقم بإنشاء التزام جديد لهذا. سأبدأ عملية التوثيق مجدداً.
00:06:10يمكنني توسيع هذا وكتابة رسالة توثيق ممتازة، كما يمكنني استخدام الذكاء الاصطناعي
00:06:15لتوليد رسائل التوثيق إذا كنت تريد نقطة بداية ثم تعدلها بنفسك.
00:06:19سيقوم الذكاء الاصطناعي بتحليل التغييرات التي أجريتها ليعطيك مسودة أولية. حسناً،
00:06:23أصبح لدينا الآن التزام في صفحة المشتركين الجدد. ولدينا هذا الفرع المتراكم
00:06:27هنا على الجانب، ومرة أخرى يمكنني الرفع وإنشاء طلب سحب لهذا بشكل مستقل.
00:06:31وإذا فعلت ذلك وتفقدت طلب السحب، فسنرى أنه على الرغم من وجود
00:06:37كل هذه التغييرات في دليل عملي في نفس الوقت، إلا أنه تم فصلها في
00:06:42فروع مختلفة. لذا يمكنني الدخول ورؤية ما يخص صفحة المسؤول فقط.
00:06:48لقد عدّل فقط صفحات المسؤول وأبقاها في فرعها والتزامها الخاص، وهي ليست
00:06:55مرتبطة بالأعمال الأخرى الموجودة في دليل عملي؛ فكل منها في فرع منفصل.
00:06:58هذه هي ميزة العمل مع الفروع المتوازية والمتراكمة في GitButler.
00:07:02هناك الكثير من الأشياء التي يمكننا القيام بها والتي قد تكون صعبة في
00:07:06Git التقليدي، وسأريكم بعضاً منها. أولاً، يمكننا نقل الالتزامات من فرع لآخر.
00:07:11فإذا أردت أخذ التزام المشتركين الجدد ونقله إلى
00:07:15التزام السمة الحمراء، يمكنني ببساطة سحبه وإفلاته، ثم التخلص من الحزمة القديمة.
00:07:20والآن أصبح الالتزام هنا. وإذا أردت دمج الالتزامات (squash) معاً، يمكنني سحب الالتزام
00:07:26ليس فقط للذي يليه مباشرة، بل لأي التزام آخر في الحزمة.
00:07:30يمكنني أخذ تغيير المسؤول وسحبه للأسفل وضمه لإصلاحات الشريط الجانبي، أو حتى نقله فقط؛
00:07:36يمكنني تحريكه لأسفل الحزمة أو دمجه في التزام آخر. وكما ترون الآن،
00:07:41أصبحت تعديلات المسؤول ضمن إصلاحات الشريط الجانبي. يمكننا أيضاً القيام بالعكس، أي تقسيم الالتزام،
00:07:47وذلك بإضافة التزام فارغ ثم نقل التغييرات إليه.
00:07:52عند القيام بذلك، يمكنني إضافة التزام فارغ في أي مكان في هذه الحزمة، في هذه الحالة بالأسفل.
00:07:58يمكنني كتابة رسالة التوثيق الآن أو نقل الملفات أولاً. لنلقِ نظرة على كل هذه الملفات.
00:08:02لدينا وحدة تحكم المسؤول والشريط الجانبي. لنأخذ فهرس المسؤول (admin index) ونسحبه
00:08:08إلى الالتزام الأوسط. الآن هذا الالتزام يحتوي فقط على فهرس المسؤول، بينما لا تزال إصلاحات
00:08:13الشريط الجانبي تحتوي على الملفات الأخرى؛ وحدة تحكم المسؤول والشريط الجانبي.
00:08:20كما يمكنني نقل أجزاء برمجية معينة فقط. فالآن هذا الالتزام لديه جزء من إصلاحات
00:08:30الشريط الجانبي، وهذا لديه الجزء الآخر. وبعد ذلك يمكنني تغيير رسالة التوثيق إذا أردت.
00:08:34وهذا يقودنا لنقطة أخرى، وهي أن تعديل رسائل التوثيق سهل للغاية.
00:08:41فبالإضافة لتغيير ترتيبها أو دمجها أو تقسيمها، يمكنني العودة
00:08:46وتغيير الاسم مثلاً إلى “الجزء الثاني”، وسيقوم النظام بإعادة بناء (rebase) كل الالتزامات فوقها.
00:08:53الأمر الآخر المثير للاهتمام هو تعديل الالتزامات في مكانها، وهناك بضعة طرق للقيام بذلك بسرعة.
00:08:57لنفترض أن أحدهم أعطاني ملاحظة وقال: بدلاً من جعل الهامش العلوي (margin-top) صفراً،
00:09:01اجعله 10 بكسل مثلاً. فكيف نعدل التزاماً ليس فقط قديماً بأربعة التزامات،
00:09:06بل موجود أيضاً في حزمة أخرى؟ مع GitButler، هذا الأمر في غاية السهولة.
00:09:13لندخل ونجري هذا التغيير فعلياً.
00:09:16حسناً، هو هنا، لنغيره إلى 10 بكسل. تنسيق CSS المضمن هو الأفضل دائماً. هذا هو التغيير
00:09:23الذي أجريته هنا. إنه مقفل لأننا نعدل جزءاً تم تعديله بالفعل، لذا يجب أن يوضع
00:09:28في هذا الفرع تحديداً. لم نتمكن من وضعه في فرع موازٍ منفصل، وهكذا عرفنا ذلك.
00:09:32ولكن كيف نفعل ذلك؟ الطريقة الأسهل هي ببساطة أخذ هذا الملف
00:09:39وسحبه إلى هذا الالتزام. والآن إذا نظرنا لهذا الالتزام، سنجد الـ 10 بكسل هناك،
00:09:46لقد عدلناه وأعدنا بناء بقية الالتزامات فوقه. الطريقة الأخرى
00:09:51التي رأيناها هي توثيق التغيير في التزام مؤقت (temp commit)
00:09:55ثم دمجه في الالتزام المقصود. هذا يؤدي لنفس النتيجة تماماً.
00:10:02إذا دخلنا وتفقدنا مجدداً، سنجد الهامش أصبح 10 بكسل. والطريقة الأخيرة
00:10:07المثيرة للاهتمام هي ما يسمى “وضع التحرير” (edit mode). لنتظاهر بأننا لم نفعل شيئاً.
00:10:12لا يزال الهامش صفر بكسل ونريد تعديله. ما يمكننا فعله هو الذهاب للالتزام نفسه
00:10:20واختيار “تعديل الالتزام” (edit commit). وعند القيام بذلك، يحدث شيء مثير للاهتمام.
00:10:25يشبه الأمر قيام Git بعملية “detached head checkout” إذا سبق لك فعل ذلك.
00:10:30فهو يستخرج حالة الالتزام في تلك اللحظة؛ يمكنك تعديله كما تشاء، وعند الخروج
00:10:36من هذا الوضع، سيعيد بناء كل شيء فوقه مجدداً. لندخل ونجري التغيير مرة أخرى.
00:10:39سيرى النظام أن الملف قد عُدل، فنقوم بالحفظ والخروج. ومرة أخرى،
00:10:46يعيد بناء كل الالتزامات التالية، ويمكننا رؤية تغييرنا محفوظاً هناك. إذن يمكنك
00:10:52تعديل الالتزام مباشرة، أو إجراء التغيير وتعديل الالتزام (amend)، أو إجراء التغيير
00:10:57في التزام جديد ثم دمجه. هناك طرق عديدة للتلاعب بالتغييرات التي تجريها في GitButler.
00:11:01وآخر شيء سأعرضه لكم هو ميزة “سجل العمليات” (operations history).
00:11:05وهو أمر يصعب جداً القيام به في Git إذا كنت قد جربت استخدام “reflog”.
00:11:10أشعر أن الجميع يخشى ذلك، ولكن في GitButler كل ما تفعله
00:11:15يُحفظ في سجل العمليات، ويمكنك تصفح الجدول الزمني والعودة لأي نقطة في الماضي.
00:11:21هذا هو الزر المخصص، هنا نرى سجل عملياتنا وكل الأشياء المختلفة التي قمنا بها خلال الجلسة.
00:11:26ويمكنني العودة بالزمن إلى أي لحظة حرفياً.
00:11:30فإذا أردت العودة لما قبل البدء بتغيير الـ 10 بكسل،
00:11:37يمكنني العودة هنا ورؤية الحالة التي كنت عليها حينها، قبل القيام بكل ذلك.
00:11:42أو يمكنني حتى العودة لبداية الجلسة التي بدأناها.
00:11:47الشيء الوحيد الذي لا يتراجع عنه هو ما تم رفعه بالفعل إلى GitHub.
00:11:52هنا يمكنني رؤية الالتزامات التي رُفعت لـ GitHub؛ تظهر كالتزامات منبع (upstream)،
00:11:56لكنني أعود بالزمن لما قبل توثيق أي شيء على الإطلاق.
00:12:01ويمكنني حتى حذف هذا الفرع والبدء من الصفر، ولكن لا يهم ما تفعله،
00:12:05فحتى عملية التراجع يمكنني التراجع عنها! فإذا جئت هنا وألغيت لقطة التراجع (revert snapshot)،
00:12:11سنعود تماماً لما كنا عليه. يمكننا دائماً العودة بالزمن لأي نقطة.
00:12:16هذا مريح جداً، فلن تضطر أبداً للخوف من أي إجراء تقوم به.
00:12:22إذا واجهت حالة غريبة أو أردت فقط العودة لما كان عليه الوضع قبل 10 دقائق،
00:12:26يكفي فتح الجدول الزمني، والعودة للخلف، والضغط على تراجع (revert). حسناً، كانت هذه
00:12:32نظرة سريعة على GitButler: إعادة البناء، محرر الالتزامات، الفروع المتوازية والمتراكمة،
00:12:36كل ذلك بسهولة ودون الحاجة لأدوات أخرى. تفضلوا بتحميله، وأخبرونا برأيكم عبر Discord.
00:12:41استمتعوا بالبرنامج!