Skip to main content
Engineering9 min read

سير عمل Git التي لا تجعلك ترغب في الاستقالة

Trunk-based مقابل GitFlow مقابل GitHub Flow — لقد استخدمت الثلاثة. إليك ما ينجح فعليًا للمطورين المنفردين والفرق الصغيرة، ولماذا معظم سير عمل Git معقدة بشكل مفرط.

Part ofProduct Systems->
By Jason TeixeiraOctober 25, 2025
GitVersion ControlWorkflowDevOpsBest Practices
Share:
On this page

لقد عملت مع GitFlow في مشاريع أكبر. فروع الميزات، فروع التطوير، فروع الإصدار، فروع الإصلاح العاجل. كان الرسم البياني للفروع يبدو مثل خريطة مترو الأنفاق. كان دمج ميزة يتطلب درجة دكتوراه في حل النزاعات.

الآن أستخدم التطوير القائم على الفرع الرئيسي (trunk-based development). فرع واحد. الشحن من main. زاد تردد النشر لدي من أسبوعي إلى يومي.

لماذا معظم سير عمل Git معقدة بشكل مفرط

تم تصميم GitFlow للبرامج التي تُشحن كل ثلاثة أشهر على وسائط مادية. إذا كانت عملية النشر لديك تتضمن حرق قرص مضغوط، فأنت بحاجة إلى فروع الإصدار.

إذا كنت تنشر عن طريق الدمج إلى main و Vercel/GitHub Actions تتولى الباقي، فلن تحتاج إلى 90% من GitFlow.

ما أفعله بالفعل

\\

Reader route

article -> proof -> offer

ReadClusterProofScope

cluster

Product Systems

intent

Engineering

route

next step

What to do with this

Turn the note into a build path.

If this topic maps to a real business problem, keep reading the cluster, study the academy path, or route the work into a scoped engagement.

Jason Teixeira
Written by
Jason Teixeira
Founder, Sage Ideas Studio · Principal Engineer
livebuild 5d6c8652026-08-05 06:00Z
// solo studio// no analytics resold// every commit human-reviewed