[Ar] A Git branching strategy
في البوست ده هاتكلم عن الـstrategy اللي ماشي بيها حالياً في تنظيم الـgit branches.
(1) Overview
باختصار، هي branching strategy بسيطة جداً:
ببقى كإني تقريباً شغال على الـmaster .. بس بدل مابشتغل على الـmaster على طول، بفتح short-lived branch من الـmaster لأي شغل وبـmergeـه على الـmaster في أقل من يوم وبمسحه بعدها.
(2) Short-lived
الـkeyword هنا هي كلمة “short-lived”: أغلب الـbranches اللي بعملها بيبقى عمرها يوم أو أقل من يوم.
الهدف من ده حاجتين:
(أ) أخلي شغلي خطوات صغيرة.
(ب) أقلل احتمالية الـmerge conflicts ومشاكل الـintegration.
(3) Linear & squashed
ممكن تقرا البوست ده عن النقطة دي.
(4) master-to-branch merge
وأنا شغال على الـbranch، ممكن في أي وقت أ-merge الـlatest master عليه عشان آخد الـupdates.
كده ممكن الـgit history بتاع الـbranch يتعقد شوية، بس مش مشكلة.
كده كده لما أ-squash البرانش وأنا بـmergeـه على الـmaster كل ده هيروح && هو short-lived أصلاً (أقل من يوم) فمش مشكلة.
(5) Slicing work
إزاي أخلي الـbranch يبقى عمره قصير بينما الـfeature كبيرة؟
الإجابة: حاول تـslice شغلك أكتر.
بدل ما تعمل برانش واحد فيه كل الـauthentication مثلاً، اعمل برانش للـsign up وبعد كده برانش للـforgot password وهكذا.
بل أصلاً ده أحد الأهداف الرئيسية للـshort-lived branches: إنك تمشي في خطوات أصغر .. وده شئ كويس في العموم.
(6) Managing releases
طاب ماذا لو الـfeature صفحة كبيرة مثلاً وماينفعش الـuser يشوفها غير وهي كاملة؟
الإجابة: الـfeature flags. ربما لا غنى عنها، بالأخص في الـfrontend.
مش هاتكلم عنها هنا، بس ممكن تلاقي recipe بسيطة نسبياً هنا.
(7) Conclusion
فبس كده، دي الطريقة اللي ماشي بيها حالياً في تنظيم الـbranches: كلها branches بسيطة طالعة من الـmaster ورايحة للـmaster وأغلبها مابيعيش أكتر من يوم. وبـsquash عشان الـgit history بتاع الـmaster يبقى بسيط وlinear، وبـmanage الـreleases عن طريق الـfeature flags.
شكراً لقرايتكم.