diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 60bfec591..9ce3f1a14 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,26 +1,27 @@ -=== Recording Changes to the Repository +=== ثبت تغییرات یک مخزن +در این بخش، شما باید یک مخزن واقعی گیت بر روی سیستم لوکال داشته باشید و یک چک‌اوت یا ـ‌کپی کاری‌ـ تمام فایل‌های موجود مقابل شما باشد. +معمولا شما می‌خواهید شروع به تغییر دادن کنید و اسنپ‌شات‌ها را در مخزن کامیت کنید، +هر بار که پروژه به وضعتی رسید که شما می‌خواهید آن را ثبت کنید. -At this point, you should have a _bona fide_ Git repository on your local machine, and a checkout or _working copy_ of all of its files in front of you. -Typically, you'll want to start making changes and committing snapshots of those changes into your repository each time the project reaches a state you want to record. +یادتون باشه که هر فایلی در پوشه کاری شما به طور کلی دو وضعیت دارد: _tracked(دنبال شده/ترکت)ـ یا _untracked(دنبال نشده/آن‌ترکت). +ترکت فایلی هستید که در اخرین اسنپ‌شات شما بوده‌اند؛ آن‌ها می‌توانند وضعتی مثل ـ‌unmodified(تغییر نکرده/آن‌مودیفاید)ـ، +ـmodified(تغییر کرده/مودی‌فاید)ـ، یا _staged(ظاهر شده/استیجد)_ داشته باشند. +به طور خلاصه، ترکت فایل‌ها آنهایی هستند که گیت آن‌ها را می‌شناسد. -Remember that each file in your working directory can be in one of two states: _tracked_ or _untracked_. -Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. -In short, tracked files are files that Git knows about. +آن‌ترکت فایل‌ها بقیه هستند -- هر فایلی در اسنپ‌شات آخر شما نبوده باشد و شما را آن را ـadd(همان عمل استیج است/اَد)ـ نکرده باشید. +وقتی اول مخزنی را کلون می‌کنید، همه‌ی فایل‌ها ترکت شده و آن‌مودیفاید هستند زیرا گیت قبلا بررسی کرده است و هنوز شما تغییراتی را +اعمال نکرده‌اید. +به محض تغییر فایل‌ها، گیت وضعیت‌ آن‌ها را به مودیفاید تغییر می‌دهد، چون شما آن را نسبت به کامیت آخر تغییر داده‌اید. +همانطور که کار می‌کنید، شما فایل‌های مودیفاید شده را انتخاب و اَد می‌کنید و سپس همه‌ی آن را کامیت می‌کنید، و این چرخه ادامه دارد. -Untracked files are everything else -- any files in your working directory that were not in your last snapshot and are not in your staging area. -When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven't edited anything. -As you edit files, Git sees them as modified, because you've changed them since your last commit. -As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats. - -.The lifecycle of the status of your files. -image::images/lifecycle.png[The lifecycle of the status of your files.] +چرخه عمر وضعیت فایل‌های شما +image::images/lifecycle.png[چرخه عمر وضعیت یک فایل] [[_checking_status]] -==== Checking the Status of Your Files - -The main tool you use to determine which files are in which state is the `git status` command.(((git commands, status))) -If you run this command directly after a clone, you should see something like this: +==== بررسی وضعیت فایل‌ها +ابزار اصلی‌ای که شما برای تعیین وضعیت فایل‌ها استفاده می‌کنید، دستور `git status` است. (((git commands, status))) +اگر شما دستور را مستقیماً بعد از کلون اجرا کنید،‌ چیزی شبیه به این خواهی دید: [source,console] ---- @@ -29,15 +30,14 @@ On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean ---- +این بدین معنی است که پوشه کاری شما تمیز است -- به زبان دیگر، هیچ کدام از فایل‌های ترکت شده تغییر داده نشده یا وضعیت مودیفاید ندارند. +همچنین گیت هیچ فایل دنبال نشده یا آن‌ترکت را نمی‌بینید. +در آخر، این دستور به شما می‌گوید که بر روی کدام برنچ هستید و شما از اختلافات بین برنچ شما و برنچ روی سرور مطلع می‌سازد. +فعلا، آن برنچ همیشه ``master`` است که به صورت پیش فرض ساخته شده؛ نگران نباشید در بخشی <<_git_branching>> درباره این موضوع +با جزئیات بحث خواهد شد. +بیایید یه فایل جدید به پروژه اضافه کنیم، یک فایل `README` ساده. +اگر از قبل وجود نداشته باشد، می‌توانید با اجرای دستور `git status` ببنید که فایل به وضعیت آن‌ترکت درآمده است: -This means you have a clean working directory; in other words, none of your tracked files are modified. -Git also doesn't see any untracked files, or they would be listed here. -Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server. -For now, that branch is always `master`, which is the default; you won't worry about it here. -<> will go over branches and references in detail. - -Let's say you add a new file to your project, a simple `README` file. -If the file didn't exist before, and you run `git status`, you see your untracked file like so: [source,console] ---- @@ -52,24 +52,25 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- +می‌توانید فایل `README` جدید که ساختید را در حالت آن‌ترکت ببینید، چون خروجی وضعیت فایل در زیر تیتر ``Untracked files`` است. +آن‌ترکت به طوری کلی به این معنی است که گیت آن را در آخرین اسنپ‌شات(کامیت) ندیده است. +گیت به هیچ عنوان آن را در اسنپ‌شات‌های(کامیت‌ها) بعدی ثبت نمی‌کند تا زمانی که شما آن را اَد کنید و به روی استیج بیارید و کامیت کنید. +پس گیت به این صورت کار میکنه در نتیجه شما‌ نمی‌توانید به صورت تصادفی شروع به اضافه کردن فایلی دودویی در یک فایل دیگر کنید که +منظورتان آن فایل نبوده است. +خب شما می‌خواهید شروع به اضافه کردن فایل `README` کنید، پس بیایید به گیت این موضوع را اعلام کنیم و آن را به حالت `tracked` +در بیاوریم. -You can see that your new `README` file is untracked, because it's under the ``Untracked files'' heading in your status output. -Untracked basically means that Git sees a file you didn't have in the previous snapshot (commit); Git won't start including it in your commit snapshots until you explicitly tell it to do so. -It does this so you don't accidentally begin including generated binary files or other files that you did not mean to include. -You do want to start including `README`, so let's start tracking the file. - -[[_tracking_files]] -==== Tracking New Files - -In order to begin tracking a new file, you use the command `git add`.(((git commands, add))) -To begin tracking the `README` file, you can run this: +[[_tracking_files]]‍ +==== دنبال کردن یک فایل جدید +به این ترتیب برای قرار دادن یک فایل در حالت tracked و اینکه گیت بتواند آن را در اسنپ‌شات‌ها بعدی را شامل کند باید از دستور +`git add` استفاده کنید.(((git commands, add))) +برای اضافه کردن فایل `README`، باید دستور زیر را وارد کنید: [source,console] ---- $ git add README ---- - -If you run your status command again, you can see that your `README` file is now tracked and staged to be committed: +اگر دستور `git status` را وارد کنید، می‌توانید ببیند فایل `README` حالا در حال ترکت و استیج شده و فعل کامیت است: [source,console] ---- @@ -83,15 +84,16 @@ Changes to be committed: ---- -You can tell that it's staged because it's under the ``Changes to be committed'' heading. -If you commit at this point, the version of the file at the time you ran `git add` is what will be in the subsequent historical snapshot. -You may recall that when you ran `git init` earlier, you then ran `git add ` -- that was to begin tracking files in your directory.(((git commands, init)))(((git commands, add))) -The `git add` command takes a path name for either a file or a directory; if it's a directory, the command adds all the files in that directory recursively. +به این وضعیت، اصطلاحا استیج می‌گویند چون فایل در زیر تیتر ``Changes to be committed`` و منتظر انجام فعل کامیت است. +شما احتمالا زمانی که دستور `git init` را اجرا کرده بودید نیز یکبار دستور `git add {files}` را نیز اجرا کرده باشید-- آن دستور +برای مورد دنبال قرار گرفتن فایل‌ها در درون پوشه بود.(((git commands, init)))(((git commands, add))) +دستور `git add` یا نام یک فایل را اضافه می‌کند یا نام یک پوشه را؛ اگر یک پوشه باشد، دستور به صورت بازگشتی تمامی فایل‌های و زیرپوشه‌ها +را اضافه می‌کند. -==== Staging Modified Files - -Let's change a file that was already tracked. -If you change a previously tracked file called `CONTRIBUTING.md` and then run your `git status` command again, you get something that looks like this: +==== اضافه کردن فایل‌های تغییر یافته +حالا بیایید فایلی که در حال حاضر ترکت شده را تغییر دهیم. +اگر فایل قبلی که اضافه کردیم به نام `CONTRIBUTING.md` تغییر دهیم و دوباره دستور `git status` را اجرا کنیم، +چیزی شبیه به نتیجه زیر را می‌بینید: [source,console] ---- @@ -111,11 +113,11 @@ Changes not staged for commit: ---- -The `CONTRIBUTING.md` file appears under a section named ``Changes not staged for commit'' -- which means that a file that is tracked has been modified in the working directory but not yet staged. -To stage it, you run the `git add` command. -`git add` is a multipurpose command -- you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. -It may be helpful to think of it more as ``add precisely this content to the next commit'' rather than ``add this file to the project''.(((git commands, add))) -Let's run `git add` now to stage the `CONTRIBUTING.md` file, and then run `git status` again: +فایل `CONTROBUTING.md` در زیر بخشی به نام ``Changes not staged for commit`` ظاهر خواهد شد -- به معنی است که یک فایلی +دچار تغییر شده بود حالا ترکت شده اما هنوز آن را استیجد نکرده‌ایم، برای انجام استیج می‌بایست دستور `git add` را اجرا کنیم. +دستور `git add` چند منظوره است -- برای ترک کردن فایل‌های جدید، برای استیج کردن فایل‌های تغییر یافته و برای انجام دیگر کارها +مثل مشخص کردن مرج-کانفلیکت‌ فایل‌ها به عنوان کاری که انجام شده. +بیایید دستور `git add` را اجرا کنیم تا فایل `CONTRIBUTING.md` را استیج کنیم، و بعد دستور `git status` را دوباره وارد کنیم. [source,console] ---- @@ -131,10 +133,10 @@ Changes to be committed: ---- -Both files are staged and will go into your next commit. -At this point, suppose you remember one little change that you want to make in `CONTRIBUTING.md` before you commit it. -You open it again and make that change, and you're ready to commit. -However, let's run `git status` one more time: +هر دو فایل استیج شده‌اند و به کامیت بعدی شما اضافه خواهند شد. +در این لحظه، فرض کنید که یادتان می‌یاد یک تغییر کوچک دیگر در فایل `CONTRIBUTING.md` می‌خواهید انجام دهید، قبل از اینکه کامیت کنید. +فایل را دوباهر باز می‌کنید و تغییرات را اعمال می‌کنید، حالا اماده کامیت است. +حالا، بیایید دوباره دستور `git status` را اجرا کنیم: [source,console] ---- @@ -156,12 +158,13 @@ Changes not staged for commit: ---- -What the heck? -Now `CONTRIBUTING.md` is listed as both staged _and_ unstaged. -How is that possible? -It turns out that Git stages a file exactly as it is when you run the `git add` command. -If you commit now, the version of `CONTRIBUTING.md` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. -If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file: +چطور ممکنه؟!!! +فایل `CONTRIBUTING.md` هم به عنوان فایلی استیج شده و ـ‌همچنین‌ـ استیج نشده لیست شده است. +چطور امکان دارد؟ +خب این موضوع بر‌میگردد به گیت، وقتی دستور `git add` را اجرا می‌کنید و فایلی را استیج می‌کنید، گیت دقیقا همان تغییرات آماده کامیت می‌کند +و شما اگر واقعا کامیت کنید، نسخه‌ای جدید از فایل پروژه ایجاد خواهد شد و وقتی که قبل از کامیت دوباره تغییر بدید درحالی که آن را یکبار +استیج کرده‌اید؛ گیت تغییرات جدیدی را ثبت می‌کند و به شما می‌گوید تغییرات جدید را در کامیت جاری اعمال نمی‌کند مگر اینکه دوباره آن را +استیج کنید. [source,console] ---- @@ -176,11 +179,11 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -==== Short Status +==== وضعیت‌های کوتاه -While the `git status` output is pretty comprehensive, it's also quite wordy. -Git also has a short status flag so you can see your changes in a more compact way. -If you run `git status -s` or `git status --short` you get a far more simplified output from the command: +خروجی `git status` خیلی توصیفی و لغوی است؛ در حالی که گیت دارای یه سری اعلام‌ وضعیت‌های کوتاه نیز می‌باشد، که می‌توانید وضعیت تغییرات +را خیلی کوتاه و خلاصه‌تر ببینید. +اگر دستور `git status -s` یا `git status --short` را وارد کنید، یک خروجی بسیار ساده شده به شما خواهد داد: [source,console] ---- @@ -192,18 +195,21 @@ M lib/simplegit.rb ?? LICENSE.txt ---- -New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on. -There are two columns to the output -- the left-hand column indicates the status of the staging area and the right-hand column indicates the status of the working tree. -So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged. -The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged. +فایل‌های جدیدی که هنوز ترکت نشده‌اند علامت `??` مقابل آنان است، فایل‌های جدیدی که استیج شده‌اند علامت `A` دارند، +فایل‌های تغییر یافته علامت `M` دارند و بقیه نیز به همین ترتیب. +خروجی حروفی که می‌بینید عملا دو ستون است، ستون سمت چپ نشان‌دهنده وضعیت استیج است و ستون سمت راست نشان‌دهنده وضعیت درخت کاری است. +برای مثال-- در خروجی بالا، فایل `README` در پوشه کاری تغییر یافته است اما هنوز آن را استیج نکرده‌اند، +در حالی که فایل `lib/simplegit.rb` تغییر یافته و استیج شده است. +فایل `Rakefile` تغییر یافته و استیج شده بود و بعد دوباره به حالت تغییر یافته درآمده، به همین دلیل هر دو ستون آن پر است و `MM` یعنی +استیج شده و استیج نشده. [[_ignoring]] -==== Ignoring Files +==== نادیده گرفتن فایل‌ها -Often, you'll have a class of files that you don't want Git to automatically add or even show you as being untracked. -These are generally automatically generated files such as log files or files produced by your build system. -In such cases, you can create a file listing patterns to match them named `.gitignore`.(((ignoring files))) -Here is an example `.gitignore` file: +گاهی مجموعه‌ای از فایل‌ها هستند که ما نمی‌خواهیم گیت به صورت خودکار آن `add` یا آن‌ها را دنبال کند. +به صورت کلی فایل‌هایی وجود دارد که به صورت اتوماتیک ساخته می‌شود مثل لاگ فایل‌ها و... +در این گونه موارد، می‌توانید لیستی از نام فایل‌ها بسازید و آن‌ها در فایلی به نام `gitingore.` قرار بدید؛ +در اینجا مثالی برای فایل `gitignore.` داریم: [source,console] ---- @@ -212,24 +218,28 @@ $ cat .gitignore *~ ---- -The first line tells Git to ignore any files ending in ``.o'' or ``.a'' -- object and archive files that may be the product of building your code. -The second line tells Git to ignore all files whose names end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. -You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. -Setting up a `.gitignore` file for your new repository before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository. +خط اول به گیت می‌گوید که هر فایلی که با ``o.`` یا ``a.`` تمام ‌می‌شود را نادیده بگیرد. +خط دوم به گیت می‌گوید که همه‌ی فایل‌های که نام‌شان با علامت تیلد(`~`) است ناده بگیرد، از این علامت اکثر ویرایشگران متن مثل +ایمکس استفاده می‌کنند تا فایل‌های موقت خود را ذخیره کنند. +شاید شما پوشه‌های tmp, log , pid را هم اضافه کنید؛ یاد گرفتن کار با فایل `gitignore.` ضروری است، چرا باید فایلی را کامیت کنید +که نمی‌خواهید واقعا در مخزن شما وجود داشته باشد. -The rules for the patterns you can put in the `.gitignore` file are as follows: +قوانین و الگو‌هایی که می‌توانید در فایل `gitignore.` قرار بدید تا فایل مورد نظر شما در کامیت‌های بعدی حضور نداشته باشد. -* Blank lines or lines starting with `#` are ignored. -* Standard glob patterns work, and will be applied recursively throughout the entire working tree. -* You can start patterns with a forward slash (`/`) to avoid recursivity. -* You can end patterns with a forward slash (`/`) to specify a directory. -* You can negate a pattern by starting it with an exclamation point (`!`). +* خط‌هایی که با `#` شروع شوند نادیده گرفته می‌شوند. +* الگو‌‌های استاندارد کار می‌کنند و به صورت بازگشتی بر روی درخت کاری شما تاثیر می‌گذارند. +* می‌توانید الگو‌ها را با علامت اسلش رو به جلو (`/`) از حالت بازگشتی خارج کنید. +* می‌توانید از اسلش رو به جلو (`/`) پوشه‌ای مشخص را تعیین کنید. +* می‌توانید با اضافه کردن علامت تعجب (`!`) منظور جمله را برعکس کنید. -Glob patterns are like simplified regular expressions that shells use. -An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen (`[0-9]`) matches any character between them (in this case 0 through 9). -You can also use two asterisks to match nested directories; `a/**/z` would match `a/z`, `a/b/z`, `a/b/c/z`, and so on. +الگو‌های استاندارد که می‌توان استفاده که به سادگی با کد‌‌های Regex(Regural expretions) نوشته می‌شود که شل هم استفاده می‌کند. +علامت ستاره (`*`) یک یا چند کارکتر را پیدا می‌کند؛ `[abc]` هر حرفی که داخل براکت(`[]`) باشد را پیدا می‌کند( در این مورد + a, b ,c هستند). علامت سوال (`?`) یک کارکتر را پیدا می‌کند و علامت براکت به همراه دو کارکتر که با `-` از هم جدا شده باشند، + آنهایی که در آن مجموعه وجود داشته باشند را پیدا می‌کند(`[9-0]` در این مورد هر عددی که بین ۰ تا ۹ باشد). +و همچنین می‌توانید از دو ستاره `**` برای پیدا کردن پوشه‌های تو در تو استفاده کنید به این صورت `a/**/z` که نتیجه‌ی آن می‌تواند +`a/z`, `a/b/z`, `a/b/c/z`, و به همین ترتیب باشد. -Here is another example `.gitignore` file: +در این مثال دیگری برای فایل `gitignore.`داریم: [source] ---- @@ -254,29 +264,34 @@ doc/**/*.pdf [TIP] ==== -GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[] if you want a starting point for your project. +در صفحه گیت‌هاب لیست قابل ملاحظه‌ای برای فایل `gitignore.` فراهم شده است که مملوع از مثال‌های مختلف برای زبان‌ها و شرایط مختلف است. +https://github.com/github/gitignore[] ==== [NOTE] ==== -In the simple case, a repository might have a single `.gitignore` file in its root directory, which applies recursively to the entire repository. -However, it is also possible to have additional `.gitignore` files in subdirectories. -The rules in these nested `.gitignore` files apply only to the files under the directory where they are located. -(The Linux kernel source repository has 206 `.gitignore` files.) - -It is beyond the scope of this book to get into the details of multiple `.gitignore` files; see `man gitignore` for the details. +در یک مورد ساده، یک مخزن شاید یک فایل `gitignore.` در پوشه اصلی داشته باشد، که به صورت بازگشتی تمام موجودیت‌های پروژه را شامل می‌شود. +با این حال، این امکان وجود دارد که در زیر پوشه‌های خود باز هم فایل `gitignore.` داشته باشد. +قوانین و الگوها در این فایل‌های `gitignore.` تو در تو فقط موجودیت‌های زیرپوشه‌‌های خود را نادیده می‌گیرند. +(مخزن اصلی سورس هسته لیوکس در فایل `gitignore.` خود ۲۰۶ فایل را نادیده می‌گیرد.) +این موضوع فراتر از بخش این کتاب است که درباره جزئیات چندین فایل `gitignore.` بگوییم. +اگر به دنبال جزئیات بیشتری هستید دستور `man gitignore` را در ترمینال وارد کنید. ==== [[_git_diff_staged]] -==== Viewing Your Staged and Unstaged Changes +==== نمایش وضعیت استیج شده‌ها و تغییرات استیج نشده + +اگر دستور `git status` کمی برایتان مبهم است -- میخواهید بفهمید دقیقا چه چیزی را تغییر داده‌اید!، نه فقط چه فایل‌هایی تغییر کرده است +(منظور جزئیات بیشتر در تغییرات اعمال شده است) -- می‌توانید از دستور `git diff` استفاده کنید.(((git commands, diff))) +درباره دستور `git diff` و جزئیات آن بعد می‌گوییم، اما احتما شما از این دستور برای پاسخ به دو سوال استفاده کنید: -If the `git status` command is too vague for you -- you want to know exactly what you changed, not just which files were changed -- you can use the `git diff` command.(((git commands, diff))) -We'll cover `git diff` in more detail later, but you'll probably use it most often to answer these two questions: What have you changed but not yet staged? -And what have you staged that you are about to commit? -Although `git status` answers those questions very generally by listing the file names, `git diff` shows you the exact lines added and removed -- the patch, as it were. +چه چیزی تغییر کرده است که هنوز استیج نشده است؟ +و چه چیزی را استیج کرده‌اید و منتظر کامیت شدن است؟ +با اینکه دستور `git status` جواب آن سوالات را به صورت خیلی کلی به وسطه لیست کردن نام‌های فایل‌ها خواهد داد، اما `git diff` +جزئیات کار را با دقت تغییر در هر خط نشان می‌دهد که چه خطی اضافه یا حذف شده است. -Let's say you edit and stage the `README` file again and then edit the `CONTRIBUTING.md` file without staging it. -If you run your `git status` command, you once again see something like this: +فرض کنیم که شما فایل `README` را تغییر داده‌اید و دوباره استیج کرده‌اید و سپس فایل `CONTRIBUTING.md` را تغییر داده و استیج نکرده‌اید. +اگر دستور ‍`git status` را اجرا کنید، به یکباره چیزی شبیه به خروجی پایین را می‌بینید: [source,console] ---- @@ -294,8 +309,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- - -To see what you've changed but not yet staged, type `git diff` with no other arguments: +برای دیدن تغییراتی که انجام دادید ولی هنوز استیج نکرده ایده، دستور `git diff` را بدون هیچ آرگومان دیگری وارد کنید: [source,console] ---- @@ -316,11 +330,11 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -That command compares what is in your working directory with what is in your staging area. -The result tells you the changes you've made that you haven't yet staged. +آن دستور چیز‌هایی که در پوشه کاری شما هست با چیز‌هایی که در موقعیت استیج هست را مقایسه می‌کند. +نتیجه‌ به شما می‌گوید تغییراتی که به وجود آورده‌اید هنوز استیج نشده‌اند. -If you want to see what you've staged that will go into your next commit, you can use `git diff --staged`. -This command compares your staged changes to your last commit: +اگر شما بخواهید ببینید چه چیزی را استیج کرده‌اید که در کامیت بعدی شما باشد، با اجرا دستور `git diff --staged` نمایش را ببینید. +این دستور آخرین کامیت را با تغییرات استیج مقایسه می‌کند: [source,console] ---- @@ -334,11 +348,13 @@ index 0000000..03902a1 +My Project ---- -It's important to note that `git diff` by itself doesn't show all changes made since your last commit -- only changes that are still unstaged. -If you've staged all of your changes, `git diff` will give you no output. +خیلی مهم است که دقت کنید که `git diff` خودش به تنهایی تمام تغییر ایجاد شده را از آخرین تغییرات نشان نمی‌دهد. -- +فقط تغییراتی که هنوز استیج نشده‌اند. +اگر شما تغییراتی را به استیج کنید، `git diff` خروجی‌ای به شما نمی‌دهد. -For another example, if you stage the `CONTRIBUTING.md` file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged. -If our environment looks like this: +برای مثالی دیگر، اگر شما فایل `CONTRIBUTING.md` را استیج کنید و سپس آن را تغییر دهید، می‌توانید از دستور `git diff` استفاده کنید +و تغییرات ایجاد شده درون فایل که استیج شده‌اند و تغییراتی که استیج نشده‌اند. +اگر محیط ما شبیه پایین باشد: [source,console] ---- @@ -359,7 +375,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Now you can use `git diff` to see what is still unstaged: +حال می‌توانید از دستور `git diff` برای دیدن فایل‌هایی که هنوز استیج نشده‌اند استفاده کنید: [source,console] ---- @@ -375,7 +391,7 @@ index 643e24f..87f08c8 100644 +# test line ---- -and `git diff --cached` to see what you've staged so far (`--staged` and `--cached` are synonyms): +و دستور `git diff --cached` برای دیدن اینکه چه چیزی را اخیرا استیج کرده‌اید (`staged--` و `cached--` مترادف هستند.) [source,console] ---- @@ -397,21 +413,27 @@ index 8ebb991..643e24f 100644 ---- [NOTE] -.Git Diff in an External Tool +دستور `git diff` یک ابزار خارجی است. ==== -We will continue to use the `git diff` command in various ways throughout the rest of the book. -There is another way to look at these diffs if you prefer a graphical or external diff viewing program instead. -If you run `git difftool` instead of `git diff`, you can view any of these diffs in software like emerge, vimdiff and many more (including commercial products). -Run `git difftool --tool-help` to see what is available on your system. +ما در آینده از دستور `git diff` در سراسر این کتاب با موضوعات گوناگونی استفاده خواهیم کرد. +راه دیگری وجود دارد که این چنین تغییرات را ببینید یا شاد ترجیح می‌هید که از ابزارهای گرافیکی یا از ابزارهای خارجی نمایش پیشرفت کار +استفاده کنید. +اگر شما دستور `git difftool` را به جای دستور `git diff` اجرا کنید،‌ می‌توانید هرگونه از این تغییرات را در نرم‌افزاری مثل +emerge, vimdiff یا هر مورد دیگری ببینید(به علاوه محصولات تجاری دیگر). +دستور `git difftool --tool-help` را اجرا کنید تا ببنید که چه نرم‌افزار بر روی سیستم شما موجود است. ==== [[_committing_changes]] -==== Committing Your Changes +==== کامیت کردن تغییرات + +دقت کنید که موقعیت استیج شما آنطور که می‌خواستید آماده شده است، حالا شما می‌توانید تغییرات را کامیت کنید. +به یاد داشته باشید که هر چیزی که همچنان آن‌استیج هستند -- هر فایلی که شما ساختید یا تغییر داده‌اید که هنوز دستور +`git add` برای استیج کردن آن‌ها اجرا نکرده‌اید. -- به مرحله کامیت اضافه نخواهند شد. +آن‌‌ها با عنوان فایل تغییر یافته بر روی دیسک شما باقی خواهد ماند. +در این مورد، فرض کنیم که آخرین باری که دستور `git status` اجرا کردید، همه تغییرات استیج شده بودند، +پس حالا آماده‌اید که تغییرات استیج شده را کامیت کنید.(((git commands, status))) +راحت‌ترین راهی که می‌توانید کامیت را انجام دهید نوشتن دستور `git commit` است:(((git commands, commit))) -Now that your staging area is set up the way you want it, you can commit your changes. -Remember that anything that is still unstaged -- any files you have created or modified that you haven't run `git add` on since you edited them -- won't go into this commit. -They will stay as modified files on your disk. -In this case, let's say that the last time you ran `git status`, you saw that everything was staged, so you're ready to commit your changes.(((git commands, status))) The simplest way to commit is to type `git commit`:(((git commands, commit))) [source,console] @@ -419,14 +441,12 @@ The simplest way to commit is to type `git commit`:(((git commands, commit))) $ git commit ---- -Doing so launches your editor of choice. +دستور بالا ادیتو متنی را باز می‌کند. +(این ادیتور متن به واسه مقداری در متغییر `EDITOR` برای محیط شل خود نوشته‌اید اجرا می‌شود -- معمولا vim یا emacs, +با این حال شما می‌تواند آن را با هر ادیتور که می‌خواهید پیکربندی کنید. با وارد کردن دستور `git config --global core.editor` +همانطور که در بخش <<_getting_started>> دیدید.)(((editor, changing default)))(((git commands, config))) -[NOTE] -==== -This is set by your shell's `EDITOR` environment variable -- usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in <>.(((editor, changing default)))(((git commands, config))) -==== - -The editor displays the following text (this example is a Vim screen): +ادیتور متن زیر را تغییر می‌دهد (این مثال با ادیتور ویم است.) [source] ---- @@ -445,19 +465,14 @@ The editor displays the following text (this example is a Vim screen): ~ ".git/COMMIT_EDITMSG" 9L, 283C ---- +می‌توانید ببینید که پیام کامیت پیش فرض شامل آخرین خروجی دستور `git status` است و یک خط خالی در بالای آن. +شما می‌توانید تمام این پیام‌ها را حذف کنید و پیام خودتان را بنویسید، یا می‌توانید همانطور رها کنید تا بعدا +به شما کمک کند تا دقیقا چیزی که کامیت کرده بودید را به یاد آورید. +برای بیشتر واضح بود یادآور چیزی که تغییر دادید، می‌توانید از آپشن `v-` برای دستور `git commit` استفاده کنید. +این کار همچنین تفاوت تغییرات داخل ادیتور را قرار می‌دهد، پس می‌توانید ببینید دقیقا چه تغییراتی را کامیت می‌کنید. +وقتی از ادیتور خارج می‌شوید، گیت کامیت مورد نظر شما را با پیام کامیتی که نوشته‌اید می‌سازد(همراه توضیحات و تفاوت‌‌ها به صورت خطی) -You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. -You can remove these comments and type your commit message, or you can leave them there to help you remember what you're committing. - -[NOTE] -==== -For an even more explicit reminder of what you've modified, you can pass the `-v` option to `git commit`. -Doing so also puts the diff of your change in the editor so you can see exactly what changes you're committing. -==== - -When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). - -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a `-m` flag, like this: +از سویی دیگر، شما می‌توانید پیام کامیت خود را به صورت یک همراه با دستور `git commit` با آپشن `m-` بنویسید،‌ مانند مثال زیر: [source,console] ---- @@ -467,19 +482,24 @@ $ git commit -m "Story 182: fix benchmarks for speed" create mode 100644 README ---- -Now you've created your first commit! -You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit. +حالا شما اولین کامیت خود را ساختید! +می‌توانید ببینید که کامیتی که ساختید چند خروجی درباره خودش به شما می‌دهد: بر روی کدام برنچ کامیت انجام شده است (`master`)، +کد هش SHA-1 خودش (`463dc4f`)، چه مقدار از فایل‌ها تغییر کرده‌اند و آمارهایی درباره خط‌هایی که اضافه یا حذف شده‌اند در همان +کامیت جاری. -Remember that the commit records the snapshot you set up in your staging area. -Anything you didn't stage is still sitting there modified; you can do another commit to add it to your history. -Every time you perform a commit, you're recording a snapshot of your project that you can revert to or compare to later. +به یاد داشته باشید که آن کامیت اسنپ‌شاتی را ثبت می‌کند شما در موقعیت استیج آماده سازی کرده‌اید. +هر چیزی که شما استیج نکرده‌اید همچنان با عنوان فایل تغییر یافته باقی مانده‌ است؛ شما می‌توانید کامیت دیگری بسازید +و آن را به تاریخچه‌ی تغییرات خود اضافه کنید. +هر زمانی که یک کامیت جدید ایفا می‌کنید، شما اسنپ‌شاتی از پروژه خود می‌سازید که در هر زمان می‌توانید پروژه +را به همان اسنپ‌شات برگردانید یا مقایسه کنید. -==== Skipping the Staging Area +==== رد کردن موقعیت استیج (((staging area, skipping))) -Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. -If you want to skip the staging area, Git provides a simple shortcut. -Adding the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: +موقعیت استیج گاهی اوقات شاید آنطور که ما باید انتظار داریم پیش نمی‌رود و بیش از حد شلوغ می‌شود. +اگر می‌خواهید از مرحله استیج کردن فایل‌ها رد شوید و سریع وارد مرحله کامیت شوید، گیت یک شورت‌کات ساده برای شما آماده کرده است. +با اضافه کردن آپشن `a-` به دستور `git commit` باعث می‌شود گیت به صورت اتوماتیک هر فایلی که ترک شده را استیج کند و آماده کامیت کند، +به طور کلی به این آپشن مرحله `git add` را انجام می‌دهد: [source,console] ---- @@ -498,18 +518,21 @@ $ git commit -a -m 'Add new benchmarks' 1 file changed, 5 insertions(+), 0 deletions(-) ---- -Notice how you don't have to run `git add` on the `CONTRIBUTING.md` file in this case before you commit. -That's because the `-a` flag includes all changed files. -This is convenient, but be careful; sometimes this flag will cause you to include unwanted changes. +دقت کنید که چرا نباید دستور `git add` برای فایل `CONTRIBUTING.md` در این مورد اجرا کنید قبل از اینکه کامیت کنید. +به این دلیل است که آپشن `a-` تمام فایل‌‌هایی است که تغییر کرده‌اند. +این گزینه‌ی راحتی است اما مراقب باشید؛ بعضی وقت‌‌ها باعث می‌شود که شما تغییراتی که نمی‌خواهید را شامل کنید. [[_removing_files]] -==== Removing Files +==== حذف‌ کردن فایل (((files, removing))) -To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. -The `git rm` command does that, and also removes the file from your working directory so you don't see it as an untracked file the next time around. -If you simply remove the file from your working directory, it shows up under the ``Changes not staged for commit'' (that is, _unstaged_) area of your `git status` output: +برای حذف یک فایل از گیت،‌ باید آن را از حالت ترکت حذف کنید(درست‌تر بگوییم، آن را از موقعیت استیج حذف کنید) و بعد کامیت کنید. +دستور `git rm` این کار را می‌کند و همچنین فایل را از پوشه کاریتان حذف می‌کند پس شما آن را به عنوان یک فایل آن‌ترکت شده +نخواهید دید. + +اگر به سادگی فایل را از پوشه کاریتان حذف کنید،‌ نام فایل را زیر تیتر ``Changed but not updated`` می‌بینید +و در خروجی `git status` شما به (آن وضعیت _unstaged_) می‌گوید. [source,console] ---- @@ -526,7 +549,7 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ---- -Then, if you run `git rm`, it stages the file's removal: +سپس، اگر دستور `git rm` را اجرا کنید، گیت فایل را با عنوان فایل حذف شده آن را استیج می‌کند: [source,console] ---- @@ -541,58 +564,60 @@ Changes to be committed: deleted: PROJECTS.md ---- -The next time you commit, the file will be gone and no longer tracked. -If you modified the file or had already added it to the staging area, you must force the removal with the `-f` option. -This is a safety feature to prevent accidental removal of data that hasn't yet been recorded in a snapshot and that can't be recovered from Git. +دفعه بعد که کامیت کنید، فایل از بین خواهد رفت و دیگر وجود نخواهد داشت. +اگر شما فایل را تغییر دهید و آن را استیج کنید، ـ‌بایدـ از آپشن `f-` استفاده کنید و یه جورایی باید آن را به زور حذف کرد. +این یک امکان امن برای حذف تصادفی اطلاعاتی است که هنوز در هیچ اسنپ‌شاتی ثبتت نشده‌اند و نمی‌توانند نمی‌توانند توسط گیت ثبت شوند. -Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. -In other words, you may want to keep the file on your hard drive but not have Git track it anymore. -This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally staged it, like a large log file or a bunch of `.a` compiled files. -To do this, use the `--cached` option: +امکان مفید دیگری شاید بخواهید انجام دهید برای نگه‌داشتن فایل در پوشه کاریتان، اما آن را از محیط استیج حذف کرده‌اید. +در زبانی دیگر، شاید بخوایید آن را در حافظه سخت خود نگه‌دارید ولی نمی‌‌خواهید گیت آن را به هیچ عنوان دنبال کند. +این یک دستور به شدت به درد بخور است چرا اگه فراموش کرده‌اید چیزی را به `gitignore.` اضافه کنید و تصادفا آن را استیج کرده‌اید، +مانند یک فایل لاگ بزرگ یا کلی فایل ‍`a.` کامپایل شده. +به راحتی از آپشن `cached--` استفاده کنید: [source,console] ---- $ git rm --cached README ---- -You can pass files, directories, and file-glob patterns to the `git rm` command. -That means you can do things such as: +شما می‌توانید از الگو‌های پوشه‌ها، فایل‌ها و فایل‌های اصلی در دستور `git rm` استفاده کنید. +که به این معنی است شمامی‌توانید اینگونه عمل کنید: [source,console] ---- $ git rm log/\*.log ---- -Note the backslash (`\`) in front of the `*`. -This is necessary because Git does its own filename expansion in addition to your shell's filename expansion. -This command removes all files that have the `.log` extension in the `log/` directory. -Or, you can do something like this: +به بک‌اسلش(‍`\`) در مقابل `*` دقت کنید. +این کار لازم است چون گیت این کار را به علاوه فایل‌های توسعه خودش بر روی فایل‌های توسعه شما هم اعمال می‌کند. +این دستور تمام فایل‌های توسعه که با پسوند `log.` هستند درون پوشته `/log` را حذف می‌کند. +یا شما می‌توانید چیزی شبیه به دستور زیر را اجرا کنید: [source,console] ---- $ git rm \*~ ---- -This command removes all files whose names end with a `~`. +این دستور تمام فایل‌هایی که نام آن‌ها با یک `~` تمام می‌شود را حذف می‌کند. [[_git_mv]] -==== Moving Files +==== جابه‌جایی فایل‌ها (((files, moving))) -Unlike many other VCS systems, Git doesn't explicitly track file movement. -If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. -However, Git is pretty smart about figuring that out after the fact -- we'll deal with detecting file movement a bit later. +برعکس خیلی از کنترل نسخه‌های دیگر، گیت به صراحت جابه‌جایی‌ها را دنبال نمی‌کند. +اگر شما فایلی را در گیت تغییر نام‌ دهید، هیچگونه متادیتا‌ای در گیت ذخیر نمی‌شود که بعدا بگوید شما آن را تغییر نام داده‌اید. +با این حال، گیت خیلی باهوش است و به راحتی بعد از این کارا می‌فهمد. -- جلوتر درباره جابه‌جایی فایل‌ها حرف خواهیم زد. -Thus it's a bit confusing that Git has a `mv` command. -If you want to rename a file in Git, you can run something like: +بنابراین شاید یکم گیج کننده باشد که گیت دستوری به نام `mv` دارد. +اگر بخواهید نام یک فایل را در گیت تغییر دهید، می‌توانید دستوری شبیه به زیر را اجرا کنید: [source,console] ---- $ git mv file_from file_to ---- -and it works fine. -In fact, if you run something like this and look at the status, you'll see that Git considers it a renamed file: +و به خوبی کار کرد. +در حقیقت، اگر شما چیزی شبیه دستور زیر را اجرا کنید و وضعیت را بررسی کنید، می‌بینید که گیت آن را به عنوان فایل تغییر نام یافته +در نظر می‌گیرد: [source,console] ---- @@ -606,7 +631,7 @@ Changes to be committed: renamed: README.md -> README ---- -However, this is equivalent to running something like this: +با این حال، این معادل اجرا کردن دستوری شبیه زیر است: [source,console] ---- @@ -615,6 +640,6 @@ $ git rm README.md $ git add README ---- -Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command. -The only real difference is that `git mv` is one command instead of three -- it's a convenience function. -More importantly, you can use any tool you like to rename a file, and address the add/rm later, before you commit. +گیت فهمید که یک تغییر نام ضمنی است، پس اصلامهم نیست که شما فایلی را با دستور `mv` تغییر نام دهید. +تنها تفاوت اصلی این است که `git mv` یک دستور است به جای سه دستور -- صرفا یک تابع برای آسودگی کار است. +مهم‌تر از هر چیزی این است که شما می‌توانید از هر ابزاری برای تغییر نام یک فایل استفاده کنید. diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index f1ba62185..c8eb5696c 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,26 +1,29 @@ [[_remote_repos]] -=== Working with Remotes - -برای همکاری در پروژه های گیت، دانستن شیوه ی مدیریت مخارن راه دور لازم است. -مخازن راه دور یک نسخه از پروژه ی شما هستند که در اینترنت یا جایی دیگر در شبکه قرار دارند. -می توانید جند تا از آنها را داشته باشید که هرکدام فقط خواندی یا با اجزاه خواندن و نوشتن باشد. -همکاری با دیگران شما را با مدیریت این مخازن و دریافت داده از آنها و انتقال داده به آنها درگیر می کند. که بتوانید کارهایتان را به اشتراک بگزارید. -مدیریت مخازن راه دور به مفهوم افزودن مخازن راه دور، حذف کردن مخازن به کار نخور، مدیریت شاخه های گوناگون و تعریف آنها به عنوان دنبال شونده با بر داشتن این تعریف و کارهای دیگر است. -در این بخش، ما به برخی از این وهارتهای مدریت مخازن راه دور خواهیم پرداخت.پ +=== کار کردن با ریموت‌ها +برای همکاری در پروژه‌های گیت، دانستن شیوهٔ مدیریت مخزن‌های ریموت لازم است. +مخازن ریموت یک نسخه از پروژهٔ شما هستند که در اینترنت یا جایی دیگر در شبکه قرار دارند. +می‌توانید چند تا از آنها را داشته باشید که هر کدام یا فقط قابل خواندن یا خواندنی/نوشتی هستند. +همکاری با دیگران شما را با مدیریت این مخازن و دریافت داده از آنها و انتقال‌داده به آنها درگیر می کند. که بتوانید کارهایتان را +به اشتراک بگزارید. +مدیریت مخازن ریموت به مفهوم افزودن مخازن ریموت، حذف کردن مخازن بلا استفاده، مدیریت شاخه‌های گوناگون و تعریف آنها به عنوان دنبال شونده +با بر داشتن این تعریف و کارهای دیگر است. +در این بخش ما درباره برخی از مهارت‌‌های مدیریت-ریموت صبحت خواهیم کرد. [NOTE] -.مخازن راه دور می توانند روی کامپیوتر خودتان باشند. +.مخازن ریموت می‌توانند روی کامپیوتر خودتان باشند. ==== به سادگی امکان پذیر است که شما با مخازن ``remote'' ی کار کنید که در واقع در همان کامپیوتر خودتان قرار دارد. -واژه ی ``remote`` لزوما به معنی این نیست که مخزن دور از دسترس، روی اینترنت یا هرجای دیگر شبکه باشد، تنها به این معنی است که مخزن جای دیگری است. -این گونه مخازن راه دور نیز همانند دیگر مخازن راه دور با مسائل دریافت داده، ارسال داده و عملیات دیگر درگیر هستند. +واژهٔ ``remote`` لزوما به معنی این نیست که مخزن دور از دسترس، روی اینترنت یا هرجای دیگر شبکه باشد، تنها به این معنی است که مخزن +جای دیگری است. +این گونه مخازن ریموت نیز همانند دیگر مخازن ریموت با مسائل دریافت داده، ارسال داده و عملیات دیگر درگیر هستند. ==== -==== Showing Your Remotes +==== نمایش ریموت‌هایتان -برای دیدن سرورهای راه دوری که پیکربندی شده اند، می توانید دستور `git remote` را اجرا کنید.(((git commands, remote))) -این دستور نامهای کوتاه سرورهای راه دوری که شما برگزیدید را نشان خواهد داد. -اگر نسخه ای از یک مخزن راه دور بردارید، باید دست کم یک `origin` ببنیند. -- گیت به شکل پیش فرض به سروری که با آن کار می کند این نام را می دهد: +برای دیدن سرورهای ریموت که پیکربندی شده‌اند، می‌توانید دستور `git remote` را اجرا کنید.(((git commands, remote))) +این دستور نام‌های کوتاه سرورهای ریموتی که شما برگزیدید را نشان خواهد داد. +اگر نسخه‌ای از یک مخزن ریموت بردارید، باید دست کم یک `origin` ببنیند. +-- گیت به شکل پیش فرض به سروری که با آن کار می کند این نام را می دهد: [source,console] ---- @@ -36,7 +39,8 @@ $ git remote origin ---- -همچنین متوانید `-v` را بکار گیرید، این دستور به شما نشانی های URL ی را نشان می دهد که برای خواندن و نوشتن داده های پروژه به کار می روند.. +همچنین متوانید `v-` را بکار گیرید،این دستور به شما نشانی های URL ی را نشان می دهد +که برای خواندن و نوشتن داده های پروژه به کار می روند.. [source,console] ---- @@ -63,17 +67,16 @@ koke git://github.com/koke/grit.git (push) origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push) ---- +این به معنی است ما می‌توانیم مشارکت‌هارا از هر کاربری به راحتی پول یا دریافت کنیم. +شاید ما به علاوه دسترسی برای پوش یا ارسال به یک یا بیشتر مخازن داشته باشیم که اینجا نمی‌توانیم بگوییم. +دقت کنید که این ریموت‌ها از پروتکل‌های متنوعی استفاده ‌می‌کنند؛ ما درباره این موضوع در <<_getting_gin_on_a_server>> بیشتر گفته‌ایم. -This means we can pull contributions from any of these users pretty easily. -We may additionally have permission to push to one or more of these, though we can't tell that here. - -Notice that these remotes use a variety of protocols; we'll cover more about this in <>. - -==== Adding Remote Repositories +==== اضافه کردن مخزن ریموت +ما پیش‌تر درباره چگونه دستور `git clone` به طور غیر مستقیم یک ریموت `origin` برای شمامی‌سازد. +خب حالا میگیم چطور یک مخزن ریموت جدید اضافه کنید. -We've mentioned and given some demonstrations of how the `git clone` command implicitly adds the `origin` remote for you. -Here's how to add a new remote explicitly.(((git commands, remote))) -To add a new remote Git repository as a shortname you can reference easily, run `git remote add `: +برای اضافه کردن یک مخزن گیت ریموت جدید با یک نام کوتاه می‌توانید به آدرس آن اشاره کنید و +تقریبا یک آلیاز از آدرس مخزن با نام کوتاه‌ بسازید. با اجرای دستور `git remote add {shortname} {url}`: [source,console] ---- @@ -86,9 +89,9 @@ origin https://github.com/schacon/ticgit (push) pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push) ---- - -Now you can use the string `pb` on the command line in lieu of the whole URL. -For example, if you want to fetch all the information that Paul has but that you don't yet have in your repository, you can run `git fetch pb`: +حالا می‌توانید از `pb` در محیط ترمینال به جای کل آدرس آن مخزن استفاده کنید. +برای مثال، اگر شما بخواهید تمام اطاعاتی که paul دارد را فچ یا دریافت کنید اما هنوز اطلاعات در مخزن خود ندارید، +با اجرای دستور `git fetch pb`: [source,console] ---- @@ -101,54 +104,61 @@ From https://github.com/paulboone/ticgit * [new branch] master -> pb/master * [new branch] ticgit -> pb/ticgit ---- +برنچ `master` پاول حالا به صورت لوکال در `master/pb` قابل دسترس دسترس است -- شما می‌توانید این شاخه را در هر کدام از بر‌نچ‌های دلخواه +ادغام کنید. یا می‌توانید برنچ لوکال خود را چک‌اوت کنید تا اطلاعات را بازرسی کنید. -Paul's `master` branch is now accessible locally as `pb/master` -- you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it. -(We'll go over what branches are and how to use them in much more detail in <>.) +(ما درباره برنچ‌های و چگونگی استفاده از آن‌ها با جزئیات بیشتر در بخش <<_git_branching>> گفته‌ایم.) [[_fetching_and_pulling]] -==== Fetching and Pulling from Your Remotes -As you just saw, to get data from your remote projects, you can run:(((git commands, fetch))) +==== فچ کردن و پول کردن در یک مخزن ریموت +همانطور که مشاهده کردید، برای دریافت اطلاعات از پروژه‌های ریموت خود،‌می‌توانید این دستور را اجرا کنید: [source,console] ---- $ git fetch ---- +دستور مراجعه می‌کند به پروژه ریموت و همه‌ی اطلاعات آن را پول می‌کند. +بعد از انجام این کار، شما می‌توانید به همه‌ی شاخه‌ها از ریموت مراجعه کنید، که می‌توان در هر لحظه ادغام یا مورد نمایش قرار دهید. -The command goes out to that remote project and pulls down all the data from that remote project that you don't have yet. -After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time. +اگر شما یک مخزن را کلون کنید، دستور به صورت خودکار نام مخزن را تحت عنوان `origin` می‌سازد. پس `git fetch origin` تمامی کارها و +اتفاقات جدید که در آن سرور از وقتی که شما آن را کلون کرده‌اید(اخرید فچی که شما داشتید) دریافت می‌کند. +خیلی مهم است که دقت کنید که دستور `git fetch` فقط اطلاعات را در مخزن لوکال شما دریافت می‌کند -- این دستور به صورت خودکار +اطلاعات را با برنچ‌هایی که روی آن کار می‌کنید یا هر برنچ دیگری ادغام نمی‌کند. -If you clone a repository, the command automatically adds that remote repository under the name ``origin''. -So, `git fetch origin` fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. -It's important to note that the `git fetch` command only downloads the data to your local repository -- it doesn't automatically merge it with any of your work or modify what you're currently working on. -You have to merge it manually into your work when you're ready. +اگر از دستور فچ استفاده کردید باید به صورت دستی فعلا مرج یا ادغام را انجام دهید. +اگر برنچ جاری شما تنظیم شده باشد تا یک شاخه ریموت را دنبال کند (بخش بعدی و <<_git_branching>>‌ را برای اطلاعات بیشتر ببینید.)، +می‌توانید از دستور `git pull` به صورت خودکار فعل فچ و ادغام یا مرج آن ریموت در برنچ جاری شما انجام شود. -If your current branch is set up to track a remote branch (see the next section and <> for more information), you can use the `git pull` command to automatically fetch and then merge that remote branch into your current branch.(((git commands, pull))) -This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local `master` branch to track the remote `master` branch (or whatever the default branch is called) on the server you cloned from. -Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on. +این کار شاید برای شما خیلی راحت‌تر یا مورد استقبال‌تر باشد، و به صورت پیش فرض دستور `git clone` خودکار برنچ مستر لوکال شما را برای +دنبال کردن برنچ مستر(یا هرچی که آن شاخه به صورت پیش فرض نامیده‌ شود) ریموت تنظیم می‌کند. -[[_pushing_remotes]] -==== Pushing to Your Remotes +اجرا کردن `git pull` به صورت کلی تمام اطلاعات را از سروری که شما کلون اصلی را انجام دادید؛ فچ می‌کند و به صورت خودکار سعی می‌کند +به ادغام یا مرج کردن کد‌های سرور در جایی که شما در حال کار کردن هستید. -When you have your project at a point that you want to share, you have to push it upstream. -The command for this is simple: `git push `.(((git commands, push))) -If you want to push your `master` branch to your `origin` server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you've done back up to the server: +[[_pushing_remotes]] +==== پوش کردن به مخزن‌های ریموت +زمانی که شما پروژه‌ای دارید که می‌خواهید آن را به اشتراک بگذارید، شما باید آن را به آپ‌استریم پوش کنید. +دستور این کار خیلی ساده است: `git push {remote} {branch}`.(((git commands, push))) +اگر می‌خواهید برنچ `master` را به سرور `origin` پوش کنید،(یادتون باشه، اسامی که گفتیم بعد از کلون کردن به صورت اتوماتیک ساخته می‌شوند) +، بعد می‌توانید با اجرای دستور پوش هر دستوری که کامیت کرده‌ بودید را به سمت سرور بفرستید. [source,console] ---- $ git push origin master ---- -This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. -If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. -You'll have to fetch their work first and incorporate it into yours before you'll be allowed to push. -See <> for more detailed information on how to push to remote servers. +این دستور فقط زمانی کار می‌کند که شما مخزنی را از سمت سروری کلون کرده باشید که دسترسی نوشتن نیز داشته باشید و اگر کسی در خلال کار +شما پوش نکرده باشد، چرا که وقتی شخصی دیگر از همان مخزن اطلاعات را کلون کرده باشد و پوش هم کرده باشد درخواست پوش شما رد خواهد شد،‌ +به این دلیل که اطلاعات شما باید عین چیزی باشد که بر روی سرور قرار داد یعنی باید به روز باشد پس باید اول اطلاعات سرور را فچ کنید +بعد اجازه دارید اطلاعات خودتون رو به سرور پوش کنید. +برای جزئیات بیشتر در این باره که چطور بر روی یک سرور ریموت پوش کنید بخش <<_git_branching>> را مطالعه کنید. [[_inspecting_remote]] -==== Inspecting a Remote - -If you want to see more information about a particular remote, you can use the `git remote show ` command.(((git commands, remote))) -If you run this command with a particular shortname, such as `origin`, you get something like this: +==== بازرسی ریموت +اگر می‌خواید درباره یک ریموت خاص اطلاعات بیشتری ببینید، می‌توانید از دستور +`git remote shot {remote}` استفاده کنید.(((git commands, remote))) +اگر این دستور را اجرا کنید با یک اسم خاص کوتاه، مثل `origin` چیزی شبیه به این را خواهید دید: [source,console] ---- @@ -166,12 +176,11 @@ $ git remote show origin master pushes to master (up to date) ---- -It lists the URL for the remote repository as well as the tracking branch information. -The command helpfully tells you that if you're on the `master` branch and you run `git pull`, it will automatically merge in the `master` branch on the remote after it fetches all the remote references. -It also lists all the remote references it has pulled down. - -That is a simple example you're likely to encounter. -When you're using Git more heavily, however, you may see much more information from `git remote show`: +این دستور آدرس مخزن ریموت و همچنین اطلاعات برنچ‌هایی که دنبال می‌شوند را لیست می‌کند و مفید و مختصر به شما می‌گوید که اگر +بر روی برنچ مستر هستید و دستور `git pull` را اجرا کنید، به صورت اتوماتیک اطلاعات که دریافت می‌کند در برنج مستر شما مرج می‌کند +و همچنین لیست تمام ریموت‌های منبع که از آن پول کرده است را نمایش می‌دهد. +این ساده‌ترین مثالی است که شما با آن برخورد خواهید کرد. +وقتی از گیت در سطح وسیع‌‌تری استفاده کنید،‌احتمالا اطلاعات بیشتری با این دستور به شما نشان داده شود، `git remote show`: [source,console] ---- @@ -196,14 +205,13 @@ $ git remote show origin markdown-strip pushes to markdown-strip (up to date) master pushes to master (up to date) ---- - -This command shows which branch is automatically pushed to when you run `git push` while on certain branches. -It also shows you which remote branches on the server you don't yet have, which remote branches you have that have been removed from the server, and multiple local branches that are able to merge automatically with their remote-tracking branch when you run `git pull`. +این دستور نشان‌ می‌دهد که به کدام برنچ به صورت اتوماتیک پوش شده‌ است وقتی دستور `git push` بر روی یک برنچ مشخص انجام می‌شود. +همچنین کدام برنچ روی سرور را، شما ندارید؛ کدام برنچ بر شما دارید اما از روی سرور حذف شده است. +و چندین برنچ لوکا که می‌توانند به صورت اتوماتیک مرج شوند با برنجی که بر روی آن هستید و این کار با دستو `git pull` اجرایی خواهد شد. ==== Renaming and Removing Remotes - -You can run `git remote rename` to change a remote's shortname.(((git commands, remote))) -For instance, if you want to rename `pb` to `paul`, you can do so with `git remote rename`: +شما می‌توانید دستور `git remote rename` را اجرا کنید تا نام کوتاه ریموت را عوض کنید. +برای نمونه، اگر می‌خواهید جای نام `pb` به `paul` تغییر کند،‌ می‌توانید دستور `git remote rename` را وارد کنید. [source,console] ---- @@ -212,11 +220,11 @@ $ git remote origin paul ---- +قابل ذکر است که دستور بالا نام تمام برنچ‌ها حتی آنهایی که بر روی سرور هستند نیز تغییر می‌کند. +چیزی که برای اشاره از آن استفاده می‌شد از `pb/master` به `paul/master` تغییر می‌کند. -It's worth mentioning that this changes all your remote-tracking branch names, too. -What used to be referenced at `pb/master` is now at `paul/master`. - -If you want to remove a remote for some reason -- you've moved the server or are no longer using a particular mirror, or perhaps a contributor isn't contributing anymore -- you can either use `git remote remove` or `git remote rm`: +اگر بخواهید یک ریموت را به هر دلیلی حذف کنید -- جابه جایی سرور یا قابل استفاده نبود آن یا شاید یک مشارکت کنند دیگر مشارکتی نمی‌کند +-- شما می‌توانید یا از دستور `git remote remove` یا از دستور `git remote rm` استفاده کنید: [source,console] ---- @@ -224,5 +232,4 @@ $ git remote remove paul $ git remote origin ---- - -Once you delete the reference to a remote this way, all remote-tracking branches and configuration settings associated with that remote are also deleted. +یکبار که یک ریموت را به این صورت پاک کنید، تمامی برنچ‌ها و پیکیربندی‌هایی همراه آن وجود داشت نیز از بین خواهند رفت. diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index f9c59003c..cf6aa91d2 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -2,14 +2,22 @@ === برجسب‌گذاری (((tags))) + مانند بیشتر VCSهای دیگر، گیت قابلیت برچسب‌زدن (Tag/تگ) نقاطی خاص از پروژه را به عنوان نقاط مهم دارد. معمولاً افراد از این قابلیت برای نشانه‌گذاری نسخه‌های قابل ارائه یا _release_ استفاده می‌کنند (`v1.0`، `v2.0` و به همین ترتیب). در این بخش می‌آموزید که چگونه تگ‌های از پیش موجود را لیست کنید، چگونه تگ بسازید و از بین ببرید و اینکه انواع مختلف تگ‌ها کدامند. -==== فهرست برچسب های موجود -لیست کردن تگ‌های از پیش موجود در گیت بسیار ساده است. -کافیست `git tag` را (با آپشن‌های `-l` یا `--list`) تایپ کنید:(((git commands, tag))) +همچون دیگر سیستم‌های کنترل نسخه، گیت هم می‌تواند یک نقطه‌ی خاص از تاریخچهٔ پروژه +را به عنواه نقطهٔ مهم و با اهمیت برچسب گذاری کند. +معمولا افراد از این قابلیت برای نشانه گذاری نسخه‌های قابل ارائه یا همان release کردن پروژه بهره می‌برند. +( نسخه v1.0، و به همین ترتیب). +در این بخش فهرست‌سازی از برچسب‌های موجود، شیوه ساخت برچسب جدید و این که گونه‌های متفاوت برچسب ها +هر کدام چه هستند را یاد خواهید گرفت. + +==== فهرست برچسب های موجود +فهرست‌‌سازی از برچسب‌های موجود در گیت بسیار ساده است. تنها نیاز است که دستور `git tag` +(با پارامتر دلخواه `-l` و یا `--list`) را وارد نمایید:(((git commands, tag))) [source,console] ---- @@ -18,11 +26,10 @@ v1.0 v2.0 ---- -این دستور تگ‌ها را به ترتیب الفبا نشان می‌دهد؛ ترتیب نمایش اهمیت خاصی ندارد. - -همچنین شما می‌توانید برچسب‌هایی که با الگویی خاص مطابقت دارند را جست‌وجو کنید. -برای نمونه مخزن سورس گیت بیش از ۵۰۰ برچسب دارد. -به طور مثال، اگر فقط دنبال سری 1.8.5 می‌گردید می‌توانید این دستور را اجرا کنید: +این دستور، برچسب های موجود را به ترتیب حرف الفبا نشان می دهد; درواقع ترتیب نمایش آنها هیچ اهمیتی ندارد. +همچنین می توان برچسب ها را جست و جو کنید و از الگوها نیز بهره‌مند شوید. +برای نمونه مخزن اصلی گیت، بیش از 500 برچسب دارد. +مثلا اگر می‌خواید تنها به دنبال برجسب‌های سری 1.8.5 بگردید، می‌توانید دستور زیر را اجرا نمایید: [source,console] ---- @@ -40,30 +47,36 @@ v1.8.5.5 ---- [NOTE] -.Listing tag wildcards requires `-l` or `--list` option ==== -If you want just the entire list of tags, running the command `git tag` implicitly assumes you want a listing and provides one; the use of `-l` or `--list` in this case is optional. +آپشن `l-` یا `list--` یک الگو خاص را می‌تواند لیست کند. + +اگر می‌خواهید لیستی از تگ‌ها را لیست کنید، با اجرا کردن دستور `git tag` به سرعت یک لیست برای شما تهیه می‌کند؛ استفاده از آپشن‌های `l-` +یا `list--` اختیاری است. -If, however, you're supplying a wildcard pattern to match tag names, the use of `-l` or `--list` is mandatory. +با این حال اگر خواستید یک لیستی مشخص با یک الگو را ببینید، استفاده از آپشن `l-` یا `list--` لازم است. ==== -==== ساخت برچسب ها +==== ساخت برچسب‌ها -گیت دو گونه برچسب دارد: _lightweight_ یا __سبک__ و _annotated_ یا __مفصل__. +گیت دو گونه برچسب دارد: _lightweight_ یا __موقت__ و _annotated_ یا __توضیحی__. -یگ برچسب lightweight بسیار شبیه یک شاخه ی بدون تغییر است. -- فقط اشاره گری به یک ثبت ویژ] و مشخص است. +یک تگ موقت بسیار شبیه یک برنچ است که تغییر نمی‌کند -- فقط یک اشاره‌گر به کامیتی مشخص است. -برچسب های Annotated , however, به عنوان مجموعه ای از اشیاء کامل در پایگاه داده گیت ذخیره می شوند. -این برچسب ها کنترل checksum می شوند; شامل نام کاربر، ایمیل و تاریخ برجسب گذاری هستند; پیام مربوط به برچسب را دارند; و می توان آنها را با GPG (GNU Privacy Guard) علامت گذاری و تایید نمود. +با این حال، تگ‌‌‌های توضیحی به عنوان یک آبجکت کامل در دیتابیس گیت ذخیره می‌شوند؛ که این آبجکت‌ها شامل نام و ایمیل کسی که تگ را ثبت کرده، +تاریخ ثبت تگ و دارای پیام مربوط به خود هستند و همچنین می‌توانند امضا شوند یا توسط گادر حریم خصوصی گنو یا GPG تایید شوند. +به طور کلی پیشنهاد می‌شود که از تگ توضیحی استفاده کنید که در نتیجه‌ می‌توانید تمام اطلاعات ذکر شده را داشته باشید؛ اما اگر لازم شد +که یک تگ موقت ثبت کنید بنا به دلایلی که نمی‌خواهید دیگر اطلاعات را نگه‌دارید، می‌توانید از تگ موقت استفاده کنید. -بیشتر پیشنهاد می شود که برچسب های annotated ایجاد کنید تا به همه این داده ها دسترسی داشته باشد; اما اگر تنها یک برچسب موفت و گذرا نیاز دارید و یا به هر روی نباید داده ها ذخیره شوند می توانید از برچسب های lightweight بهره بگیرید. +بیشتر پیشنهاد می شود که تگ‌‌های توضیحی ایجاد کنید تا به همه این داده ها دسترسی داشته باشد; [[_annotated_tags]] -==== برچسبهای Annotated +==== برچسب‌های توضیحی (((tags, annotated))) -ساخت یک برچسب Annotated در گیت بسیار ساده است. -ساده ترین راه افزدون `-a` هنگام اجرای دستور `tag` می باشد:(((git commands, tag))) +ساخت یک برچسب توضیحی در گیت بسیار ساده است. +ساده‌ترین راه افزدون آپشن `a-` هنگام اجرای دستور `git tag`می باشد: + +(((git commands, tag))) [source,console] ---- @@ -74,10 +87,10 @@ v1.3 v1.4 ---- -`-m` مشخص گننده پیام برچسب است، که با برچسب ذخیره خواهد شد. -اگر پیامی برای یک برچسب annotated مشخص نکنید گیت ویرایش پیش فرض را اجرا کرده و شما می توانید آنجا نوشتن را بیاغازید. +با آپشن `m-` می‌توانید همراه دستور `git tag` پیام برچسب را در یک خط بنویسید اما اگر این آپشن را برای یک تگ توضیحی مشخص نکنید، +گیت ویرایشگر متن شما را برای نوشتن پیام تگ باز خواهد کرد. -داده های برچسب را میتوانید در همان ثبت برچسب گذاری شده با دستور `git show` ببینید. +شما می‌توانید اطلاعات مربوط به تگ‌ها و کامیت‌های مربوط به آن تگ را با استفاده از دستور `git show` ببینید. [source,console] ---- @@ -94,16 +107,14 @@ Date: Mon Mar 17 21:52:11 2008 -0700 Change version number ---- +این دستور داده‌هایی اعم از اطلاعات کاربر, تاریخی که تگ کامیت شده است و یادداشت‌‌ها قبل از نمایش اطلاعات کامیت. -این دستور داده های کاربر برچسب گذار، تاریخ برچسب -گذاری و پیام مربوط به برچسب را پیش ا ز داده های ثبت مربوطه نشان می دهد. - -==== برچسب های Lightweight +==== برچسب‌های موقت (((tags, lightweight))) -راه دیگری برای برچسب گذاری ثبت ها برچسب lightweight است. -این برچسب تنها checksum مربوط به ثبت است که در یک فایل ذخیره می شود -- اطلاعات دیگری نگه داشته نمیشود. -برای ساخت یک برچشب lightweight، هیچکدام از گزینه های `-a`، `-s`، یا `-m` را بکار نگیرید، تنها نام برچسب را وارد نمایید. +راه دیگری برای برچسب گذاری کامیت‌ها تگ موقت است. +این تگ تنها مربوط به یک کامیت است که در یک فایل ذخیره می شود -- اطلاعات دیگر مانند تگ توضیحی نگه‌داشته نمی‌شود. +برای ساخت یک برچشب موقت، هیچکدام از آپشن‌های `a-` و `s-`، یا `m-` را بکار نگیرید، فقط نام برچسب را وارد نمایید. [source,console] ---- @@ -115,9 +126,10 @@ v1.4 v1.4-lw v1.5 ---- +در این لحظه، اگر شما دستور `git show` بر روی یک تگ اجرا کنید؛ اطلاعات اضافی نمی‌بینید. -اکنو اگر `git show` را بر روی یک برچسب اجرا کنید، داده های بیشتری از برچسب را نخواهید دید.(((git commands, show))) -این دستور تنها ثبت را نشان خواهد: +این دستور فقط کامیت‌ را نشان می‌دهد: +(((git commands, show))) [source,console] ---- @@ -129,10 +141,11 @@ Date: Mon Mar 17 21:52:11 2008 -0700 Change version number ---- -==== برچسب گذاری با تاخیر +==== بعدا تگ بزنید + +شما این امکان را دارید که بعد از چند کامیت، کامیت‌ها قبلی را تگ بزنید. -همچینین می توانید بعد از چند ثبت،ثبت های پیشین را برچسب گذاری کتید. -فرض کنید تاریخچه ی برچسب های شما شبیه این باشد: +فرض کنید تاریخچهٔ تگ‌های شما شبیه این باشد: [source,console] ---- @@ -149,16 +162,17 @@ a6b4c97498bd301d84096da251c98a07c7723e65 Create write support 8a5cbc430f1a9c3d00faaeffd07798508422908a Update readme ---- -حال فرض کنید که فراموش کرده‌اید که پروژه را وقتی که در v1.2 و در کامیت ``Update rakefile'' بود تگ‌گذاری کنید. -پس از ثبت می‌توانید این کار را انجام دهید. -برای تگ کردن آن کامیت می‌توانید چک‌سام (یا بخشی از چک‌سام) آن کامیت را در پایان دستور مشخص کنید: +حالا فرض کنید که در کامیت ``updated rakefile`` فراموش کرده‌اید پروژ را با v1.2 تگ گذاری کنید. +پس از کامیت می‌توانید این کار را انجام دهید. + +برای تگ کردن کامیت مورد نظر، هش کد کامیت مورد نظر را در اخر دستور وارد کنید. [source,console] ---- $ git tag -a v1.2 9fceb02 ---- -می بینید که ثبت مورد نظر برچسب گذاری شده است:(((git commands, tag))) +می بینید که کامیت مورد نظر تگ گذاری شده است:(((git commands, tag))) [source,console] ---- @@ -185,11 +199,11 @@ Date: Sun Apr 27 20:43:35 2008 -0700 ---- [[_sharing_tags]] -==== اشتراک گذری برجسب ها +==== اشتراک گذری تگ‌ها -دستور `git push` برچسب ها را به صورت پیش فرض به سرور منتقل نمی کند.(((git commands, push))) -شما باید برچسب ها را پس از ساخت و ایجاد آنها، مستقلا انتقال دهید. -این فرآیند دقیقا شبیه انتقال و انتشار شاخه هاست -- شما می توانید دستور `git push origin ` را بکار ببرید. +دستور `git push` تگ‌ها را به صورت پیش فرض به سرور منتقل نمی کند.(((git commands, push))) +شما باید تگ‌ها را پس از ساخت و ایجاد آنها، مستقلا انتقال دهید. +این فرآیند دقیقا شبیه انتقال و انتشار شاخه‌ها است -- شما می‌توانید دستور `git push origin {tagname}` را بکار ببرید. [source,console] ---- @@ -204,8 +218,8 @@ To git@github.com:schacon/simplegit.git ---- -اگر برچسب های زیادی دارید که میخواهید همه را یکجا به سرور منتقل کنید، می توانید از گزینه `--tags` در دستور `git push` استفاده نمایید. -این دستور تمام برچسب هایی را که در سرور نیستند به سرور منتقل خواهد کرد. +اگر تگ‌های زیادی دارید که می‌خواهید همه را یکجا به سرور منتقل کنید، می‌توانید از گزینهٔ `tags--` در دستور `git push` استفاده نمایید. +این دستور تمام تگ‌هایی را که در سرور نیستند به سرور منتقل خواهد کرد. [source,console] ---- @@ -218,18 +232,20 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.4-lw -> v1.4-lw ---- -اینک اگر کسی دیگر از مخزن ما نمونه برداری کرد یا تنها ثبت ها را فراخوانی و بارگزاری کرد، تمام برجسب ها را نیز دریافت خواهد نمود. +حالا اگر شخصی دیگر از مخزن ما کلون کند یا آن را پول کند، تمامی تگ‌های ساخته شده نیز وجود خواهند داشت. [NOTE] -.`git push` pushes both types of tags -==== -Pushing tags using `git push --tags` does not distinguish between lightweight and annotated tags; there is no simple option that allows you to select just one type for pushing. ==== -==== Deleting Tags +دستور `git push` هر دو نوع تگ را به سرور خواهد فرستاد. + +فرستادن تگ‌ها به سمت سرور با دستور `git push {tagname} --tags` هیچ وجه تمایزی بین تگ توضیحی یا تگ موقت قائل نمی‌شود. +هیچ راه یا آپشن ساده‌ای وجود ندارد که نوع تگ مورد نظر برای پوش انتخاب کنید. +==== -To delete a tag on your local repository, you can use `git tag -d `. -For example, we could remove our lightweight tag above as follows: +==== حذف کردن تگ‌ها +برای حذف تگ‌های ساخت شدن در مخزن محلی لوکال خود، می‌توانید از دستور `git tag -d {tagname}`. برای مثال، ما می‌توانیم تگ‌های موقت خود را +با دستور زیر حذف کنیم. [source,console] ---- @@ -237,31 +253,31 @@ $ git tag -d v1.4-lw Deleted tag 'v1.4-lw' (was e7d5add) ---- -Note that this does not remove the tag from any remote servers. -There are two common variations for deleting a tag from a remote server. +دقت کنید که دستور بالا تگ را از مخزن‌های ریموت پاک نمی‌کند و فقط شامل مخزن لوکال می‌شود. +دو راه برای معمول برای حذف تگ از ریموت سرور وجود دارد. -The first variation is `git push :refs/tags/`: +اولین ایجاد تغییر با دستور `git push {remote} :refs/tags/{tagnam}`: [source,console] ---- $ git push origin :refs/tags/v1.4-lw To /git@github.com:schacon/simplegit.git - - [deleted] v1.4-lw + - [deleted] v1.4-lw ---- -The way to interpret the above is to read it as the null value before the colon is being pushed to the remote tag name, effectively deleting it. +اتفاقی که در بالا می‌افتد این است که قبل از پوش شدن کلون به سمت ریموت سرور مقدار تگ تعیین شده تهی می‌شود. -The second (and more intuitive) way to delete a remote tag is with: +راه دوم و منطقی‌ترین راه برای حذف تگ از یک ریموت دستور زیر است. [source,console] ---- $ git push origin --delete ---- -==== Checking out Tags +==== بررسی صحت تگ‌ها -اگر می‌خواهید نسخه‌هایی از فایل‌هایی که یک تگ به آنها اشاره دارد را ببینید، کافیست که یک `git checkout` از آن تگ انجام دهید؛ اگرچه این دستور مخزن شما را در حالت ``detached HEAD'' قرار می‌دهد که عوارض جانبی نامطلوبی دارد: ->>>>>>> master +اگر نسخه‌های فایلهایی که تگ به آنها اشاره می‌کند را می‌خواهید ببینید، می‌توانید یک `git checkout` اجرا کنید، +آگاه باشید که این کار مخزن شما را در وضعیت «**detached HEAD**» قرار می‌دهد, که امکان تاثیرات جبران ناپذیری دارد: [source,console] ---- @@ -284,8 +300,10 @@ Previous HEAD position was 99ada87... Merge pull request #89 from schacon/append HEAD is now at df3f601... Add atlas.json and cover image ---- -در حالت ``detached HEAD''، اگر تغییراتی ایجاد کنید و سپس آنها را کامیت کنید، تگ به همان صورت باقی خواهند ماند اما کامیت شما به هیچ برنچی تعلق نخواهد گرفت و غیرقابل دسترس خواهد بود مگر اینکه به وسیله هش کد به آن دسترسی پیدا کنید. -بنابراین اگر می‌خواهید تغییراتی اعمال کنید -- ثرض کنیم می‌خواهید مشکلی را از یک نسخه قدیمی برطرف کنید -- احتمالاً خواهید خواست که یک برنچ هم برایش بسازید: +در وضعیت «**detached HEAD**» اگر تغییراتی ایجاد کنید و آنها را کامیت کنید، +تگ تغییر نخواهد کرد، اما کامیت شما در هیچ کدام از شاخه‌ها ثبت نخواهد شد و از دست می‌رود. +مگر با کد کامل hash مربوط به آن کامیت. بنابراین اگر نیاز به ایجاد تغییرات دارید +-- مثلا می‌خواهید یک باگ را در نسخه‌های پیشین برطرف نمایید -- شماه باید یک شاخهٔ جدید بسازید. [source,console] ---- @@ -293,4 +311,5 @@ $ git checkout -b version2 v2.0.0 Switched to a new branch 'version2' ---- -با اجرای دستور بالا، اگر یک ثبت تازه ایجاد نمودید، شاخه ی `version2` اندکی متفاوت از برچسب `v2.0.0` خواهد بود. تا زمانی که با تغییرات جدید در این شاخه به پیش می رود. پس مرافب باشید. +اگر دستور بالا را اجرا کنید و یک کامیت بسازید، شاخه `version2` از زمانی که شروع به پیشرفت کند مقداری کمی متفاوت +از تگ `v2.0.0` خواهد بود، پس مراقب تغییرات باشید که از دست نروند. diff --git a/status.json b/status.json index b00cf070a..d3344ae7f 100644 --- a/status.json +++ b/status.json @@ -14,14 +14,14 @@ "sections/installing.asc": 100 }, "02-git-basics": { - "1-git-basics.asc": 98, - "sections/aliases.asc": 98, - "sections/getting-a-repository.asc": 100, - "sections/recording-changes.asc": 0, - "sections/remotes.asc": 0, + "1-git-basics.asc": 95, + "sections/aliases.asc": 95, + "sections/getting-a-repository.asc": 95, + "sections/recording-changes.asc": 95, + "sections/remotes.asc": 95, "sections/tagging.asc": 95, - "sections/undoing.asc": 10, - "sections/viewing-history.asc": 90 + "sections/undoing.asc": 95, + "sections/viewing-history.asc": 95 }, "03-git-branching": { "1-git-branching.asc": 95,