http://www.codinghorror.com/blog/2010/03/compiled-or-bust.html
بله موافقم، مایکروسافت داره به سمت ASP.Net MVC میره.
نوشتن اتوماسیون با ASP.Net دیگه کار درستی نیست! سیلورلایت بهترین انتخابه(فقط از MVVM استفاده نکنید، اگر مشکل زمان دارید)
Subversion 1.6.0
- SVN برای کار کردن نیازی به هیچ افزونهای در هیچ IDE ایی نداره. همان برای مثال TortoiseSVN کار شما را راه خواهد انداخت.
عمدهی افزونههایی رو که من برای کار با SVN دیدم در حقیقت یک سری محصور کنندهی تواناییهای TortoiseSVN در IDE های مختلف هستند.
- برای VS6 یک افزونهی غیر رایگان هست:
http://www.pushok.com/soft_svn.php
نداشتن Relation بین موجودیت Comment و User
- قسمت پروژهها فقط مرتبط هست به مشکلات پروژهها و هیچ هدف دیگری ندارد. لطفا رعایت کنید.
عدم رعایت این مساله در آینده، سبب حذف شما از سایت خواهد شد.
سایت ما هدف تبدیل شدن به انجمن عمومی پرسش و پاسخ را ندارد. از روز اول نداشتهاست.
نیازی به تعریف خیلی از مسایل در EF نیست. به صورت خودکار آنها را میتواند تشخیص دهد. مطالب سری EF را در سایت مطالعه کنید، این مورد دقیقا بحث شدهاست.
هدر فقط در صفحه نخست گزارش
.MainTablePreferences(table => { table.ShowHeaderRow(false);
events.MainTableCreated(args => { var infoTable = new PdfGrid(numColumns: 1) { WidthPercentage = 100 }; infoTable.AddSimpleRow((cellData, properties) => {}); // ... the rest ... var table = infoTable.AddBorderToTable(borderColor: BaseColor.LIGHT_GRAY, spacingBefore: 10f); table.SpacingAfter = 10f; args.PdfDoc.Add(table); });
قبلا مطلبی رو در مورد توانایی AutoMapper در تهیهی یک چنین نگاشتهایی با استفاده از متد project to آن، تهیه کردم. البته کلیاتش فرقی نکرده؛ ولی syntax اش تغییر کرده که آخرین به روز رسانی اون رو در اینجا میتونید مطالعه کنید. بهشما توصیه میکنم از همین روش استفاده کنید و سعی نکنید این متد رو خودتون بازنویسی کنید و بهتر از است از همان نمونهای که سالهاست آزمایش شده و در حال استفادهاست، کمک بگیرید.
return context.OrderLines.Where(ol => ol.OrderId == orderId) .ProjectTo<OrderLineDTO>(configuration).ToList();
آیا به این نتیجه رسیدید که اصل DRY را نقض کردهایم؟ بله همین طور است. تکرار کلاسهای css مربوط به بوت استرپ، تکرار هلپرهای توکار ASP.NET MVC بارها و بارها، خوانایی کد را پایین میارود و در برخی موارد هم خسته کننده خواهد بود. اگر با مباحث مربوط به EditorTemplateها قبلا آشنا شده باشید، خیلی سریع عنوان خواهید کرد که بهتر است از این امکان بهره برد؛ بله درست است. برای این منظور در مسیر Views/Shared/EditorTemplates، فایل cshtml. همنام با نوع داده مد نظر را ایجاد میکنیم.
String.cshtml
@model string @Html.TextBox("",ViewData.TemplateInfo.FormattedModelValue, new { @class="form-control",placeholder=ViewData.ModelMetadata.Watermark})
Enum.cshtml
@model Enum @Html.EnumDropDownListFor(m => Model, new { @class = "form-control" })
حال دوباره به نتیجه حاصل از تغییرات اعمال شده توجه کنید:
این نتیجه امیدوار کننده است ولی بازهم یکسری از کدها بی دلیل تکرار شدهاند. هلپرهای زیر نیز میتوانند در کاهش کدها به کمک ما برسند :
public static class BootstrapHelpers { public static IHtmlString BootstrapLabelFor<TModel,TProp>( this HtmlHelper<TModel> helper, Expression<Func<TModel,TProp>> property) { return helper.LabelFor(property, new { @class = "col-md-2 control-label" }); } public static IHtmlString BootstrapLabel( this HtmlHelper helper, string propertyName) { return helper.Label(propertyName, new { @class = "col-md-2 control-label" }); } }
از کلاس بالا برای عدم تکرار کلاسهای بوت استرپ مربوط به Label، استفاده میشود .
حال دوباره نتیجه را مشاهده کنید:
خیلی عالی؛ توانستیم از تکرار یکسری از کلاسهای بوت استرپ خلاص شویم. اما در ادامه با استفاده از یک Object Template به عنوان EditorTemplate برای نوع دادههای Complex، کار را تمام خواهیم کرد.
EditorTemplateهای تعریف شده در بالا، صرفا برای نوع دادههای خاصی مورد استفاده قرار خواهند گرفت؛ ولی پیاده سازی یک EditorTemplate جنریک که حتی از ویومدلهای موجود در پروژه نیز پشتیابی کند، به شکل زیر خواهد بود.
Object.cshtml
@model dynamic @foreach (var prop in ViewData.ModelMetadata.Properties .Where(p => p.ShowForEdit)) { if (prop.TemplateHint == "HiddenInput") { @Html.Hidden(prop.PropertyName) } else { <div class="form-group"> @Html.BootstrapLabel(prop.PropertyName) <div class="col-md-10"> @Html.Editor(prop.PropertyName) @Html.ValidationMessage(prop.PropertyName) </div> </div> } }
با استفاده از ViewData.ModelMetadata میتوان به خصوصیات مدل مربوط به ویو دسترسی پیدا کرد که در بالا با استفاده از همین خصوصیت به تمام پراپرتیهای مدل دسترسی پیدا کرده و مقداری کد تکراری باقی مانده را هم در اینجا کپسوله کردیم.
حال کافی است به شکل زیر عمل کنیم:
داستانهای کاربر
توسعهدهندگان، ویژگیهای مورد نظر پروژه را با جمعآوری نیازمندیها، در قالب داستانهای کاربر احصاء میکنند و به هرکدام متناسب با پیچیدگیاش امتیازی اختصاص میدهند. با لیستی از داستانهای دارای ابعادی مشخص و بودجه و زمان مورد نیاز برای هرکدام، مشتریان قادر به این انتخابند که کدام ویژگیها در تکرار (iteration) بعدی باقی بماند. مشخصکردن بودجه و زمان، یعنی تعیین حجم کاری که تیم توسعه برای انجام آن ویژگی، نیاز میداند. برآورد بودجۀ مورد نیاز تکرار اول به صورت تجربی خواهد بود و ممکن است این تخمین در ابتدا نادرست باشد؛ اما با شروع تکرار بعدی درست خواهد شد. در پایان هر تکرار، امتیازات به دست آمده از داستانهای کامل شده را جمع کنید. مجموع این امتیازات، نشانگر سرعت شما خواهد بود. این سرعت شاخص خوبی جهت چگونگی بودجهبندی مرحلۀ بعد است. هنگامیکه امتیازات جمعآوری شده به حد مطلوبی رسید، «سرعت پیشرَوی»، شاخص مناسب دیگری برای بودجهبندی است که عبارت است از متوسط سرعت سه تکرار آخر.
با این کار شما به دیدگاه مناسبی از فاز برنامهریزی دست پیدا میکنید. حال اجاز دهید نگاه دقیقتری به شیوههای برنامهریزی داشته باشیم.
برنامهریزی (planning game) دو فاز دارد: فاز شناسایی و فاز برنامهریزی. در فاز شناسایی، توسعهدهندگان و مشتریان را دور هم جمع میکنند تا دربارۀ نیازمندیهای سیستم در حال طراحی، گفتگو کنند. به خاطر داشته باشید که این کار تا وقتی انجام میشود که به ویژگیهایی (features) کافی برای شروع انجام کار برسیم و البته واضح است که چنین لیستی از ویژگیهای احصاء شده، هرچقدر هم که تلاش شود، کامل نخواهد بود. مشتریان اغلب اوقات، خواستهی خود را یا نمیدانند یا نمیتوانند به خوبی توضیح دهند. بنابراین معمولاً این لیست به مرور تغییر میکند. در ضمن آنکه برخی ویژگیها دقیقتر میشود، مواردی نیز ممکن است به لیست افزوده شوند یا حتی میتوان برخی ویژگیهای نامربوط را از لیست حذف کرد. در مرحلۀ شناسایی، ویژگیها به داستانهای کاربر تجزیه شد و ثبت میشوند.
یک داستان کاربر عبارت است از توصیفی کوتاه از یک ویژگی که نمایانگر یک واحد ارزش کسب و کار برای مشتری است. داستانهای کاربر از زبان کاربر بیان شدهاند و قالب نوشتاری زیر را دارند:
به عنوان «نوع کاربر»، من میخواهم «یک فعل» تا «منفعتی برای کسب و کار»
یا به صورت:
به منظور «یک دلیل» به عنوان «نقش کاربر» من میخواهم «یک فعل»
داستانهای کاربر معمولاً در جلسهی گفتگو با مشتری بر روی کارتهای راهنما نوشته شده و در آن از واژگان و ادبیاتی استفاده میشود که برای مشتری قابل فهم باشد. ممکن است چنین بیاندیشید که ثبت نیازمندیها، خلاف مزیتهای چابکسازی است؛ چرا که تولید نرمافزار کارآمد و چابک مبتنی بر مستندسازی گسترده و فراگیر خواهد بود. در واقع، داستانهای کاربر به طور ساده فقط یادآورندۀ جزئیات بیشتری از گفتگوی انجام شدهاند که به عمد بهصورت کوتاه و دقیق نوشته شدهاند. فهم دقیقتر جزئیات کار، مستلزم ارتباط بیشتر میان توسعهدهندگان و مشتری است. در واقع همسو با این اصل چابک که میگوید: «مؤثرترین و کارآمدترین شیوۀ انتقال اطلاعات در میان تیم توسعه و به خارج از آن، گفتگوی چهره به چهره است.»
هنگام احصاء ویژگیهای پروژه تحت عنوان داستانهای کاربری، از اصول INVEST (که پیشتر گفته شد) جهت کنترل مناسب بودن این داستانها استفاده کنید. شکل 2-3 مثالی از یک داستان کاربر را که توصیفکنندۀ ویژگی «افزودن یک بن تخفیف به سبد خرید» است، نشان میدهد. «تخفیف گرفتن»، یک منفعت کسب و کار است برای عامل (actor) اصلی، یعنی مشتری. «یک بن تخفیف به سبد بیفزا» نام فرآیند یا «use case» مربوط است.
معیار پذیرش همچنین به تشخیص جزئیات بیشتر یا شناسایی وابستگیها کمک میکند. مثلاً در شکل 3-3 تعریف «in date» چیست و چه چیزی حدود یک بن تخفیف را مشخص میکند؟ معمولاً باید حداقل سه معیار پذیرش وجود داشته باشد. در فصل بعد در یک مطالعۀ موردی، مطالب بیشتری را دربارۀ داستانهای کاربر خواهید آموخت.
هنگامیکه تیم و مشتریان حسکنند که حدود 75 درصد از ویژگیهای اصلی احصاء شده است، توسعهدهندگان ابعاد داستانها را تخمین زده و آنها را برای اولویتبندی توسط مشتری آماده میکنند.
تخمین
شکی در آن نیست که تخمینزدن کار سختی است. تخمینزدن هم دانش است هم هنر. تخمینزدن در یک پروژۀ تازه شروع شده، بسیار سخت است زیرا مجهولات بسیاری در آن وجود دارد.
یکی از روشهای تخمین گروهی، روش «Planning Poker» نام دارد. در این روش همهی اعضای فنی تیم، متشکل از توسعهدهندگان نرمافزار، تحلیلگران، متخصصان امنیت و زیرساخت، مشارکت میکنند. نقش مشتری در این حالت پاسخگویی به سؤالات احتمالی اعضای تیم است تا ایشان بهتر بتوانند تخمین بزنند.
شیوۀ انجام کار به این صورت است که عضوی از تیم، یک داستان کاربر را برداشته و آن را برای تیم توضیح میدهد. تیم دربارۀ آن ویژگی با مشتری گفتگو کرده تا جزئیات بیشتری را دریابد. وقتی که تیم به درک خوبی از آن رسید، رأیگیری آغاز میشود. هر عضو تیم با یک کارت، از مجموعهای ازکارتهایی با شمارههای 0، 1 ، 2، 3، 5، 8، 13، 20، 40 و 100 رأی خود را اعلام میکند.
تیم باید از داستانی شروع کند که نسبتاً کوچک و ساده باشد. این داستان به عنوان مبنا انتخاب میشود. هر تخمین داستان کاربر، باید به نسبت این داستان کوچک انجام شود. اگر داستان مبنا به خوبی انتخاب نشود، بقیۀ تخمینها نادرست خواهد بود.
اگر همهی اعضای تیم به یک صورت رأی دهند، آن رأی، تخمین آن داستان خواهد شد. اگر اختلاف آراء وجود داشت، ناظر یعنی کسی که رأی نمیدهد، از افرادی که بالاترین و پایینترین امتیاز را دادهاند، میخواهد که علل خود را توضیح دهند. سپس تیم مجدداً گفتگو کرده و دوباره رأیگیری میکند. طبق تجربه، خوب است که زمان معقولی، برای هر گفتگو در نظر گرفته شود.
اگر تخمین یک داستان به دلیل فقدان دانش فنی، بسیار سخت بود، مناسب است که این داستان کنار گذاشته شود و داستان دیگری برای برطرف کردن مشکل ناآشنایی با دانش فنی مورد نظر فراهم شود. بدین ترتیب تیم توسعه در موقعیت بهتری میتواند نسبت به داستان جدید تخمین بزند.
داستانهایی که بیش از یک هفته کار نیاز داشته باشند با عنوان داستانهای حماسی (epic stories) شناخته میشوند و معمولاً برای تخمین بسیار بزرگ هستند. در واقع، این داستانها به چند داستان کوچکتر که قابل فهمتر و به آسانی قابل تخمین باشند، تجزیه میشوند. این بدان معناست که ایجاد یک داستان کاربر از تعداد انبوهی ویژگی موجب کاهش کارآیی خواهد شد.
تخمین در تیمی که افراد آن تاکنون با همدیگر سابقۀ همکاری نداشته باشند، خیلی پایین یا خیلی بالاست. اما با استمرار هر تکرار و تجربه و دانش بیشتر افراد، تخمین داستانها بهتر میشود.
استفاده از ابزار Planning Poker مزایای بسیاری دربردارد. دقت تخمین بالا میرود؛ زیرا مسأله از منظر تخصصهای گوناگون مورد بررسی قرار گرفته است. همچنین به تیم کمک میکند که هم رأی شوند و گفتگو میان اعضاء را تسهیل میکند. پس از آنکه داستانها تخمین زده شدند، مشتری و صاحب محصول با تیم توسعه در تولید چگونگی انتشار نسخهها، همکاری میکنند.
برنامه انتشار
اگرچه کدهای قابل ارسال، قابلیت انتشار در پایان هر تکرار را دارند، اما یک پروژه XP در چند سری منتشر شده است. یک نسخۀ منتشرشده، متشکل از تعداد مناسبی داستان برای عرضۀ ارزش کسب وکاری است که به کوچک نگه داشتن آن کمک میکند. بسیار مناسب است که یک موضوع یا هدف خاص را در ضمن هرنسخۀ انتشار، مد نظر قرار داد تا کمک کند که هر نسخۀ انتشار بر برخی ارزشهای کسب و کاری متمرکز شده و آن را هدایت کند. معمولاً یک نسخۀ انتشار، متشکل از چهار تکرار است؛ همانطور که در شکل 4-3 نشان داده شده است.
در برنامهریزی نسخههای انتشار، طول یک تکرار نیز تعیین میشود که معمولاً بین دو تا چهار هفته است. مطابق تجربه، اگر محیط کار شما دچار بینظمی و اختلالات دائمی است، میتوانید دورۀ تکرار را به یک هفته محدود کنید.
یکی از پروژههایی که ما بر روی آن کار میکردیم، برنامهای بود که نگهداری آن بسیار سخت و فوقالعاده ناپایدار بود. مشتری مکررا با تیم تماس گرفته و اشکالات بحرانساز و ایراداتی را که مخل برنامه بودند، گزارش میکرد. در ابتدای کار دوره، تکرار ما هفتگی بود. به همین دلیل چون حلقۀ بازخوردگیریمان کوچک بود، میتوانستیم بر پایدارسازی پروژه در هر دوره کاری تمرکز کنیم. هنگامی که محصول به پایداری مناسبتری رسید و تماسهای مشتری کم شد، قادر شدیم تا در هر دوره، دقت بیشتری بر روی مسائل به خرج دهیم.
اگر قصد دارید به صورت دقیق بر روی حلقۀ بازخورد متمرکز شوید، دورهی تکرار یک هفتهای، مدل خوبی است. اما این مدل سربار زیادی را به دلیل ضرورت تقسیم داستانهای کاربر باید به بخشهای کوچکتری تا آن اندازه که در یک دوره تکمیل شوند، بر پروژه تحمیل میکند. در ادامه خواهیم گفت که هر تکرار شامل برنامۀ ملاقات و بازبینی نیز هست.
بعد از مدتی که تیم با فرآیند کار آشناتر شد و نوبت به مشکلات با اولویت کمتر رسید، میتوان دورۀ تکرار را دو هفتهای در نظر گرفت. اما اگر پروژه به گونهای است که ویژگیهای بزرگتر را نمیتوان به موارد کوچکتری که قابل انجام در دورههای یک هفتهای باشد، تجزیه کرد و تیم هنوز در حال یادگیری است، دورههای بلندمدتتر قابل پذیرش است.
مشتری با توجه به طول دورۀ تکرار و بودجۀ داستان آغازین، انتخاب میکند که کدام داستان در هنگام انتشار نسخۀ اوّل، در تکرار اوّل کامل شود.
این مشتری است که داستانها را به گونهای اولویتبندی میکند تا مشخص شود که کدامیک بیشترین ارزش کسب و کار را فراهم میکند. از آنجایی که مشتری مسؤول داستانهای کاربر است، تیم باید به وی توضیح دهد که داستانهایی وجود دارند که صرفاً باید به جهت دلایل فنی ایجاد شوند.
معمولاً باید به داستانهای کاربریای که مستلزم ریسک بالا بوده یا دربرگیرندۀ مجهولات زیادی باشند، بیش از یک یا دو تکرار اختصاص داد.
برنامۀ تکرار
مشتری داستانهایی را که میخواهد در تکرار باشند، انتخاب میکند. برای هر داستان کاربر، مجموعهای از معیارهای پذیرش، تعریف شده است. همان طور که متوجه شدهاید ما در هر فاز، وقت بیشتر و بیشتری را صرف جمعآوری جزئیات هر داستان کاربر کرده و بصورت عمیقتری در آن غور میکنیم. این کار مفید است، زیرا اگر یک داستان کاربر ایجاد شده در ابتدای پروژه، ممکن است بعداً به عنوان داستانی کم اهمیت یا غیر مهم دیدهشود و بدون آنکه وقت خاصی برای آن صرف شده باشد، کنار گذاشته شود. اما اگر در ابتدای کار وقت زیادی صرف دقیقتر کردن داستانهای کاربر شود و بعداً بعضی از آنها کنار گذاشته شوند، در واقع وقت تلف شده است. بنابراین دقیقتر کردن یک داستان در جایی که مورد نیاز است، باید اتفاق بیفتد. در سطح برنامۀ تکرار، مجموعهای از معیارهای پذیرش را برای هر داستان کاربر تعریف میکنیم. معیار پذیرش به توسعهدهنده کمک میکند تا بداند که یک داستان کاربر به طور کامل انجام میشود. این معیارها به صورت مؤلفههایی از بافرض/هنگامی که/درنتیجه، نوشته میشود.
مثالهای زیر چگونگی انجام این کار را توصیف میکند:
عنوان ویژگی: افزودن کالایی به سبد
به عنوان یک مشتری میخواهم بتوانم کالایی را به سبدم اضافه کنم؛ به نحوی که قادر باشم به خرید خود ادامه دهم.
سناریو: سبد خالی
با فرض اینکه یک سبد خالی دارم، در نتیجه جمع تعداد کالایی که برای سفارش در سبد من وجود دارد، صفر است.
سناریو: افزودن یک کالا به سبد
با فرض اینکه یک سبد خالی دارم هنگامی که کالایی با شناسۀ 1 به سبدم اضافه میکنم، در نتیجه جمع کالاهای قابل سفارش در سبدم 1 میشود.
سناریو: افزودن کالاهایی به سبد
با فرض اینکه یک سبد خالی دارم، هنگامی که کالایی با شناسۀ 1 و کالایی با شناسۀ 2 به سبدم اضافه میکنم، در نتیجه جمع کالاهای قابل سفارش در سبدم 2 میشود.
سناریو: دو بار افزودن یک کالا
با فرض اینکه یک سبد خالی دارم هنگامی که کالایی با شناسۀ 1 به سبدم اضافه میکنم و هنگامی که کالایی با شناسۀ 1 را مجدداً به سبدم اضافه میکنم، در نتیجه تعداد کالاهای با شناسۀ 1 در سبد من باید 2 باشد.
سناریو: افزودن یک کالای تمام شده به سبد
با فرض اینکه یک سبد خالی دارم و کالایی با شناسۀ 2 در انبار وجود نداشته باشد، هنگامی که من کالایی با شناسۀ 2 را به سبد خودم اضافه میکنم، در نتیجه جمع تعداد کالای قابل سفارش در سبد من باید 0 باشد و به کاربر، موجود نبودن آن کالا را هشدار دهد.
یک آزمون پذیرش (acceptance) به زبان متعارف در قوانین کسب و کار نوشته میشود. در مثال سبد خرید، این سؤال پیش میآید که چگونه میتوان یک محصول را از سبد کالا، حذف کرد و اگر یک جنس اکنون در انبار نیست و کاربر پیام هشدار دریافت کرده است، در ادامه چه اتفاقی باید بیفتد؟ سناریوها به تیم در کشف ملزومات کسب و کار و تصریح آنها کمک میکند.
این سناریوها توسط توسعهدهنده به عنوان نقطۀ شروع آزمونهای واحد در توسعۀ آزمون محور و رفتار محور استفاده میشود. سناریوها همچنین در آزمودن معیارهای پذیرش به توسعهدهنده کمک کرده و توسعهدهنده و تستکننده را قادر میسازند که بر روی اتمام داستان اتفاق نظر داشته باشند.
بعد از آنکه سناریوهای معیار پذیرش تعیین شد، تیم توسعه، هر داستان را به تعدادی وظیفه تقسیم میکند و وظایف مرتبط به یک داستان، در تابلوی وظایف قرارگرفته و تیم توسعه تخمینهای خود را در قالب یکی از واحدهای اندازهگیری، مثلاً نفرساعت اعلام میکند. شکل 5-3 یک تابلوی وظیفه را نمایش میدهد.
به عنوان مثال وظایف میتوانند شامل ایجاد طرح یک بانک اطلاعاتی برای یک داستان یا یکپارچهسازی آن با بخشی موجود در سیستم باشند. وظایف شامل مؤلفههای فنی مانند تهیۀ گزارش از زیرسیستمها یا چارچوب مدیریت استثنائات نیز میباشد. اغلب اینگونه وظایف نادیدهگرفته میشود. یک داستان کاربر با وظایف گوناگونی گره خورده است. مثلاً:
داستان کاربر : به عنوان یک کاربر میخواهم بتوانیم یک کاربر را مدیریت کنم.
وظایف زیر از این داستان قابل استخراج است:
- طرحی برای بانک اطلاعات جهت ذخیرهسازی اطلاعات کاربر ایجاد کن.
- یک کلاس کاربر، برای مدیریت کاربر از درون برنامه ایجاد کن.
هر عضو تیم میتواند بر روی هر وظیفهای که بر روی تخته است، کار کند. هنگامیکه یک عضو گروه، وظیفهای را برمیدارد، باید نشانی از خود روی کارت آن وظیفه قراردهد ( مثلاً حروف اوّل اسمش) تا بقیۀ افراد بدانند که وی بر روی آن وظیفه، مشغول به کار است. معمولاً اما نه همیشه، یک توسعهدهنده همۀ وظایف مربوط به یک داستان را برمیدارد. این کار بدین معناست که آن توسعهدهنده با پشتیبانی تیم، مسؤول اتمام آن کار است.
در طول یک تکرار، هر روز باید گفتگوهایی سرپایی با حضور همۀ اعضای تیم انجام شود و مشکلاتی که ممکن است باعث به تأخیر افتادن ارائه کار شود، مورد بحث و بررسی قرار گیرد و همچنین تیم، لیست وظایف و تخته آن را بهروز کرده تا پیشرفت یا موانع آن به وضوح قابل رؤیت باشند.
با تشکر از آقای سید مجتبی حسینی
در نسخه 2.39 و نسخههای قبلتر از آن دو آسیبپذیری جدید پیدا شده است که منجر به integer overflow میشوند؛ اولی مربوط به git log --format است که حین استفاده از padding operatorها اگر آفست بزرگی پاس داده شود رخ خواهد داد. دومی هم مربوط به پارزر gitattribute است؛ که حین بارگذاری فایل از ایندکس اگر محتویات نامعتبری در آن باشد رخ خواهد داد. همچنین در Git GUI ویندوز نیز موقع clone کردن یک مخزن گیت یکسری post-processing بر روی branch دیفالتی که checkout میشود انجام خواهد شد به عنوان مثال یکی از این فازها spell-checker است؛ در حین انجام این پردازشها ممکن است یک مخزنی حاوی untrusted codeهایی باشد.
جزئیات هر کدام از این آسیبپذیریها را میتوانید در لینک مشاهده کنید؛ برای رفع این مشکل بهتر است ورژن Git خود را بروزرسانی کنید. در غیراینصورت باید حین کار با untrusted repositories از فلاگ --format و همچنین git archive استفاده نکنید. همچنین بهتر است از Git GUI برای کار با untrusted repositories استفاده نکنید.