بوابة داخل وخارج

القدرة على العمل داخل نظام التحكم في الإصدار هي مهارة يحتاج إليها كل مبرمج. في كثير من الأحيان قد يبدو أن الحفر في Git وفهمه الداخلي هو مضيعة إضافية للوقت ويمكن حل المهام الأساسية من خلال مجموعة أساسية من الأوامر.

بالطبع ، أراد فريق AppsCast معرفة المزيد ، وللحصول على المشورة بشأن التطبيق العملي لجميع ميزات Git ، تحول الرجال إلى Yegor Andreyevich من Square.



دانييل بوبوف : مرحباً بالجميع. اليوم ، انضم إلينا ايجور أندرييفيتش من سكوير.

إيجور أندرييفيتش : مرحباً بالجميع. أنا أعيش في كندا وأعمل لدى Square ، وهي شركة برمجيات وأجهزة للقطاع المالي. بدأنا مع محطات لقبول المدفوعات عن طريق بطاقات الائتمان ، والآن نحن نقدم خدمات لأصحاب الأعمال. أنا أعمل على أحد منتجات Cash App. هذا بنك للهاتف المحمول يسمح لك بتبادل الأموال مع الأصدقاء ، وطلب بطاقة الخصم للدفع في المتاجر. وتمتلك الشركة العديد من المكاتب في جميع أنحاء العالم ، والمكتب الكندي لديه حوالي 60 مبرمج.

دانييل بوبوف : في بيئة مطوري نظام أندرويد ، تشتهر سكوير بمشاريعها المفتوحة المصدر التي أصبحت معايير صناعية: OkHttp و Picasso و Retrofit. من المنطقي أن تفتح هذه الأدوات للجميع ، فأنت تعمل كثيرًا مع Git. نود التحدث عن هذا.

ما هو بوابة

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

Git هو نظام ملفات مبسط ، على رأسه مجموعة من العمليات للعمل مع التحكم في الإصدار.

Git يسمح لك بحفظ الملفات بتنسيق معين. في كل مرة تكتب فيها ملفًا ، يقوم Git بإرجاع المفتاح إلى كائنك - التجزئة .

دانييل بوبوف : لاحظ الكثير من الناس أن المستودع به دليل خفي سحري. لماذا هو مطلوب؟ هل يمكنني حذفها أو إعادة تسميتها؟

إيجور أندرييفيتش : إنشاء مستودع ممكن من خلال الأمر git init . يقوم بإنشاء دليل .git الذي يستخدمه Git للتحكم في الملفات. يخزن Git كل ما تفعله في مشروعك ، فقط بتنسيق مضغوط. لذلك ، يمكنك استعادة المخزون من هذا الدليل.

أليكسي كودريافتسيف : اتضح أن مجلد المشروع الخاص بك هو أحد إصدارات مجلد Git الموسع؟

إيجور أندرييفيتش : استنادًا إلى الفرع الذي أنت فيه ، تقوم git باستعادة مشروع يمكنك العمل معه.

أليكسي كودريافتسيف : ما هو داخل المجلد؟

إيجور أندرييفيتش : بوابة يخلق مجلدات وملفات محددة. المجلد الأكثر أهمية هو .git / الكائنات ، حيث يتم تخزين جميع الكائنات. إن أبسط كائن هو النقطة النقطية ، وهو في الأساس نفس الملف ، ولكن بتنسيق يفهمه. عندما تريد حفظ ملف نصي في المستودع ، يقوم Git بضغطه وأرشفته وإضافة بيانات وإنشاء نقطة.

هناك أدلة - هذه مجلدات بها مجلدات فرعية ، على سبيل المثال يحتوي Git على نوع كائن شجرة يحتوي على مراجع للنقط ، إلى الأشجار الأخرى.

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

عند إنشاء التزام ، يتم إصلاح ارتباط إلى دليل العمل - شجرة.

الالتزام عبارة عن رابط إلى شجرة يحتوي على معلومات حول من قام بإنشائها: البريد الإلكتروني والاسم ووقت الإنشاء والرابط إلى الأصل (الفرع الرئيسي) والرسالة. Git يضغط أيضًا ويكتب التزامًا بدليل الكائنات.

لمعرفة كيفية عمل كل هذا ، تحتاج إلى سرد الدلائل الفرعية من سطر الأوامر.

فوائد العمل مع جيت

دانييل بوبوف : كيف يعمل جيت؟ لماذا هي خوارزمية العمل معقدة للغاية؟

إيجور أندرييفيتش : إذا قارنت Git مع Subversion (SVN) ، في النظام الأول ، هناك عدد من الوظائف التي تحتاج إلى فهمها. سأبدأ بمساحة التدريج ، والتي لا ينبغي اعتبارها قيدًا على بوابة Git ، بل ميزات.

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

أليكسي كودريافتسيف : كيف يختلف جيت عن أنظمة التحكم في الإصدار الأخرى؟

إيجور أندرييفيتش : شخصيا ، بدأت مع SVN ثم انتقلت على الفور إلى Git. الأهم من ذلك ، جيت هو نظام للتحكم في الإصدار اللامركزي. جميع نسخ من بوابة جيت هي بالضبط نفس الشيء. كل شركة لديها خادم حيث يوجد الإصدار الرئيسي ، ولكن لا يختلف عن ذلك الموجود لدى المطور على الكمبيوتر.

تحتوي SVN على مستودع مركزي ونسخ محلية. هذا يعني أن أي مطور يمكنه كسر المستودع المركزي وحده.

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

دانييل بوبوف : جيت تشتهر بتفرعها ، والذي يعمل بشكل أسرع بشكل ملحوظ من SVN. كيف يفعل ذلك؟

إيجور أندرييفيتش : في SVN ، يعد الفرع نسخة كاملة من الفرع السابق. لا يوجد فرع التمثيل الجسدي في جيت. هذا رابط للالتزام الأخير في خط تطوير معين. عندما يحفظ Git الكائنات ، عند إنشاء التزام ، فإنه ينشئ ملفًا يحتوي على معلومات محددة حول الالتزام. بوابة يخلق ملف رمزي - symlink مع وصلة لملف آخر. عندما يكون لديك العديد من الفروع ، فأنت تشير إلى عمليات ارتكاب مختلفة في المستودع. لتتبع محفوظات الفرع ، يتعين عليك الانتقال من كل التزام باستخدام الرابط مرة أخرى إلى الالتزام الأصل.

فروع مرجم

دانييل بوبوف : هناك طريقتان لدمج فرعين في واحد - وهذا هو دمج وإعادة. كيف يمكنك استخدامها؟

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

لدمج ، يمكنك استخدام سريع إلى الأمام. يكون ذلك ممكنًا إذا تم بدء العمل في فرع الميزة منذ اللحظة التي لم يتم فيها تنفيذ أي تعهدات جديدة بشكل رئيسي. وهذا هو ، الالتزام الأول في الميزة هو الالتزام الأخير في الرئيسي.

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

يمكن أن يكون الأمر خلاف ذلك. ينشئ Git التزامًا بدمجًا جديدًا ، يحتوي على رابطين لالتزامات الوالدين: واحد في الرئيسي والآخر في الميزة. مع الالتزام الجديد ، يتم توصيل فرعين ويمكن حذف الميزة مرة أخرى.

بعد التزام الدمج ، يمكنك إلقاء نظرة على القصة ورؤية أنها متشعبة. إذا كنت تستخدم أداة تجسد الالتزام بيانيا ، فستظهر بصريا شجرة عيد الميلاد. هذا لا يكسر Git ، لكن من الصعب على مطور مشاهدة مثل هذه القصة.

أداة أخرى هي rebase . من الناحية النظرية ، يمكنك أخذ جميع التغييرات من فرع الميزة والوجه عليها على الفرع الرئيسي. يصبح التزام الميزة الأولى الالتزام الجديد أعلى التزام الالتزام الرئيسي.

هناك مشكلة - لا يمكن لـ Git تغيير الالتزامات. كان هناك التزام في الميزة ولا يمكننا فقط لفه على الرئيسي ، لأن كل التزام له طابع زمني.

في حالة rebase ، يقرأ Git جميع الالتزامات الموجودة في الميزة ، ويحفظها مؤقتًا ، ثم يعيد إنشاؤها بنفس الترتيب الرئيسي. بعد rebase ، تختفي الإلتزامات الأولية ، وتظهر إلتزامات جديدة بنفس المحتوى في أعلى الصفحة الرئيسية. هناك مشاكل. عندما تحاول إعادة إنشاء فرع يعمل معه أشخاص آخرون ، يمكنك كسر المستودع. على سبيل المثال ، إذا بدأ شخص ما فرعه من التزام كان موجودًا ، وقمت بتدمير ذلك الالتزام وإعادة إنشائه. Rebase هو أكثر ملاءمة للفروع المحلية.

دانييل بوبوف : إذا أدخلت قيودًا على أن هناك شخصًا واحدًا فقط يعمل في فرع واحد من الميزات ، فوافق على أنه لا يمكنك إنشاء فرع لميزة واحدة من قسم آخر ، فلن تنشأ هذه المشكلة. ولكن ما النهج الذي تمارسه؟

إيجور أندرييفيتش : نحن لا نستخدم فروع الميزات بالمعنى المباشر لهذا المصطلح. في كل مرة نجري فيها التغيير ، ننشئ فرعًا جديدًا ، ونعمل فيه ونضعه في الحال على الفور. لا توجد فروع طويلة اللعب.

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

دانييل بوبوف : كيف لا تخشى دمج ميزة الخمول الرئيسية ، لأن تحليل مهمة إلى فواصل زمنية كل ساعة يكون غير واقعي في كثير من الأحيان؟

إيجور أندرييفيتش : نحن نستخدم نهج أعلام المعالم . هذه علامات ديناميكية ، وهي ميزة محددة لها حالات مختلفة. على سبيل المثال ، وظيفة إرسال المدفوعات إلى بعضها البعض إما قيد التشغيل أو إيقاف التشغيل. لدينا خدمة توفر هذه الحالة بشكل حيوي للعملاء. أنت من الخادم تحصل على ميزة إيقاف القيمة أم لا. يمكنك استخدام هذه القيمة في الكود - قم بإيقاف تشغيل الزر الذي ينتقل إلى الشاشة. الكود نفسه موجود في التطبيق ، ويمكن إصداره ، لكن لا يمكن الوصول إلى هذه الوظيفة ، لأنه وراء علامة الميزة.

دانييل بوبوف : غالبًا ما يقال للوافدين الجدد إلى Git أنه بعد إعادة التسديد ، يجب أن تضغط بقوة. من اين هو؟

إيجور أندرييفيتش : عندما تدفع فقط ، قد يلقي مستودع آخر خطأ: أنت تحاول بدء فرع ، لكن لديك تعهدات مختلفة تمامًا في هذا الفرع. يتحقق Git من جميع المعلومات حتى لا تقوم بتفكيك المستودع عن طريق الخطأ. عندما تقول git push force ، قم بإيقاف هذا الاختيار معتقدًا أنك تعرف أفضل منه ، واطلب إعادة كتابة الفرع.

لماذا هذا مطلوب بعد rebase؟ Rebase إعادة يخلق ارتكاب. اتضح أن الفرع يسمى أيضًا ، لكنه يلتزم به بعلامات أخرى ، ويقسم Git عليك. في هذه الحالة ، من الطبيعي تمامًا القيام بعملية دفع ، لأنك تتحكم في الموقف.

دانييل بوبوف : لا يزال هناك مفهوم rebase تفاعلي ، ويخشى الكثيرون منه.

إيجور أندرييفيتش : لا يوجد شيء فظيع. نظرًا لحقيقة أن Git تعيد إنشاء القصة خلال rebase ، فإنها تخزنها مؤقتًا قبل إلقائها. عندما يكون لديه تخزين مؤقت ، فإنه يمكن أن يفعل أي شيء مع ارتكابها.

يفترض Rebase في الوضع التفاعلي أن Git قبل rebase يطرد نافذة محرر نصي يمكنك من خلالها تحديد ما يجب القيام به مع كل التزام فردي. يبدو كأنه عدة أسطر من النص ، حيث يكون كل سطر واحدًا من الإلتزامات الموجودة في الفرع. قبل كل التزام ، هناك إشارة إلى العملية التي تستحق القيام بها. أبسط عملية افتراضية هي الاختيار ، أي لاتخاذ وتدرج في rebase. الأكثر شيوعًا هو الاسكواش ، ثم سيتولى Git إجراء التغييرات من هذا الالتزام ودمجها مع التغييرات السابقة.

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

قائمة الفرق طويلة. يمكنك إلقاء الالتزام - إسقاط ويختفي ، يمكنك تغيير رسالة الالتزام ، إلخ.

أليكسي كودريافتسيف : عندما تواجه صراعات في rebase التفاعلية ، فإنك تمر بجميع دوائر الجحيم.

إيجور أندرييفيتش : أنا بعيد كل البعد عن فهم كل حكمة rebase التفاعلية ، لكنها أداة قوية ومعقدة.

تطبيق بوابة العملية

دانييل بوبوف : دعنا ننتقل إلى الممارسة. في المقابلة ، كثيراً ما أسأل: "لديك ألف التزام. في البداية كل شيء على ما يرام ، في اختبار الألف كسر. كيف يمكن للمرء أن يجد التغيير الذي أدى إلى ذلك بمساعدة غيتا؟ "

إيجور أندرييفيتش : في هذه الحالة ، تحتاج إلى استخدام التشريح ، على الرغم من أنه من الأسهل تحمل اللوم.

لنبدأ مع واحد للاهتمام. Git bisect ينطبق على الموقف الذي تعاني فيه من ارتداد - لقد كان وظيفيًا ، لكنه نجح ، لكنه توقف فجأة. لمعرفة متى تعطلت الوظيفة ، يمكنك من الناحية النظرية التراجع إلى الإصدار السابق من التطبيق ، وإلقاء نظرة على الكود ، ولكن هناك أداة تسمح لك بالتعامل مع المشكلة بطريقة منظمة.

Git bisect هو أداة تفاعلية. هناك أمر سيئ git bisect يمكنك من خلاله الإبلاغ عن وجود التزام غير صالح و bitect جيد - عن التزام عملي. في كل مرة يتم فيها إصدار التطبيق ، نتذكر تجزئة الالتزام الذي تم إصداره منه. يمكن أيضًا استخدام هذا التجزئة للإشارة إلى ارتكاب أعمال سيئة وجيدة. يستقبل Bisect معلومات حول الفاصل الزمني الذي قطعت فيه إحدى التعيينات الوظيفة ، وتبدأ جلسة البحث الثنائية ، حيث تصدر تدريجيًا تعهدات للتحقق مما إذا كانت تعمل أم لا.

لقد بدأت الجلسة ، يقوم Git بالتبديل إلى أحد عمليات الإيقاف في الفاصل الزمني ، ويبلغنا بذلك. في حالة ارتكاب ألف ، لن يكون هناك العديد من التكرارات.

يجب إجراء التحقق يدويًا: من خلال اختبارات الوحدة أو تشغيل التطبيق والنقر يدويًا. بوابة bisect هو النصي مريحة. في كل مرة يصدر فيها التزامًا ، تقدم له نصًا للتحقق من أن الشفرة تعمل.

Blame هي أداة أبسط تتيح لك ، بناءً على اسمها ، العثور على "الجاني" لفشل وظيفي. نظرًا لهذا التعريف السلبي ، لا يحبذ الكثيرون في مجتمع اللوم.

ماذا يفعل؟ إذا أعطيت git اللوم ملفًا محددًا ، فسيظهر الخطي في هذا الملف الالتزام الذي غير هذا السطر أو ذاك. أنا لم تستخدم قط بوابة اللوم من سطر الأوامر. كقاعدة عامة ، يتم ذلك في IDEA أو Android Studio - انقر ومعرفة من قام بتغيير أي سطر من الملف وفي أي التزام.

دانييل بوبوف : بالمناسبة ، في Android Studio كان يطلق عليه Annotate. تمت إزالة دلالة سلبية من اللوم.

أليكسي كودريافتسيف : بالضبط ، في xCode أطلقوا عليه اسم المؤلفين.

إيجور أندرييفيتش : قرأت أيضًا أن هناك مدحًا مفيدًا - للعثور على الشخص الذي كتب هذه الشفرة الممتازة.

دانييل بوبوف : تجدر الإشارة إلى أنه بناءً على اقتراحات المراجعين بشأن عمل طلب السحب. إنه ينظر إلى من لمست ملفًا معينًا بشكل خاص ، ويقترح أن هذا الشخص سيكون قادرًا على مراجعة الكود.
في حالة المثال عن ألف عملية ارتكاب ، فإن إلقاء اللوم في 99٪ من الحالات سيظهر الخطأ الذي حدث. Bisect هو بالفعل الملاذ الأخير.

إيجور أندرييفيتش : نعم ، ألجأ إلى التشريح بشكل نادر للغاية ، لكني أستخدم التعليقات التوضيحية بانتظام. على الرغم من أنه من المستحيل في بعض الأحيان فهم سبب عدم وجود علامة فارغة من سطر الشفرة ، إلا أنه من الواضح طوال فترة الالتزام ما أراد المؤلف القيام به.

كيفية العمل مع PRS مكدس؟

دانييل بوبوف : سمعت أن سكوير يستخدم طلبات السحب المكدسة (PRS).

إيجور أندرييفيتش : على الأقل في فريق أندرويد الخاص بنا ، نستخدمها غالبًا.
نكرس الكثير من الوقت لجعل كل طلب سحب يسهل مراجعته. في بعض الأحيان يكون هناك إغراء للتغذية ، والتغذية السريعة ، والسماح للمراجعين بفهمها. نحاول إنشاء طلبات سحب صغيرة ووصف قصير - يجب أن يتحدث الرمز عن نفسه. عندما تكون طلبات السحب صغيرة ، فمن السهل والسريع التفاخر.

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

كيف يمكننا الالتفاف حول هذا؟ بعد أن أنشأنا طلب السحب الأول ، نواصل العمل ، وننشئ فرعًا جديدًا من الفرع الحالي ، والذي استخدمناه قبل طلب السحب. كل فرع لا يأتي من السيد ، ولكن من الفرع السابق. عندما ننتهي من العمل على هذه الوظيفة ، نرسل طلب سحب آخر ونشير مرة أخرى إلى أنه مع الدمج ، لا يتم دمجه في برنامج رئيسي ، ولكن في الفرع السابق. اتضح مثل هذه السلسلة من طلبات السحب - prs مكدسة. عندما يراجع شخص ما ، يرى التغييرات التي تم إجراؤها بواسطة هذه الميزة فقط ، ولكن ليس التغييرات السابقة.

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

دانيل بوبوف : أفهم بشكل صحيح أنه في النهاية سيكون هناك بعض طلب السحب الأخير الذي يحتوي على جميع طلبات السحب الصغيرة. كنت صب هذا الموضوع دون النظر؟

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

أليكسي كودريافتسيف : هل لديك ظروف سباق عندما يكون الفرع الأول قد جمد بالفعل ، وفقط بعد أن توقف الفرع الثاني في الأول لأنه لم يغير الهدف لإتقانه؟

إيجور أندرييفيتش : نحتفظ به باليد ، لذلك لا توجد مثل هذه الحالات. أفتح طلب سحب ، لاحظ الزملاء الذين أريد منهم الحصول على مراجعة ، وعندما يكونون جاهزين ، انتقل إلى bitbucket ، اضغط على دمج.

أليكسي كودريافتسيف : لكن ماذا عن الشيكات على سي أي أنه لم يتم كسر أي شيء؟

إيجور أندرييفيتش : نحن لا نفعل هذا. يعمل CI على الفرع ، وهو الأساس لطلب السحب ، وبعد التحقق ، نقوم بتغيير القاعدة. من الناحية الفنية ، لا يتغير ، نظرًا لأنك تستهدف أيضًا عدد التغييرات.

دانييل بوبوف : هل تدفع مباشرة إلى الماجستير أم تتطور؟ وعند الإفراج عن صراحة تشير إلى الالتزام الذي جمع من؟

إيجور أندرييفيتش : ليس لدينا تطوير ، سيد فقط. سنصدر بالتأكيد كل أسبوعين. عندما نبدأ في إعداد إصدار ، نفتح فرع إصدار وبعض الإصلاحات الأخيرة تذهب إلى الرئيسي وإلى هذا الفرع. نستخدم العلامات - روابط دائمة لالتزام معين ، اختياريًا مع بعض المعلومات. إذا كان هناك نوع من الالتزام هو التزام بالإفراج ، فسيكون من الجيد الاحتفاظ في التاريخ الذي أصدرناه من هذا الالتزام. يتم إنشاء علامة ، يحفظ Git معلومات الإصدار ، ويمكنك الرجوع إليها لاحقًا.

أليكسي كودريافتسيف : أين تدرس جيت ، ماذا تقرأ؟

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

لن نتحدث عن Git في Saint AppsConf القادمة. ولكن من ناحية أخرى ، قررنا إجراء تجربة وقمنا بإضافة تقارير تمهيدية إلى برنامج المؤتمرات الحافل بالأحداث ، حيث يتقاسم متحدثون من صناعات التطوير ذات الصلة المعرفة لتوسيع آفاق مطور متنقل. ننصحك بالاهتمام بالعرض الذي قدمه نيكولاي جولوف من Avito حول قواعد البيانات : كيف لا نخطئ ونختار قاعدة البيانات الصحيحة ، وكيف نستعد للنمو وما هو مهم في عام 2019.

تُصدر AppsCast كل أسبوعين يوم الأربعاء ، وإذا كنت تفضل إصدار الصوت إلى الإصدار النصي ، فقم بالاشتراك معنا في SoundCloud ، مثل ومناقشة المواضيع في الدردشة .