در این مقاله با یکی از مهمترین ویژگیهای git یعنی بازیابی تغییرات فایلها، آشنا میشویم. اما در ابتدا نگاهی میکنیم به چگونگی ایجاد تغییر در آخرین commit:
تغییر آخرین commit:
در
git این امکان وجود دارد که آخرین فرمان commit با استفاده از اصلاحکننده
amend تغییر کند. علت تاکید بر روی آخرین دستور این است که git به دلیل
ساختاری که دارد نمیتواند commitهای قبل را تغییر دهد. اگر مقالات ابتدایی
آموزش git را مطالعه کرده باشید، به خاطر دارید که هر commit دارای یک کد
منحصر به فرد SHA-1 است، که این کد از هش کردن BLOBها به همراه خود مقادیر
commit یعنی مشخصات ایجاد کننده آن و از همه مهمتر SHA-1 پدر ایجاد میشود.
در نتیجه تغییر commitیی که نقش برگ را ندارد، یعنی در ساختار درختی git
دارای فرزند است، سبب میشود کد SHA-1 آن تغییر کند. این تغییر، commitهای فرزند را مجاب میکند برای حفظ صحت دادهها مقدار SHA-1 خود را تغییر دهند.
به این ترتیب این تغییرات در کل repository پخش خواهد شد. به همین دلیل git
جز آخرین commit امکان اصلاح دیگر commitها را نخواهد داد.
برای اصلاح آخرین commit کافی است دستور commit خود را با amend-- بیاورید
دستورات بازیابی فایل:
دستور checkout:
این فرمان یکی از مهمترین فرمانهای git است که دارای دو کاربرد است:
۱) بازیابی فایلی از repository و یا stage
۲) تغییر شاخه (این مورد را در مقالات مربوط به branch بررسی خواهیم کرد)
با
استفاده از این دستور میتوان فایلی را از repository به stage یا working
tree و یا هر دو بیاوریم. عملکرد این دستور با اصلاح کنندههای گوناگون
متفاوت خواهد بود. در ادامه روشهای مختلف فراخوانی این دستور و کاربرد هر
کدام آورده شده است:
در صورتی که بخواهیم فایلی را از محلی که head اکنون به آن اشاره میکند به working tree بیاوریم از دستور زیر استفاده میکنیم:
git checkout --[filename]
در حالت فوق فایل مستقیما به working tree آورده شده و در stage قرار نمیگیرد
تذکر:
-- در دستور بالا اختیاری بوده، اما استفاده از آن توصیه میشود. زیرا در
صورتیکه نام فایل به اشتباه وارد شود و یا فایل موجود نباشد، git اقدام به
تعویض شاخه میکند. زیرا همانطور که گفته شد، این دستور کاربرد دوگانه دارد.
در این حالت ممکن است به علت سهل انگاری مشکلاتی ایجاد شود علامت -- تاکید میکند که مقدار نوشته نام فایل است.
حال اگر بخواهیم فایلی را از commitهای قبل بازیابی کنیم، میتوانیم از دستور زیر استفاده کنیم:
git checkout [SHA-1] [filename]
در این حالت فایل هم در stage و هم در working tree قرار میگیرد.
دستور reset:
در
صورتیکه بخواهید تعداد زیادی فایل را به وضعیت مشخصی در زمان قبل
برگدانید، reset فرمان مناسبی خواهد بود. البته استفاده از این دستور باید با
احتیاط کامل صورت گیرد. زیرا در صورت اشتباه، این امکان وجود دارد که دیگر
نتوانید به بخشی از سوابق فایلهای خود دسترسی داشته باشید. بنابراین این
دستور همانقدر که کاربردی است، به همان اندازه نیز خطرناک است.
دستور reset را میتوان به ۳ صورت اجرا نمود:
۱) soft
۲) mixed (حالت پیشفرض)
۳) hard
۱)در
حالت soft تنها head به commit گفته شده منتقل میشود و working tree و
همچنین stage تغییری نمیکند. دقیقا مانند آنکه هد یک نوار خوان ویدئویی به
جای آنکه به آخرین محل ضبط اشاره کند، به عقب برگشته و به قسمتی در قبل
برود. در این حالت در صورتیکه دستور commit جدیدی ایجاد نشود که باعث پاک
شدن commitهای از آنجا به بعد شود، میتوان با اجرای مجدد دستور reset و اشاره
به آخرین commit، مجددا head را به سر جای اول برگرداند. البته توجه کنید در
صورتیکه در هنگام برگرداندن head به commitهای قبلی، فایلهایی تغییر کرده
باشند، آنها به صورت خودکار به stage اضافه میشوند.
۲) در حالت mixed
که پیش فرض این دستور نیز است، working tree بدون تغییر میماند. اما stage
تغییر کرده و دقیقا مانند وضعیت commit میشود.
۳) در این حالت هم
working tree و هم stage تغییر میکند و عینا وضعیت commitیی را میگیرند
که اکنون head به آن اشاره میکند. استفاده از این اصلاح کننده بسیار
خطرناکتر از موارد قبل است.
در هر یک از موارد فوق تا زمانیکه دستور
commit جدیدی را اجرا نکرده باشید، میتوانید به وضعیت قبل برگردید. اما اگر
commit جدید اجرا شود دیگر امکان بازگشت به commitهای صورت گرفته بعد از
آن وجود ندارد.
نکته مهم:
علیرغم
آنکه میتوان به commitهای گذشته در صورت عدم داشتن commit جدید مراجعه
کرد، اما یک اشکال فنی وجود دارد و آن این است که شما نمیتوانید SHA-1های آن commitها را با دستوراتی نظیر log ببینید. بنابراین بهتر است مقدار آنها
را قبل از اجرای دستور، ذخیره و تا اطمینان از وضعیت فعلی در محلی نگه دارید.
شکل زیر نمایانگر وضعیتهای مختلف دستور reset در هنگام بازگشت به سه commit قبل نسبت به وضعیت فعلی Head است:
Learn FULL STACK Web Development in 2 HOURS! ASP.NET & Angular
Timestamps:
00:00:00 Welcome to our 2 hour FULL STACK Course!
00:01:12 What you will learn during the next 2 hours
00:03:29 Day 1 Multi-Page and Single-Page Applications, TypeScript, and Angular Components
00:21:57 Day 2 One-Way Binding and Event Binding in Angular
00:34:23 Day 3 Our Flight Booking Portal and routing in Angular
00:44:52 Day 4 The 'Search Flight' page, Design a HTML page, install Font Awesome using Node, and TypeScript interfaces
01:27:00 Day 5 ASP.NET Core REST API, SWAGGER for documenting and testing our API
01:55:51 Thanks for watching!
Its value MUST be a number containing a NumericDate value.
A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the IEEE Std 1003.1, 2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in which each day is accounted for by exactly 86400 seconds, other than that non-integer values can be represented. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.
با آمدن Asp.Net Web API کار ساختن Web APIها برای برنامه نویسها به خصوص دسته ای که با ساخت API و
وب سرویس آشنا نبودند خیلی سادهتر شد . اگر با Asp.Net MVC آشنا باشید
خیلی سریع میتوانید اولین Web Service خودتان را بسازید .
در صفحه مربوط به Asp.Net Web API آمده است که این فریمورک بستر مناسبی برای ساخت و توسعه برنامه های RESTful است . اما تنها ساختن کنترلر و اکشن و برگشت دادن دادهها به سمت کلاینت ، به خودی خود برنامه شما رو تبدیل به یک RESTful API نمیکند .
مثل تمام مفاهیم و ابزارها ، طراحی و ساختن RESTful API هم دارای اصول و Best Practice هایی است که رعایت آنها به خصوص در این زمینه از اهمیت زیادی برخوردار است . همانطور که از تعریف API برمی آید شما در حال طراحی رابطی هستید تا به توسعه دهندگان دیگر امکان دهید از دادهها و یا خدمات شما در برنامهها و سرویس هایشان استفاده کنند . مانند APIهای توئیتر و نقشه گوگل که برنامههای زیادی بر مبنای آنها ساخته شده اند . در واقع توسعه دهندگان مشتریان API شما هستند .
بهره وری توسعه دهنده مهمترین اصل
اینطور میتوان نتیجه گرفت که اولین و
مهمترین اصل در طراحی API باید رضایت و موفقیت توسعه دهنده در درک و
یادگیری سریع API شما ،نه تنها با کمترین زحمت بلکه همراه با حس نشاط ، باشد. ( تجربه کاربری در اینجا هم میتواند صدق کند ). سعی کنید در زمان
انتخاب از بین روشهای طراحی موجود ، از دیدگاه توسعه دهنده به مسئله نگاه کنید .
خود را به جای او قرار دهید و تصور کنید که میخواهید با استفاده از API
موجود یک رابط کاربری طراحی کنید یا یک اپلیکشن برای موبایل بنویسید و اصل را این
نکته قرار دهید که بهره وری برنامه نویس را حداکثر کنید. ممکن است گاهی بین طرحی که بر اساس این اصل برای API خود در نظر داریم و یکی از اصول یا استانداردها تعارض بوجود بیاید . در این موارد بعد از اینکه مطمئن شدیم این اختلاف ناشی از طراحی و درک اشتباه خودمان نیست (که اکثرا هست ) ارجحیت را باید به طراحی بدهیم .
تهیه مستندات API
اگر برای پروژه وب سایتتان هیچ نوشته ای یا توضیحی ندارید ، جالب نیست اما خودتان ساختار برنامه خود را میشناسید و کار را پیش میبرید. اما توسعه دهنده ای که از API شما میخواهد استفاده کند و به احتمال زیاد شما را نمیشناسد ، عضو تیم شما هم نیست ، هیچ ایده ای درباره ساختار آن ، روش نامگذاری توابع و منابع، ساختار Urlها ، چگونگی و گامهای پروسه درخواست تا دریافت پاسخ ندارد ،و به مستندات شما وابسته است و تمام اینها باید در مستندات شما باشد. بیشتر توسعه دهندهها قبل از تست کردن API شما سری به مستندات میزنند ، دنبال نمونه کد آموزشی میگردند و در اینترنت درباره آن جستجو میکنند . ازینرو مستندات ( کارامد ) یک ضرورت است :
1- در مستندات باید هم درباره کلیت و هم در مورد تک تک توابع ( پارامترهای معتبر ، ساختار پاسخها و ... ) توضیحات وجود داشته باشد.
2- باید شامل مثالهایی از سیکل کامل درخواستها / پاسخها باشند .
3- تغییرات اعمال شده نسبت به نسخههای قبلی باید در مستندات بیان شوند .
4- (در وب ) یافتن و جستجو کردن در مستنداتی که به صورت فایل Pdf هستند یا برای دسترسی نیاز به Login داشته باشند سخت و آزاردهنده هستند.
5- کسی را داشته باشید تا با و بدون مستندات با API شما کار کند و از این روش برای تکمیل و اصلاح مستندات استفاده کنید.
رعایت نسخه بندی و حفظ نسخههای قبلی به صورت فعال برای مدت معین
یک API تقریبا هیچوقت کاملا پایدار نمیشود و اعمال تغییرات برای بهبود آن اجتناب ناپذیر هستند . مسئله مهم این است که چطور این تغییرات مدیریت شوند . مستند کردن تغییرات ، اعلام به موقع آنها و دادن یک بازه زمانی کافی برای ارتقا یافتن برنامه هایی که از نسخههای قدیمیتر استفاده میکنند نکات مهمی هستند . همیشه در کنار نسخه بروز و اصلی یک یا دو نسخه ( بسته به API و کلاینتهای آن ) قدیمیتر را برای زمان مشخصی در حالت سرویس دهی داشته باشید .
داشتن یک روش مناسب برای اعلام تغییرات و ارائه مستندات و البته دریافت بازخورد از استفاده کنندگان
تعامل با کاربران برنامه باید از کانالهای مختلف وجود داشته باشد .از وبلاگ ، Mailing List ، Google Groups و دیگر ابزارهایی که در اینترنت وجود دارند برای انتشار مستندات ، اعلام بروزرسانیها ، قرار دادن مقالات و نمونه کدهای آموزشی ، پرسش و پاسخ با کاربران استفاده کنید .
مدیریت خطاها به شکل صحیح که به توسعه دهنده در آزمودن برنامه اش کمک کند.
از منظر برنامه نویسی که از API شما استفاده میکند هرآنچه در آنسوی API اتفاق میافتد یک جعبه سیاه است . به همین جهت خطاهای API شما ابزار کلیدی برای او هستند که خطایابی و اصلاح برنامه در حال توسعه اش را ممکن میکنند . علاوه بر این ، زمانی که برنامه نوشته شده با API شما مورد استفاده کاربر نهایی قرار گرفت ، خطاهای به دقت طراحی شده API شما کمک بزرگی برای توسعه دهنده در عیب یابی هستند .
1- از Status Code های HTTP استفاده کنید و سعی کنید تا حد ممکن آنها را نزدیک به مفهوم استانداردشان بکار ببرید .
2- خطا و علت آن را به زبان روشن توضیح دهید و در توضیح خساست به خرج ندهید .
3- در صورت امکان لینکی به یک صفحه وب که حاوی توضیحات بیشتری است را در خطا بگنجانید .
رعایت ثبات و یکدستی در تمام بخشهای طراحی که توانایی پیش بینی توسعه دهنده را در استفاده از API افزایش میدهد .
داشتن مستندات لازم است اما این بدین معنی نیست که خود API نباید خوانا و قابل پیش بینی باشد . از هر روش و تکنیکی که استفاده میکنید آن را در تمام پروژه حفظ کنید . نامگذاری توابع/منابع ، ساختار پاسخها ، Urlها ، نقش و عملیاتی که HTTP methodها در API شما انجام میدهند باید ثبات داشته باشند . از این طریق توسعه دهنده لازم نیست برای هر بخشی از API شما به سراغ فایلها راهنما برود . و به سرعت کار خود را به پیش میبرد .
انعطاف پذیر بودن API
API توسط کلاینتهای مختلفی و برای افراد مختلفی مورد استفاده قرار میگیرد که لزوما همهی آنها ساختار یکسانی ندارند و API شما باید تا جای ممکن بتواند همه آنها را پوشش دهد . محدود بودن فرمت پاسخ ، ثابت بودن فیلدهای ارسالی به کلاینت ، ندادن امکان صفحه بندی ، مرتب سازی و جستجو در دادهها به کلاینت ، داشتن تنها یک نوع احراز هویت ، وابسته بودن به کوکی و ... از مشخصات یک API منجمد و انعطاف ناپذیر هستند .
اینها اصولی کلی بودند که بسیاری از آنها مختص طراحی API نیستند و در تمام حوزهها قابل استفاده بوده ، جز الزامات هستند . در قسمتهای بعدی نکات اختصاصیتری را بررسی خواهیم کرد .
public SettingsController(ISettings settings) { // example of saving _settings.General.SiteName = "دات نت تیپس"; _settings.Seo.HomeMetaTitle = ".Net Tips"; _settings.Seo.HomeMetaKeywords = "َAsp.net MVC,Entity Framework,Reflection"; _settings.Seo.HomeMetaDescription = "ذخیره تنظیمات برنامه"; _settings.Save(); }
- تنظیمات به صورت گروه بندی شده در کنار هم قرار گرفتهاند و یافتن تنظیمات برای زمانی که نیاز به دسترسی به آنها داریم، راحتتر و سادهتر خواهد بود.
- به این شکل تنظیمات قابل دسترس در یک گروه، از دیتابیس بازیابی خواهند شد.
اصلا چرا باید این تنظیمات را در دیتابیس ذخیره کنیم؟
- ساخت یک Asp.net Web Application
- ساخت مدل Setting و افزودن آن به کانتکست Entity Framework
- ساخت کلاس SettingBase برای بازیابی و ذخیره سازی تنظیمات با رفلکشن
- ساخت کلاس GenralSettins و SeoSettings که از کلاس SettingBase ارث بری کردهاند.
- ساخت کلاس Settings به منظور مدیریت تمام انواع تنظیمات
namespace DynamicSettingAPI.Models { public interface IUnitOfWork { DbSet<Setting> Settings { get; set; } int SaveChanges(); } } public class ApplicationDbContext : IdentityDbContext<ApplicationUser>,IUnitOfWork { public DbSet<Setting> Settings { get; set; } public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false) { } public static ApplicationDbContext Create() { return new ApplicationDbContext(); } } namespace DynamicSettingAPI.Models { public class Setting { public string Name { get; set; } public string Type { get; set; } public string Value { get; set; } } }
protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Entity<Setting>() .HasKey(x => new { x.Name, x.Type }); modelBuilder.Entity<Setting>() .Property(x => x.Value) .IsOptional(); base.OnModelCreating(modelBuilder); }
namespace DynamicSettingAPI.Service { public abstract class SettingsBase { //1 private readonly string _name; private readonly PropertyInfo[] _properties; protected SettingsBase() { //2 var type = GetType(); _name = type.Name; _properties = type.GetProperties(); } public virtual void Load(IUnitOfWork unitOfWork) { //3 get setting for this type name var settings = unitOfWork.Settings.Where(w => w.Type == _name).ToList(); foreach (var propertyInfo in _properties) { //get the setting from setting list var setting = settings.SingleOrDefault(s => s.Name == propertyInfo.Name); if (setting != null) { //4 set propertyInfo.SetValue(this, Convert.ChangeType(setting.Value, propertyInfo.PropertyType)); } } } public virtual void Save(IUnitOfWork unitOfWork) { //5 get all setting for this type name var settings = unitOfWork.Settings.Where(w => w.Type == _name).ToList(); foreach (var propertyInfo in _properties) { var propertyValue = propertyInfo.GetValue(this, null); var value = (propertyValue == null) ? null : propertyValue.ToString(); var setting = settings.SingleOrDefault(s => s.Name == propertyInfo.Name); if (setting != null) { // 6 update existing value setting.Value = value; } else { // 7 create new setting var newSetting = new Setting() { Name = propertyInfo.Name, Type = _name, Value = value, }; unitOfWork.Settings.Add(newSetting); } } } } }
propertyInfo.SetValue(this, Convert.ChangeType(setting.Value, propertyInfo.PropertyType));
public class GeneralSettings : SettingsBase { public string SiteName { get; set; } public string AdminEmail { get; set; } public bool RegisterUsersEnabled { get; set; } } public class GeneralSettings : SettingsBase { public string SiteName { get; set; } public string AdminEmail { get; set; } }
public interface ISettings { GeneralSettings General { get; } SeoSettings Seo { get; } void Save(); } public class Settings : ISettings { // 1 private readonly Lazy<GeneralSettings> _generalSettings; // 2 public GeneralSettings General { get { return _generalSettings.Value; } } private readonly Lazy<SeoSettings> _seoSettings; public SeoSettings Seo { get { return _seoSettings.Value; } } private readonly IUnitOfWork _unitOfWork; public Settings(IUnitOfWork unitOfWork) { _unitOfWork = unitOfWork; // 3 _generalSettings = new Lazy<GeneralSettings>(CreateSettings<GeneralSettings>); _seoSettings = new Lazy<SeoSettings>(CreateSettings<SeoSettings>); } public void Save() { // only save changes to settings that have been loaded if (_generalSettings.IsValueCreated) _generalSettings.Value.Save(_unitOfWork); if (_seoSettings.IsValueCreated) _seoSettings.Value.Save(_unitOfWork); _unitOfWork.SaveChanges(); } // 4 private T CreateSettings<T>() where T : SettingsBase, new() { var settings = new T(); settings.Load(_unitOfWork); return settings; } }
private readonly ICache _cache; public Settings(IUnitOfWork unitOfWork, ICache cache) { // ARGUMENT CHECKING SKIPPED FOR BREVITY _unitOfWork = unitOfWork; _cache = cache; _generalSettings = new Lazy<GeneralSettings>(CreateSettingsWithCache<GeneralSettings>); _seoSettings = new Lazy<SeoSettings>(CreateSettingsWithCache<SeoSettings>); } private T CreateSettingsWithCache<T>() where T : SettingsBase, new() { // this is where you would implement loading from ICache throw new NotImplementedException(); }
public ActionResult Index() { using (var uow = new ApplicationDbContext()) { var _settings = new Settings(uow); _settings.General.SiteName = "دات نت تیپس"; _settings.General.AdminEmail = "admin@gmail.com"; _settings.General.RegisterUsersEnabled = true; _settings.Seo.HomeMetaTitle = ".Net Tips"; _settings.Seo.MetaKeywords = "Asp.net MVC,Entity Framework,Reflection"; _settings.Seo.HomeMetaDescription = "ذخیره تنظیمات برنامه"; var settings2 = new Settings(uow); var output = string.Format("SiteName: {0} HomeMetaDescription: {1} MetaKeywords: {2} MetaTitle: {3} RegisterEnable: {4}", settings2.General.SiteName, settings2.Seo.HomeMetaDescription, settings2.Seo.MetaKeywords, settings2.Seo.HomeMetaTitle, settings2.General.RegisterUsersEnabled.ToString() ); return Content(output); } }
کامپایلر مبتنی بر LLVM برای دات نت
مایکروسافت تصمیم گرفتهاست تا CoreCLR را بر اساس کامپایلر LLVM طراحی کند تا بر روی تمام سکوهای کاری که LLVM اجرا میشود قابل کامپایل باشد.