Merge pull request #25 from MYDavoodeh/ch5

Draft chapter 5

Author: hjavadish

TRANSLATION_NOTES.asc

@@ -106,4 +106,9 @@
 |برنچ پیگیر |Tracking Branch
 |ریبیس |Rebase
 |دوشاخه |Divergent
+|مدیر-یکپارچه‌سازی|Integration-Manager
+|باقدمت|Long-term
+|چری-پیک (در مواردی که نیاز به ترجمه مفهومی فارسی است «دست‌چینی»)|Cherry-pick
+|ررره|Rerere
+|شورت‌لاگ|Shortlog
 |===

book/05-distributed-git/sections/contributing.asc

@@ -1,90 +1,92 @@
-=== Distributed Workflows
+=== روندهای کاری توزیع‌شده
 
 (((workflows)))
-In contrast with Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects.
-In centralized systems, every developer is a node working more or less equally with a central hub.
-In Git, however, every developer is potentially both a node and a hub; that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to.
-This presents a vast range of workflow possibilities for your project and/or your team, so we'll cover a few common paradigms that take advantage of this flexibility.
-We'll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each.
+برخلاف سیستم‌های کنترل نسخه متمرکز (CVCS)، نفس توزیع‌شدهٔ گیت به شما این اجازه می‌دهد تا در اینکه چگونه توسعه‌دهنده‌ها روی پروژه‌ها همکاری می‌کنند انعطاف خیلی بیشتری داشته باشید.
+در سیستم‌های متمرکز، هر توسعه‌دهنده یک گره فعال است که کم‌وبیش به طور برابر با دیگران با هاب مرکزی کار می‌کند.
+لکن در گیت هر توسعه‌دهنده می‌تواند هم یک گره باشد هم یک هاب؛ اینگونه، هر توسعه‌دهنده هم می‌تواند در کد مخازن دیگر مشارکت کند و یک مخزن عمومی داشته باشد که دیگران می‌توانند روی آنها کار کنند و در آن مشارکت کنند.
+این اصل طیف زیادی از روندهای کاری ممکن برای پروژه و/یا تیم شما ارائه می‌کند؛ به همین دلیل ما چند نمونه از آنها را بررسی خواهیم کرد تا از این انعطاف‌پذیر نهایت استفاده را ببریم.
+به نقاط قوت و ضعف احتمالی هر طراحی خواهیم پرداخت؛ شما می‌توانید یکی از این طراحی‌ها را انتخاب کنید، یا می‌توانید که آنها را ترکیب کنید و از هرکدام یک ویژگی برگزینید.
 
-==== Centralized Workflow
+==== روند کاری متمرکز
 
 (((workflows, centralized)))
-In centralized systems, there is generally a single collaboration model -- the centralized workflow.
-One central hub, or _repository_, can accept code, and everyone synchronizes their work with it.
-A number of developers are nodes -- consumers of that hub -- and synchronize with that centralized location.
+در سیستم‌های متمرکز، غالباً یک مدل همکاری وجود دارد -- روند کاری متمرکز.
+یک هاب یا _مخزن_ مرکزی قادر است کدها را بپذیرد و همه کار خود را با آن همگام‌سازی می‌کنند.
+تعدادی توسعه‌دهنده گره‌های این شبکه هستند -- مشتری‌های هاب -- و کار خود را با آن نقطهٔ مرکزی همگام‌سازی می‌کنند.
 
-.Centralized workflow.
+.روند کاری متمرکز.
 image::images/centralized_workflow.png[Centralized workflow.]
 
-This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems.
-The second developer must merge in the first one's work before pushing changes up, so as not to overwrite the first developer's changes.
-This concept is as true in Git as it is in Subversion(((Subversion))) (or any CVCS), and this model works perfectly well in Git.
+این بدان معناست که اگر دو توسعه‌دهنده از هاب کلون کنند و هر دو تغییراتی را اعمال کنند، اولین توسعه‌دهنده‌ای که بخواهد تغییرات را پوش کند، می‌تواند بی‌مشکل این کار را انجام دهد.
+اما دومی توسعه‌دهنده باید کار نفر اول را قبل از پوش کردن ادغام کند تا منجر به بازنویسی روی کارهای توسعه‌دهندهٔ اول نشوند.
+این مفهوم در گیت هم به اندازهٔ ساب‌ورژن(((Subversion))) (یا هر CVCS دیگری) برقرار است و این مدل کاری در گیت هم به طور بی‌نقص کار می‌کند.
 
-If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git.
-Simply set up a single repository, and give everyone on your team push access; Git won't let users overwrite each other.
+اگر از قبل به روند کاری متمرکز در کمپانی یا تیم خود عادت دارید، به سادگی می‌توانید همان روند را ادامه دهید.
+خیلی ساده یک مخزن راه‌اندازی کنید، به تمام افراد تیم خود دسترسی پوش بدهید؛ گیت اجازه نخواهد داد که کاربران تغییرات یکدیگر را بازنویسی کنند.
 
-Say John and Jessica both start working at the same time.
-John finishes his change and pushes it to the server.
-Then Jessica tries to push her changes, but the server rejects them.
-She is told that she's trying to push non-fast-forward changes and that she won't be able to do so until she fetches and merges.
-This workflow is attractive to a lot of people because it's a paradigm that many are familiar and comfortable with.
+فرض کنیم که جان و جسیکا هر دو در حال کار هم‌زمان هستند.
+جان تغییرات خود را تمام می‌کند و آنها را روی سرور پوش می‌کند.
+سپس جسیکا سعی می‌کند که تغییرات خود را پوش کند، اما سرور آنها را رد می‌کند.
+به او گفته می‌شود که اون سعی در پوش کردن تغییرات غیر-fast-forward است و تا زمانی که فچ و مرج نکند، نخواهد توانست چنین کاری را انجام دهد.
+این روند کاری افراد زیادی را جذب خود می‌کند، چرا که روشی است که کثیری از افراد با آن احساس راحتی می‌کنند و آشنا هستند.
 
-This is also not limited to small teams.
-With Git's branching model, it's possible for hundreds of developers to successfully work on a single project through dozens of branches simultaneously.
+بعلاوه، این روش به تیم‌های کوچک محدود نیست.
+با مدل شاخه‌سازی گیت، می‌توانید صدها توسعه‌دهنده داشته باشید تا به طور موفقیت‌آمیز و همزمان به وسیلهٔ هزاران برنچ، همزمان روی یک پروژه کار کنند.
 
 [[_integration_manager]]
-==== Integration-Manager Workflow
+==== روند کاری مدیر-یکپارچه‌سازی
 
 (((workflows, integration manager)))
-Because Git allows you to have multiple remote repositories, it's possible to have a workflow where each developer has write access to their own public repository and read access to everyone else's.
-This scenario often includes a canonical repository that represents the ``official'' project.
-To contribute to that project, you create your own public clone of the project and push your changes to it.
-Then, you can send a request to the maintainer of the main project to pull in your changes.
-The maintainer can then add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository.
-The process works as follows (see <<wfdiag_b>>):
-
-1.  The project maintainer pushes to their public repository.
-2.  A contributor clones that repository and makes changes.
-3.  The contributor pushes to their own public copy.
-4.  The contributor sends the maintainer an email asking them to pull changes.
-5.  The maintainer adds the contributor's repository as a remote and merges locally.
-6.  The maintainer pushes merged changes to the main repository.
+از این جهت که گیت به شما اجازهٔ داشتن چندین مخزن ریموت را می‌دهد، این امکان وجود دارد که روند کاری داشته باشید
+که در آن هر توسعه‌دهنده اجازهٔ نوشتن به مخزن عمومی خودش را دارد و اجازهٔ خواندن از مخازن دیگران را دارد.
+در این سناریو معمولاً یک مخزن استاندارد و مرکزی وجود دارد که نقش پروژهٔ «رسمی» را بازی می‌کند.
+برای مشارکت در آن پروژه، مشا کلون عمومی خود را از پروژه می‌سازید و تغییرات خود را به آن پوش می‌کنید.
+سپس می‌توانید به نگهدارندهٔ پروژهٔ اصلی درخواستی ارسال کنید تا تغییرات شما را پول کند.
+نگهدارندهٔ مذکور پس از این، می‌تواند مخزن شما را به عنوان یک ریموت اضافه کند، تغییرات شما را به طور محلی تست کند، آنها را در برنچ خودش  مرج کند و به مخزن خودش پوش کند.
+این فرآیند به صورت زیر است (<<wfdiag_b>> را نگاه کنید):
+
+1.  نگه‌دارندهٔ پروژه به مخزن عمومی پوش می‌کند.
+2.  یک همکار آن را کلون می‌کند و تغییراتی اعمال می‌کند.
+3.  همکار به کپی عمومی خودش پوش می‌کند.
+4.  همکار ایمیلی به نگهدارنده می‌فرستد و از او می‌خواهد که تغییرات را پول کند.
+5. نگهدارنده مخزن همکار را به عنوان یک ریموت اضافه می‌کند به صورت محلی مرج می‌کند.
+6.  نگدارنده مرج تغییرات را به مخزن اصلی پوش می‌کند.
 
 [[wfdiag_b]]
-.Integration-manager workflow.
+.روند کاری مدیر-یکپارچه‌سازی.
 image::images/integration-manager.png[Integration-manager workflow.]
 
 (((forking)))
-This is a very common workflow with hub-based tools like GitHub or GitLab, where it's easy to fork a project and push your changes into your fork for everyone to see.
-One of the main advantages of this approach is that you can continue to work, and the maintainer of the main repository can pull in your changes at any time.
-Contributors don't have to wait for the project to incorporate their changes -- each party can work at their own pace.
-
-==== Dictator and Lieutenants Workflow
-
-(((workflows, dictator and lieutenants)))
-This is a variant of a multiple-repository workflow.
-It's generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel.
-Various integration managers are in charge of certain parts of the repository; they're called _lieutenants_.
-All the lieutenants have one integration manager known as the benevolent dictator.
-The benevolent dictator pushes from their directory to a reference repository from which all the collaborators need to pull.
-The process works like this (see <<wfdiag_c>>):
-
-1.  Regular developers work on their topic branch and rebase their work on top of `master`.
-    The `master` branch is that of the reference repository to which the dictator pushes.
-2.  Lieutenants merge the developers' topic branches into their `master` branch.
-3.  The dictator merges the lieutenants' `master` branches into the dictator's `master` branch.
-4.  Finally, the dictator pushes that `master` branch to the reference repository so the other developers can rebase on it.
+این روند کاری رایجی بین ابزارهای هاب-پایه مانند گیت‌هاب و گیت‌لَب است، در این ابزارها فورک کردن یک پروژه و پوش کردن تغییرات‌تان به فورکتان برای همه آسان است.
+یکی از اصلی‌ترین مزیت‌های این روش این است که می‌توانید به کار کردن ادامه دهید و نگهدارندهٔ مخزن اسصلی می‌تواند در هر زمانی پول کند.
+مشارکت‌کنندگان مجبور نیستند منتظر پروژه بمانند تا تغییرات خود را معرفی کنند -- هر گروه می‌تواند با سرعتی که صلاح می‌داند کار کند.
+
+==== روندهای کاری دیکتاتور و ستوانی
+
+ن(((workflows, dictator and lieutenants)))
+این روند، نوعی روند کاری چند-مخزنی است.
+عموماً‌این روش برای پروژه‌های بزرگ با صدها مشارکت‌کننده به کار می‌رود؛ یکی از مثال‌های معروف هستهٔ لینوکس است.
+مدیران یکپارچه‌سازی مختلف مسئول بخش‌های مختلف پروژه هستند؛ به آنها _ستوان_ (Lieutenant) گفته می‌شود.
+همهٔ ستوان‌ها یک مدیر یکپارچه‌سازی به نام دیکتاتور کریم دارند.
+دیکتاتور کریم از پوشهٔ خود به یک مخزن مرجع پوش می‌کند که همهٔ مشارکت‌کنندگان مستلزم پول کردن از آن هستند.
+فرآیند به این شکل کار می‌کند (<<wfdiag_c>> را ببینید):
+
+1.  توسعه‌دهندگان معمولی روی برنچ موضوعی خود کار می‌کنند و تغییرات را به نوک `master` ریبیس می‌کنند.
+    برنچ `master` آن برنچی از مخزن مرجع است که دیکتاتور به آن پوش می‌کند.
+2.  ستوان‌ها برنچ‌های موضوعی توسعه‌دهندگان را به برنچ `master` خود پوش می‌کنند.
+3.  دیکتاتور برنچ‌های `master` ستوان‌ها را با `master` دیکتاتور ادغام می‌کند.
+4.  در آخر دیکتاتور به آن برنچ `master` در مخزن مرجع پوش می‌کند تا دیگر توسعه‌دهندگان بتوانند روی آن ریبیس کنند.
 
 [[wfdiag_c]]
-.Benevolent dictator workflow.
+.روندکاری رهبر کریم
 image::images/benevolent-dictator.png[Benevolent dictator workflow.]
 
-This kind of workflow isn't common, but can be useful in very big projects, or in highly hierarchical environments.
-It allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them.
+این نوع روند کاری رایج نیست، اما می‌تواند در پروژه‌های بزرگ یا در محیط‌های خیلی سلسله مراتبی مفید باشد.
+به رهبر پروژه (دیکتاتور) این امکان را می‌دهد تا بخش عظیمی از کار را واگذار کند و پیش از یکپارچه‌سازی کد بخش‌های اعظمی از آنرا از جاهای مختلف گردآوری کند.
 
-==== Workflows Summary
+==== خلاصهٔ روندهای کاری
 
-These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow.
-Now that you can (hopefully) determine which workflow combination may work for you, we'll cover some more specific examples of how to accomplish the main roles that make up the different flows.
-In the next section, you'll learn about a few common patterns for contributing to a project.
+انگشت شماری روند کاری رایج وجود دارد که معمولاً با سیستم توزیع‌شده‌ای مانند گیت اجرا می‌شود، اما اکنون می‌بینید که مشتقات بسیار بیشتری قابل پیاده‌سازی است که می‌تواند با روند کاری واقعی شما تطبیق پیدا کند.
+حال که (به احتمال زیاد) می‌توانید به اینکه چه ترکیبی از روندهای کاری برای شما مناسب است پی ببرید،
+چند مورد جزئی تر از اینکه «چگونه می‌توان نقش‌های اصلی را به نحوی ایفا کرد که روندهای مختلف را بسازند» بررسی خواهیم کرد.
+در بخش بعد، چند الگوی رایج مشارکت در یک پروژه را یاد خواهید گرفت.