Translate undoing section

Author: MSafariyan

book/02-git-basics/sections/undoing.asc

@@ -6,21 +6,25 @@
 توجه کنید، شما همین این برگشتها را نمی توانید دوباره برگشت کنید.
 اینجا یکی از معدود جاهایی است که اگر حواستان جمع نباشد امکان دارد داده ای از دست برود.
 
-One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message.
-If you want to redo that commit, make the additional changes you forgot, stage them, and commit again using the `--amend` option:
+یکی از متداول ترین بازگشت‌ها زمانی است که شما کامیتی خیلی زود انجام دادید و احتمالا اضافه کردن چند فایل‌ را فراموش کردید یا
+در پیام کامیتتان خطایی رخ داده باشد.
+اگر شما بخواهید کامیت را «ریدو» کنید، تغییرات اضافه فراموش شده را اعمال کنید، آنان را استیج کنید و دوباره با استفاده از آپشن
+`amend--` دوباره کامیت کنید:
 
 [source,console]
 ----
 $ git commit --amend
 ----
 
-This command takes your staging area and uses it for the commit.
-If you've made no changes since your last commit (for instance, you run this command immediately after your previous commit), then your snapshot will look exactly the same, and all you'll change is your commit message.
+این دستوری که انجام می‌دهید وارد منطقه استیج می‌شود و برای کامیت کردن استفاده می‌شود.
+اگه از اخرین کامیتتان هیچ تغییری ایجاد نکرده باشید(برای مثال، شما دستور را به محض انجام کامیت قبلی اجرا می‌کنید)، سپس اسنپ‌شات شما
+دقیقا به یک شکل است و  تمام چیزی که تغییر می‌کند فقط پیام کامیت شما است و نه چیز دیگری.
 
-The same commit-message editor fires up, but it already contains the message of your previous commit.
-You can edit the message the same as always, but it overwrites your previous commit.
+همان ویرایشگر پیام کامیت بالا می‌آید، اما در حال حاضر شما پیام کامیت قبلی است.
+شما می‌توانید پیام را مانند همیشه اصلاح کنید، اما این عمل بر روی کامیت قبلی بازنویسی می‌شود.
 
-As an example, if you commit and then realize you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this:
+برای مثال، اگر شما کامیت کنید و سپس متوجه شوید که چیزی را فراموش کردید و میخواستید آن را استیج کنید و به همین کامیت اضافه کنید،
+شما می‌توانید چنین کاری را انجام دهید:
 
 [source,console]
 ----
@@ -29,24 +33,28 @@ $ git add forgotten_file
 $ git commit --amend
 ----
 
-You end up with a single commit -- the second commit replaces the results of the first.
+در نهایت کار شما با یک کامیت به پایان می‌رسد -- کامیت دوم جایگزین نتایج کامیت اول می‌شود.
 
 [NOTE]
 ====
-It's important to understand that when you're amending your last commit, you're not so much fixing it as _replacing_ it entirely with a new, improved commit that pushes the old commit out of the way and puts the new commit in its place.
-Effectively, it's as if the previous commit never happened, and it won't show up in your repository history.
+خیلی مهم است که بدانید که وقتی درحال امند کردن اخرین کامیت هستید، درواقع شما آن را با استفاده عمل _جایگزین‌_ تعمیر نمی‌کنید بلکه
+یه ورودی جدید میسازید، کامیت بهبود یافته، کامیت قدیمی را کنار میزند و جایگزین آن می‌شود.
+همانطور که انتظار داشتیم، انگار قبلا هیچ کامیت غلطی وجود نداشته و هیچ وقت در تاریخچه‌ی مخزن شما نمایش داده نمی‌شود.
 
-The obvious value to amending commits is to make minor improvements to your last commit, without cluttering your repository history with commit messages of the form, ``Oops, forgot to add a file'' or ``Darn, fixing a typo in last commit''.
+فایده مشخص امند کردن کامیت‌ها این است که یک تغییر خیلی جزئی برای اخرید کامیت می‌سازید،‌ بدون ایجاد درهم ریختگی در تاریخچه‌ی مخزن شما
+ و جلوگیری از کامیت‌های با پیام‌های این‌چنینی، ``اوه، اضافه کردن یک فایل فراموش شده بود‍‍'' اصلاح یک غلط املایی در کامیت آخر''``.
 ====
 
 [[_unstaging]]
-==== Unstaging a Staged File
+==== آن‌استیج کردن یک فایل استیج شده
 
-The next two sections demonstrate how to work with your staging area and working directory changes.
-The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them.
-For example, let's say you've changed two files and want to commit them as two separate changes, but you accidentally type `git add *` and stage them both.
-How can you unstage one of the two?
-The `git status` command reminds you:
+دو قسمت بعدی درباره چگونگی کار با بخش استیج و تغیرات پوشه کاری توضیح می‌دهد.
+قسمت قشنگ است که شما دستوری که شما استفاده می‌کنید برای تعیین وضعیت آن دو بخش که بالا گفته شد همچنین یاد‌آوری می‌کند که چگونه
+تغییرات به عقب برگردانید.
+برای مثال، بیایید بگوییم شما دو فایل را تغییر داده بودید و مخوایید آن‌ها جدا از هم کامیت کنید، اما به کاملا تصادفی دستور `git add * `
+را وارد می‌کنید و هر دو آن‌ها استیج می‌شوند.
+چطور می‌توانید آن‌ها آن‌استیج کنید؟
+دستور `git status` به شما یادآوری می‌کند.
 
 [source,console]
 ----
@@ -60,8 +68,8 @@ Changes to be committed:
     modified:   CONTRIBUTING.md
 ----
 
-Right below the ``Changes to be committed'' text, it says use `git reset HEAD <file>...` to unstage.
-So, let's use that advice to unstage the `CONTRIBUTING.md` file:
+دقیقا بالای متن ``Changes to be comitted``، به شما گفته از `git reset HEAD <file> ...` برای آن‌استیج استفاده کنید.
+پس بایید به توصیه گیت گوش کنیم و فایل `CONTRIBURING.md` را آن‌استیج کنیم:
 
 [source,console]
 ----
@@ -82,24 +90,27 @@ Changes not staged for commit:
     modified:   CONTRIBUTING.md
 ----
 
-The command is a bit strange, but it works.
-The `CONTRIBUTING.md` file is modified but once again unstaged.
+دستور مقداری عجیب به نظر می‌رسد،‌ اما کار می‌کند.
+فایل `CONTRIBUTING.md` تغییر کرده است اما دوباره به حال آن‌استیج درآمده است.
 
 [NOTE]
 =====
-It's true that `git reset` can be a dangerous command, especially if you provide the `--hard` flag.
-However, in the scenario described above, the file in your working directory is not touched, so it's relatively safe.
+این درست که دستور `git reset` می‌تواند خطرناک باشد، مخصوصا اگر از فلگ `hard--` استفاده کرده باشید.
+با این حال، در این سناریو که بالا توضیح داده شد، فایل در پوشه کاری شما قرار دارد متاثر خطرات نمی‌شود، پس امن است.
 =====
 
-For now this magic invocation is all you need to know about the `git reset` command.
-We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <<ch07-git-tools#_git_reset>>.
+در حال حاضر این توضیحات جادویی تمام چیزی بود که شما لازم داشتید تا درباره دستور `git reset` بدانید.
+بعد تر در بخش <<ch07-git-tools#_git_reset>> با جزئیات بیشتری وارد بحث `reset` می‌شویم که چه کاری می‌کن
+د و چطور می‌توان در آن استاد شد تا چیزهای واقعا جالب‌تری انجام داد.
 
-==== Unmodifying a Modified File
 
-What if you realize that you don't want to keep your changes to the `CONTRIBUTING.md` file?
-How can you easily unmodify it -- revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)?
-Luckily, `git status` tells you how to do that, too.
-In the last example output, the unstaged area looks like this:
+==== بازگشت اصلاحات به قبل
+
+چه می‌شود اگر بفهمید دیگر نمی‌خواهید تغییر فایل `COUNTRIBUTING.md` حفظ کنید؟
+چطور می‌شود تغییرات را به حالت قبل برگرداند -- بازگرداندن آن به همان شکل که در آخرین کامیت شما بود
+(یا کلون شده بود، یا همانگونه که وارد پوشه کاری شما شده بود).
+خوش‌بختانه، `git status` این را نیز به شما می‌گوید که چگونه آن را انجام دهید.
+در خروجی آخرین مثال،  بخش آن‌استیج چیزی شبیه به این بود:
 
 [source,console]
 ----
@@ -110,8 +121,8 @@ Changes not staged for commit:
     modified:   CONTRIBUTING.md
 ----
 
-It tells you pretty explicitly how to discard the changes you've made.
-Let's do what it says:
+این به شما به زیبایی و صراحت می‌گوید که تغییرات انجام شده را چگونه از بین ببریم.
+بزارید کاری که گفته شده را انجام دهیم:
 
 [source,console]
 ----
@@ -125,17 +136,22 @@ Changes to be committed:
 
 ----
 
-You can see that the changes have been reverted.
+شما می‌‌توانید ببینید که تغییرات با حالت اول بازگشتند.
 
 [IMPORTANT]
 =====
-It's important to understand that `git checkout -- <file>` is a dangerous command.
-Any local changes you made to that file are gone -- Git just replaced that file with the most recently-committed version.
-Don't ever use this command unless you absolutely know that you don't want those unsaved local changes.
+خیلی مهم است بدانید که دستور `git checkout -- <file>` دستور خطرناکی است.
+هر تغییری که محلی باشد و کامیت نشده باشد از بین خواهد رفت -- گیت تغییرات فایل‌ها را با آخرین نسخه کامیت‌ شده باز میگرداند.
+از این دستور تا زمانی که نمی‌دانید دقیقا واقعا می‌دانید که به آن تغییرات نیاز ندارید انجام ندهید.
 =====
 
-If you would like to keep the changes you've made to that file but still need to get it out of the way for now, we'll go over stashing and branching in <<ch03-git-branching#ch03-git-branching>>; these are generally better ways to go.
+اگر مایل هستید تا تغییراتی که ایجاد کرده بودید را حفظ کنید اما در حال حاضر می‌خواید سر راهتان نباشند، شما باید از سراغ استش کردن و شاخه‌ها
+در بخش <<ch03-git-branching#ch03-git-branching>> بروید؛ به طور کلی این‌ها بهترین راه‌ها هستند.
+
+یادتان باشد، هرچیزی که در گیت _کامیت‌_ شده باشد می‌تواند تقریبا همیشه بازگردانی شود.
+حتی کامیت‌هایی که بر روی شاخه‌هایی که حذف شده بودند وجود داشتند یا کامیت‌هایی که با فلگ `amend--` بازنویسی شده‌ بودند می‌توانند بازگردانی شوند.
+
+
+( بخش <<ch10-git-internals#_data_recovery>> را برای بازگردانی اطلاعات ببینید ).
 
-Remember, anything that is _committed_ in Git can almost always be recovered.
-Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see <<ch10-git-internals#_data_recovery>> for data recovery).
-However, anything you lose that was never committed is likely never to be seen again.
+با این حال، هر چیزی که شما کامیت نکرده باشد و از دست دهید، انگار هیچ وقت آن‌ها را نساخته بودید.