هل من الآمن أن أدع Claude يشغّل git commands على الـ repo لديّ؟

نعم، مع الانضباط الذي بُني عليه هذا الـ playbook: اجعله يشرح الحالة وما الذي سيفعله الأمر قبل أن يشغّل أي شيء، ولا تدعه أبدًا يشغّل أمرًا مدمّرًا (reset --hard، push --force، clean -fd) لا تفهمه. في Claude Desktop توافق على كل إجراء، والمجلد المفتوح هو حدّك. القراءة والشرح آمنان دائمًا؛ أما أي شيء يعيد كتابة التاريخ أو يحذفه فيمرّ على عيني إنسان أولًا.

هل أعمل rebase أم merge للّحاق بـ main؟

يعتمد على مَن يملك الفرع غيرك. فرع feature تملكه وحدك يقبل rebase على main من أجل تاريخ نظيف خطّي. وفرع سحبه آخرون يكون merge أأمن له، لأن الـ rebase يعيد كتابة commits يبنون عليها. عند الشكّ، اطلب من Claude أن يشرح المقايضة لحالتك المحدّدة ويمشي على الخطوات — لا تدعه يشغّل rebase على عمياء على فرع مشترك.

هل يستطيع Claude كتابة رسائل الـ commit لي؟

نعم، وهو بارع في ذلك — لكنك تملك الرسالة. اجعله يكتب مسوّدة عنوان وجسم يشرح لماذا لزِم التغيير، ثم اقرأها وعدّلها قبل الالتزام. الرسالة التي تلتقط لماذا هي ما يجعل git blame مفيدًا لاحقًا؛ أما «fix stuff» فلا تفيد أحدًا. التقِط اصطلاح الـ commit لفريقك في CLAUDE.md مرّة واحدة وتتبعه كل مسوّدة.

ماذا عن conflict في الـ merge لا أفهمه؟

ذلك تحديدًا حين تتوقّف وتجعل Claude يشرحه. اطلب منه أن يُرِيك جانبَي الـ conflict — ما الذي غيّره main وما الذي غيّره فرعك — وما الذي كان كلٌّ منهما يحاول إنجازه، بلغة واضحة لا بعلامات diff فقط. conflict لا تستطيع قراءته هو conflict لا ينبغي أن تحلّه بعد؛ فهمه أولًا هو ما يجنّبك إسقاط عمل أحدهم بصمت. الإنسان هو من يملك الـ merge.

فُكّ فوضى git والتزِم بـ commits نظيفة ومنطقية

متى تلجأ إلى هذا

رفعتَ نظرك عند الخامسة مساءً فإذا الـ working tree فوضى: إصلاح bug، وتعديل config، وfeature نصف مكتوب، كلها متشابكة في التغييرات نفسها غير المُلتزَمة، إضافةً إلى merge بدأته هذا الصباح ولم تُنهِه. الحركة الكسولة هي git add -A && git commit -m "stuff" — commit واحد يخلط ثلاثة شواغل، وgit blame سيلعنه زملاؤك مستقبلًا، وmerge حُلّ بالتخمين. الانضباط هو العكس تمامًا: اجعل Claude يشرح الحالة قبل أن يمسّ أي شيء، ثم التزِم بكل شاغل وحده برسالة تقول لماذا، كي يُقرأ التاريخ كقصّة لا كانهيار صخري.

جهّز هذا أولًا

الـ repo مفتوحًا في Claude Desktop — افتح مجلد المشروع كي يقرأ Claude الـ working tree الفعلي، ووافِق على كل قراءة في نافذة Ask permissions. المجلد المفتوح هو حدّك.
الحالة الراهنة ظاهرةً أمامك أنت أيضًا: git status والـ diff بين يديك، كي تتحقّق من سلامة قراءة Claude مقابل عينيك أنت. (مسار Power Track: git status / git diff في الـ Terminal.)
تصوّر تقريبي لأي الشواغل المنطقية متشابكة فعلًا — إصلاح الـ bug، وتغيير الـ config، والـ feature نصف المنجز. لا يلزم أن يكون مثاليًا؛ إظهار التقسيم هو الخطوة الأولى.

الـ workflow

اجعله يشرح الحالة — قبل أن يمسّ أي شيء

الحركة الأولى غير القابلة للتفاوض: الفهم قبل الفعل. اطلب من Claude أن يقرأ الـ working tree ويرويه لك بلغة واضحة — ما الذي في staging، وما غير المُجهّز، وما هو ذلك الـ merge نصف المنجز فعلًا — واطلب منه صراحةً ألّا يشغّل شيئًا بعد. أنت تتحقّق من قراءته مقابل قراءتك قبل أن يُشغَّل أمر واحد.

أنت تطلب

اقرأ الـ working tree في هذا الـ repo. بلغة واضحة، أخبرني ما الذي في staging، وما غير المُجهّز، وما هو الـ merge الجاري وأي الملفات ما زالت في conflict — وكم عدد الشواغل المتمايزة غير المترابطة التي تمثّلها هذه التغييرات فعلًا. لا تشغّل أي git commands ولا تُغيّر أي شيء بعد.

ما تحصل عليه خريطة بلغة واضحة للفوضى: «ثلاثة شواغل — إصلاح bug في الـ session داخل auth/، ورفع config في .env.example، وfeature نصف منجز في dashboard/ — إضافةً إلى merge غير منجز بين main وفرعك مع ملفين ما زالا في conflict». الآن تستطيع التصرّف من فهم، لا من add -A أعمى.

«لا تشغّل شيئًا بعد» هي التعليمة المحورية. لا تريد أبدًا أن يُشغَّل git command مدمّر قبل أن يقرأ إنسانٌ الخطة ويوافق عليها.
اجمع التغييرات في شواغل منفصلة

حوّل تلك القراءة الآن إلى خطة: أي الـ hunks ينتمي إلى أي شاغل. هذا هو الجزء الذي يجعل التاريخ قابلًا للقراءة — commit واحد لكل فكرة، لا commit واحد لكل فترة بعد ظهر.

أنت تطلب

اجمع التغييرات غير المُجهّزة في الشواغل المنطقية المنفصلة التي حدّدتها للتو. لكل شاغل، اذكر الملفات (والـ hunks المحدّدة، إن امتدّ ملف على شاغلين) التي تنتمي إليه، واقترح ملخّصًا من سطر واحد لما هو ذلك الشاغل. لا تُجهّز شيئًا بعد — أرِني التجميع فقط.

ما تحصل عليه تجميع نظيف — شاغلًا شاغلًا، الملفات (وأجزاء الملفات) تحت كلٍّ منها، مع سطر واحد لكل مجموعة. وحيث يحمل ملف واحد شاغلين، يُنبّه على التقسيم كي تجهّز بالـ hunk، لا بالملف كاملًا.

إن خلط ملف واحد شاغلين فعلًا، فهنا تلتقطه — تجهيز الملف كاملًا كان سيهرّب تعديل الـ config إلى commit إصلاح الـ bug.
جهّز كل شاغل والتزِم به، مراجعًا كل diff

امشِ على المجموعات واحدةً تلو الأخرى. لكل واحدة: جهّز ذلك الشاغل وحده، اقرأ الـ diff الذي يعرضه Claude، ثم التزِم برسالة تشرح لماذا، لا ماذا فقط. في Claude Desktop ترى كل تغيير على شكل diff مرئي تقبله أو ترفضه قبل أن يستقرّ — اقرأه، لا تختمه دون نظر.

أنت تطلب

لنلتزم بالشاغل الأول — إصلاح bug الـ session. جهّز تلك الملفات وحدها، أرِني الـ diff لأتأكّد أنه ذلك التغيير فقط، ثم اكتب مسوّدة رسالة commit: عنوان قصير وجسم يشرح *لماذا* لزِم التغيير، لا ماذا يفعل فقط. أرِني الرسالة قبل أن تلتزم، وسأوافق.

ما تحصل عليه شاغل واحد مُجهّز، diff معروض لتتأكّد منه، ورسالة commit يجيب جسمها عن لماذا («كانت الـ sessions تنتهي مبكرًا لأن الـ TTL يُقرأ بالـ ms ويُضبط بالـ s») — السياق الذي يحتاجه فعلًا قارئٌ مستقبلي، أو git blame. كرّر لكل شاغل متبقٍّ.

أنت توافق على كل commit. يكتب Claude المسوّدة ويجهّز؛ وأنت تقرأ الـ diff وتملك الرسالة — الـ commits الصغيرة المنطقية التي تشرح السبب هي ما يُبقي التاريخ قابلًا للمراجعة.
حُلّ الـ merge عن قصد — افهم كل conflict

عُد إلى الـ merge نصف المنجز. الفخّ هو أن تدعه يحلّ تلقائيًا conflicts لم تقرأها. اجعل Claude يشرح كلا الجانبين في كل conflict وما الذي كان كل تغيير يحاول فعله، ثم احسم بنيّة — لا تقبل «theirs» أو «ours» على عمياء أبدًا.

أنت تطلب

الآن الـ merge الجاري. لكل ملف في conflict، أرِني الجانبين — ما الذي غيّره `main` وما الذي غيّره فرعي — واشرح ما الذي كان كلٌّ منهما يحاول إنجازه. أوصِ بحلٍّ لكلٍّ منها وأخبرني بأيّها أنت واثق وأيّها يحتاج قراري. لا تُنهِ الـ merge حتى أوافق على كل conflict.

ما تحصل عليه شرحٌ conflict تلو الآخر: الجانبان مشروحان بالنيّة، لا بعلامات الـ diff فقط، مع حلٍّ موصى به و«هذا قرارك» صادق على الغامضة منها — كي تُنجِز الـ merge بفهم، لا بقبول ما عرضه الأداة أولًا.

conflict لا تستطيع قراءته هو conflict لا تحلّه بعد. اجعله يشرح الجانبين حتى تفهم الخيار فهمًا حقيقيًا — الإنسان هو من يملك الـ merge.
اكتب وصف الـ PR — بلغة المراجِع

أغلِق الحلقة بوصفٍ يستطيع مراجِعك أن يتصرّف بناءً عليه فعلًا: ما الذي تغيّر، ولماذا، وكيف اختبرته. في فريق ثنائي اللغة، اكتبه باللغة التي يقرؤها المراجِع — الكود يبقى إنجليزيًا، لكن وصف الـ PR موجّه لإنسان.

أنت تطلب

اكتب مسوّدة وصف PR لهذا الفرع: *ماذا* و*لماذا* قصيران في الأعلى، وقائمة نقطية بالشواغل المنفصلة (سطر واحد لكلٍّ، مطابقًا للـ commits)، وقسم *كيف اختبرته*. أبقِه محكمًا وسهل التصفّح. [لفريق ثنائي اللغة: اكتبه بالعربية كي يقرأه مراجِعي بلغته — أبقِ الكود وأسماء الملفات والأوامر بالإنجليزية.]

ما تحصل عليه وصف PR قابل للمراجعة — ماذا/لماذا في الأعلى، والشواغل كقائمة نقطية نظيفة تعكس الـ commits لديك، وقسم اختبرته — جاهز للّصق، باللغة التي يقرؤها مراجِعك فعلًا.

وصف الـ PR هو قرين الـ commits النظيفة: هذا هو لماذا للتغيير كله، حيث جسم كل commit هو لماذا لجزئه. يقترن بـ playbook الـ ship-a-feature وplaybook الـ code-review — النصف الآخر من الحلقة.

اجعله ملكك

إنقاذ فرع متخلّف عن main: اطلب من Claude أن يشرح rebase مقابل merge لحالتك — فرع feature تملكه وحدك يقبل rebase نظيفًا عادةً من أجل تاريخ خطّي؛ وفرع مشترك سحبه آخرون يكون merge أأمن له. اجعله يمشي على الخطوات ويشرح كلًّا منها، لا تشغّل الـ rebase على عمياء أبدًا.
تنظيف التاريخ التفاعلي (مسار `Power Track`، بحذر): قبل المراجعة، قد ترغب في squash للضجيج أو إعادة صياغة الرسائل بـ git rebase -i. هذا يعيد كتابة التاريخ — لا يكون إلا على فرع لم يسحبه أحد سواك. اجعل Claude يشرح بالضبط ما يفعله كل سطر في خطة الـ rebase قبل أن تشغّلها، وأبقِ شبكة نجاة git reflog في بالك.
التقاط اصطلاح في CLAUDE.md: إن كان فريقك يستخدم نمط commit (Conventional Commits، أو بادئة ticket، أو قاعدة «الجسم يشرح لماذا»)، اكتبه في الـ CLAUDE.md للمشروع مرّة واحدة. عندئذٍ يتّبع كل commit يكتبه Claude نمط بيتك دون أن تُعيد شرحه في كل مرّة.

انتبه إلى

لا تسلّمه أبدًا أمرًا مدمّرًا لا تفهمه. git reset --hard، git push --force، git clean -fd، rebase أعمى — هذه تتلف عملًا يصعب أو يستحيل استرجاعه. اجعل Claude يشرح ما الذي سيفعله وما الذي ستخسره قبل أن يشغّل أي شيء يعيد الكتابة أو يحذف. الفهم قبل الفعل هو قاعدة هذا الـ playbook كلها.
commit واحد يخلط ثلاثة شواغل هو git blame ستندم عليه. حين يُجري نسخةٌ مستقبلية منك (أو زميل) bisect لـ bug وصولًا إلى ذلك الـ commit، لا يخبره الـ commit المتشابك بشيء. التزِم بكل شاغل وحده — يكلّفك دقيقتين الآن ويوفّر عليك فترة بعد ظهر لاحقًا.
الإنسان هو من يملك الـ merge. يكتب Claude المسوّدة ويجهّز ويحلّ؛ وأنت تقرأ كل diff وتوافق على كل commit وكل حلّ conflict. أنت المؤلّف المسؤول عمّا يستقرّ — عامل ناتجه كأنه PR من junior سريع: صحيح غالبًا، خاطئ بثقة أحيانًا.
لا تحلّ تلقائيًا conflict لا تستطيع قراءته. قبول «theirs» أو «ours» على عمياء يُسقط بصمت عمل أحد الجانبين. إن لم تفهم جانبَي الـ conflict، فتلك إشارة إلى التمهّل وجعل Claude يشرحه، لا إلى القبول والمضي.

ستحصل في النهاية على يصير الـ working tree المتشابك تاريخًا نظيفًا قابلًا للمراجعة — كل شاغل في commit خاصّ به برسالة تشرح *لماذا*، والـ merge محلولًا بفهم بدل التخمين، ووصف PR جاهز لمراجِعك. والشخص التالي الذي يقرأ git blame يشكرك.

أسئلة يطرحها الناس

هل من الآمن أن أدع Claude يشغّل git commands على الـ repo لديّ؟: نعم، مع الانضباط الذي بُني عليه هذا الـ playbook: اجعله *يشرح الحالة وما الذي سيفعله الأمر قبل أن يشغّل أي شيء*، ولا تدعه أبدًا يشغّل أمرًا مدمّرًا (`reset --hard`، `push --force`، `clean -fd`) لا تفهمه. في Claude Desktop توافق على كل إجراء، والمجلد المفتوح هو حدّك. القراءة والشرح آمنان دائمًا؛ أما أي شيء يعيد كتابة التاريخ أو يحذفه فيمرّ على عيني إنسان أولًا.
هل أعمل rebase أم merge للّحاق بـ main؟: يعتمد على مَن يملك الفرع غيرك. فرع feature تملكه وحدك يقبل rebase على `main` من أجل تاريخ نظيف خطّي. وفرع سحبه آخرون يكون merge أأمن له، لأن الـ rebase يعيد كتابة commits يبنون عليها. عند الشكّ، اطلب من Claude أن يشرح المقايضة لحالتك المحدّدة ويمشي على الخطوات — لا تدعه يشغّل rebase على عمياء على فرع مشترك.
هل يستطيع Claude كتابة رسائل الـ commit لي؟: نعم، وهو بارع في ذلك — لكنك تملك الرسالة. اجعله يكتب مسوّدة عنوان وجسم يشرح *لماذا* لزِم التغيير، ثم اقرأها وعدّلها قبل الالتزام. الرسالة التي تلتقط *لماذا* هي ما يجعل git blame مفيدًا لاحقًا؛ أما «fix stuff» فلا تفيد أحدًا. التقِط اصطلاح الـ commit لفريقك في `CLAUDE.md` مرّة واحدة وتتبعه كل مسوّدة.
ماذا عن conflict في الـ merge لا أفهمه؟: ذلك تحديدًا حين تتوقّف وتجعل Claude يشرحه. اطلب منه أن يُرِيك جانبَي الـ conflict — ما الذي غيّره `main` وما الذي غيّره فرعك — وما الذي كان كلٌّ منهما يحاول إنجازه، بلغة واضحة لا بعلامات diff فقط. conflict لا تستطيع قراءته هو conflict لا ينبغي أن تحلّه بعد؛ فهمه أولًا هو ما يجنّبك إسقاط عمل أحدهم بصمت. الإنسان هو من يملك الـ merge.