diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc index 938a7e6e..bd87e8f1 100644 --- a/TRANSLATION_NOTES.asc +++ b/TRANSLATION_NOTES.asc @@ -39,6 +39,7 @@ https://github.com/progit/progit2-uk/issues?q=is%3Aopen+is%3Aissue+label%3A%D0%9 *branching*:: галуження *checkout*:: отримання (файлу), переключення (на гілку) *checkout, to*:: отримати (файл), переключитися (на гілку) +*cherry pick*:: висмикнути *command line*:: командний рядок *commit*:: коміт *commited*:: *НЕ УЗГОДЖЕНО* збережений/закомічений/зафіксований diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index b237c5be..a0ed8e43 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -1,108 +1,108 @@ [[_contributing_project]] -=== Contributing to a Project +=== Внесення змін до проекту (((contributing))) -The main difficulty with describing how to contribute to a project is that there are a huge number of variations on how it's done. -Because Git is very flexible, people can and do work together in many ways, and it's problematic to describe how you should contribute – every project is a bit different. -Some of the variables involved are active contributor count, chosen workflow, your commit access, and possibly the external contribution method. - -The first variable is active contributor count – how many users are actively contributing code to this project, and how often? -In many instances, you'll have two or three developers with a few commits a day, or possibly less for somewhat dormant projects. -For larger companies or projects, the number of developers could be in the thousands, with hundreds or thousands of commits coming in each day. -This is important because with more and more developers, you run into more issues with making sure your code applies cleanly or can be easily merged. -Changes you submit may be rendered obsolete or severely broken by work that is merged in while you were working or while your changes were waiting to be approved or applied. -How can you keep your code consistently up to date and your commits valid? - -The next variable is the workflow in use for the project. -Is it centralized, with each developer having equal write access to the main codeline? -Does the project have a maintainer or integration manager who checks all the patches? -Are all the patches peer-reviewed and approved? -Are you involved in that process? -Is a lieutenant system in place, and do you have to submit your work to them first? - -The next issue is your commit access. -The workflow required in order to contribute to a project is much different if you have write access to the project than if you don't. -If you don't have write access, how does the project prefer to accept contributed work? -Does it even have a policy? -How much work are you contributing at a time? -How often do you contribute? - -All these questions can affect how you contribute effectively to a project and what workflows are preferred or available to you. -We'll cover aspects of each of these in a series of use cases, moving from simple to more complex; you should be able to construct the specific workflows you need in practice from these examples. +Дуже складно описати як зробити внесок до проекту, через те, що існує неосяжна кількість варіантів того, як це робиться. +Оскільки Git дуже гнучкий, люди можуть співпрацювати різноманітними методами, і дуже проблематично описати, як вам слід робити внесок – кожен проект трохи своєрідний. +Ось деякі зі змінних, що впливають на це: кількість активних учасників, вибраний процес роботи, чи є у вас доступ на запис, та можливо метод внеску ззовні. + +Перша змінна -- кількість активних учасників – скільки користувачів активно роблять внески коду до проекту, та як часто? +У багатьох випадках, у вас буде два або три розробника з декількома комітами на день, чи навіть менше для дещо неактивних проектів. +Для більших компаній чи проектів, кількість розробників може вимірюватись тисячами, з сотнями або тисячами комітів щодня. +Це важливо, адже зі збільшенням кількості розробників, виникає все більше проблем з тим, щоб переконатись, що код правильно застосовується та може бути легко злитим. +Зміни, які ви надсилаєте, можуть виявитись застарілими, або геть зламаними роботою, яка була злита, доки ви працювали або доки ваші зміни очікували на схвалення та застосування. +Як ви можете зберігати ваш код постійно оновленим, а коміти правильними? + +Наступною змінною є те, який процес роботи використовується в проекті. +Він централізований, та кожен розробник має рівне право запису до головної лінії коду? +Чи є в проекті супроводжувач чи менеджер інтеграції, який перевіряє всі латки (patch)? +Чи всі латки перевіряються іншими та схвалюються? +Чи ви приймаєте участь в цьому процесі? +Чи може використовується система лейтенантів, і необхідно спочатку надіслати свою роботу до них? + +Наступним питанням є ваш доступ до проекту. +Необхідний процес роботи для внеску до проекту є дуже відмінним в залежності від того, чи маєте ви доступ на запис до проекту, чи ні. +Якщо у вас немає доступу на запис, як проект воліє приймати вашу роботу? +Чи є в нього хоча б якісь правила? +Скільки роботи ви збираєтесь надсилати за раз? +Як часто ви будете це робити? + +Усі ці питання можуть вплинути на те, як робити внесок до проекту ефективно та які процеси роботи є ліпшими чи доступними вам. +Ми розглянемо деталі кожного з них у набір прикладів використання, від простого до складніших; ви маєте бути в змозі створювати специфічні процеси роботи, які вам потрібні на практиці, з цих прикладів. [[_commit_guidelines]] -==== Commit Guidelines +==== Правила щодо комітів -Before we start looking at the specific use cases, here's a quick note about commit messages. -Having a good guideline for creating commits and sticking to it makes working with Git and collaborating with others a lot easier. -The Git project provides a document that lays out a number of good tips for creating commits from which to submit patches – you can read it in the Git source code in the `Documentation/SubmittingPatches` file. +До того, як розпочати з конкретних прикладів використання, наведемо коротеньку нотатку про повідомлення комітів. +Мати добрі правила щодо створення комітів та дотримування їх робить працю з Git та співпрацю з іншими набагато легшою. +Проект Git постачає документ, що викладає чимало гарних порад щодо створення комітів, з яких надсилати латки – ви можете прочитати їх у вихідному коді у файлі `Documentation/SubmittingPatches`. (((git commands, diff, check))) -First, you don't want to submit any whitespace errors. -Git provides an easy way to check for this – before you commit, run `git diff --check`, which identifies possible whitespace errors and lists them for you. - -.Output of `git diff --check`. -image::images/git-diff-check.png[Output of `git diff --check`.] - -If you run that command before committing, you can tell if you're about to commit whitespace issues that may annoy other developers. - -Next, try to make each commit a logically separate changeset. -If you can, try to make your changes digestible – don't code for a whole weekend on five different issues and then submit them all as one massive commit on Monday. -Even if you don't commit during the weekend, use the staging area on Monday to split your work into at least one commit per issue, with a useful message per commit. -If some of the changes modify the same file, try to use `git add --patch` to partially stage files (covered in detail in <<_interactive_staging>>). -The project snapshot at the tip of the branch is identical whether you do one commit or five, as long as all the changes are added at some point, so try to make things easier on your fellow developers when they have to review your changes. -This approach also makes it easier to pull out or revert one of the changesets if you need to later. -<<_rewriting_history>> describes a number of useful Git tricks for rewriting history and interactively staging files – use these tools to help craft a clean and understandable history before sending the work to someone else. - -The last thing to keep in mind is the commit message. -Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. -As a general rule, your messages should start with a single line that's no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation. -The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior – this is a good guideline to follow. -It's also a good idea to use the imperative present tense in these messages. -In other words, use commands. -Instead of ``I added tests for'' or ``Adding tests for,'' use ``Add tests for.'' -Here is a template originally written by Tim Pope: +По-перше, ви не хочете надсилати будь-які помилки пробільних символів. +Git надає легкий спосіб перевірити це – перед тим, як створювати коміт, виконайте `git diff --check`, що знаходить можливі помилки з пробільними символами та надає їх список для вас. + +.Вивід `git diff --check`. +image::images/git-diff-check.png[Вивід `git diff --check`.] + +Якщо виконати цю команду перед створенням коміту, то можна дізнатись, чи будуть проблеми з пробільними символами в цьому коміті, які можуть дратувати інших розробників. + +По-друге, намагайтесь робити кожен коміт логічно окремим набором змін. +Якщо можете, спробуйте робити ваші зміни легкими для сприйняття – не працюйте всі вихідні над пʼятьма різними завданнями та потім створюйте з них усіх один величезний коміт у понеділок. +Навіть якщо ви не робили комітів впродовж вихідних, скористайтесь індексом у понеділок щоб розділити свою роботу принаймні на один коміт для кожного завдання, зі змістовним повідомленням кожного коміту. +Якщо деякі зміни редагують один файл, спробуйте використати `git add --patch`, щоб частково проіндексувати файли (розглянуто докладно в <<_interactive_staging>>). +Відбиток проекту наприкінці гілки однаковий, хоч ви зробите один коміт, хоч пʼять, доки всі зміни додані в якийсь мент, отже спробуйте спростити своїм колегам розробникам перегляд ваших змін. +Цей підхід також сприяє легшому вилученню чи вивертанню (revert) змін, якщо це буде потрібно пізніше. +<<_rewriting_history>> описує чимало корисних хитрощів Git для переписування історії та інтерактивного індексування файлів – використовуйте ці інструменти для виготовлення чистої та зрозумілої історії перед тим, як надсилати вашу роботу іншим. + +Нарешті, не варто забувати про повідомлення комітів. +Якщо взяти за звичку створювати якісні повідомлення комітів, то використання та співпраця з Git стає значно легшою. +За загальним правилом, повідомлення мають починатися з єдиного рядка, який містить не більш ніж приблизно 50 символів та описує набір змін змістовно, після яким є порожній рядок, за яким іде більш докладне пояснення. +Проект Git вимагає, щоб докладніше пояснення включало мотивацію зміни та описувало різницю з попередньою поведінкою – це правило варте наслідування. +Також слушно використовувати доконаний вид теперішнього часу в цих повідомленнях. +Іншими словами, використовуйте команди. +Замість ``Я додав тести для'' чи ``Додаю тести для,'' використовуйте ``Додати тести для.'' +Ось шаблон, автором якого є Тім Поуп: [source,text] ----- -Short (50 chars or less) summary of changes +Стислий (50 символів або менше) підсумок змін -More detailed explanatory text, if necessary. Wrap it to -about 72 characters or so. In some contexts, the first -line is treated as the subject of an email and the rest of -the text as the body. The blank line separating the -summary from the body is critical (unless you omit the body -entirely); tools like rebase can get confused if you run -the two together. +Докладніший пояснювальний текст, якщо потрібно. Розбивайте +рядки по приблизно 72 символи. У деяких ситуаціях, перший +рядок сприймається як заголовок електронного листа, а +решка як текст тіла листа. Порожній рядок відділяє підсумок +від тіла і є необхідним (хіба ви взагалі не пишете тіло); +такі інструменти як перебазування можуть заплутатися, порожнього +рядка не буде. -Further paragraphs come after blank lines. +Подальші параграфи йдуть після порожнього рядка. - - Bullet points are okay, too + - Маркери елементів списку теж можна використовувати. - - Typically a hyphen or asterisk is used for the bullet, - preceded by a single space, with blank lines in - between, but conventions vary here + - Зазвичай як маркер використовують дефіс або зірочку, + перед якими є єдиний пробіл, з порожніми рядками між + елементами, проте домовленості щодо цього різняться ----- -If all your commit messages look like this, things will be a lot easier for you and the developers you work with. -The Git project has well-formatted commit messages – try running `git log --no-merges` there to see what a nicely formatted project-commit history looks like. +Якщо ваші повідомлення комітів виглядають саме так, то всім працюючим над проектом буде значно легше. +Проект Git має добре оформлені повідомлення комітів – спробуйте виконати для нього `git log --no-merges`, і побачите, як виглядає історія відформатованих комітів проекту. -In the following examples, and throughout most of this book, for the sake of brevity this book doesn't have nicely-formatted messages like this; instead, we use the `-m` option to `git commit`. -Do as we say, not as we do. +У наступних прикладах, і протягом решти книги, заради стислості, ця книга не буде використовувати такі охайно оформлені повідомлення; натомість, ми використовуємо опцію `-m` команди `git commit`. +Робіть як ми кажемо, а не як ми робимо. [[_private_team]] -==== Private Small Team +==== Маленька закрита команда (((contributing, private small team))) -The simplest setup you're likely to encounter is a private project with one or two other developers. -``Private,'' in this context, means closed-source – not accessible to the outside world. -You and the other developers all have push access to the repository. +Найпростіший випадок, який ви можете зустріти -- це закритий проект з одним чи двома іншими розробниками. +``Закритий,'' у цьому контексті, означає зі закритим вихідним кодом – недоступним зовнішньому світу. +Ви та інші розробники всі мають доступ на запис до репозиторію. -In this environment, you can follow a workflow similar to what you might do when using Subversion or another centralized system. -You still get the advantages of things like offline committing and vastly simpler branching and merging, but the workflow can be very similar; the main difference is that merges happen client-side rather than on the server at commit time. -Let's see what it might look like when two developers start to work together with a shared repository. -The first developer, John, clones the repository, makes a change, and commits locally. -(The protocol messages have been replaced with `...` in these examples to shorten them somewhat.) +У такому середовищі, ви можете працювати за процесом роботи, схожим на той, за яким ви могли працювали при користуванні Subversion чи іншої централізованої системи. +Ви все одно отримуєте такі переваги, як створення комітів поза мережею та неймовірно простіше галуження та зливання, проте процес роботи може бути дуже схожим: головною відмінністю є те, що зливання здійснюються на клієнті, а не на сервері під час створення коміту. +Погляньмо, як це працює, коли два розробника починають працювати разом над спільним сховищем. +Перший розробник, Джон, клонує репозиторій, робить зміни й створює коміти локально. +(Повідомлення протоколу замінені на `...` у цих прикладах, щоб дещо скоротити їх.) [source,console] ----- @@ -117,7 +117,7 @@ $ git commit -am 'removed invalid default value' 1 files changed, 1 insertions(+), 1 deletions(-) ----- -The second developer, Jessica, does the same thing – clones the repository and commits a change: +Друга розробниця, Джесіка, робить те саме – клонує сховище та створює коміт зі змінами: [source,console] ----- @@ -132,7 +132,7 @@ $ git commit -am 'add reset task' 1 files changed, 1 insertions(+), 0 deletions(-) ----- -Now, Jessica pushes her work up to the server: +Тепер, Джесіка надсилає свою працю до сервера: [source,console] ----- @@ -143,7 +143,7 @@ To jessica@githost:simplegit.git 1edee6b..fbff5bc master -> master ----- -John tries to push his change up, too: +Джон також намагається надіслати свої зміни: [source,console] ----- @@ -154,10 +154,10 @@ To john@githost:simplegit.git error: failed to push some refs to 'john@githost:simplegit.git' ----- -John isn't allowed to push because Jessica has pushed in the meantime. -This is especially important to understand if you're used to Subversion, because you'll notice that the two developers didn't edit the same file. -Although Subversion automatically does such a merge on the server if different files are edited, in Git you must merge the commits locally. -John has to fetch Jessica's changes and merge them in before he will be allowed to push: +Джону не дозволено це зробити, адже Джесіка вже встигла надіслати зміни тим часом. +Це особливо важливо зрозуміти, якщо ви звикли до Subversion, оскільки ви помітите, що два розробники не редагували один і той самий файл. +Хоча Subversion автоматично робить таке злиття на сервері, якщо різні файли були редаговані, у Git ви змушені зливати коміти локально. +Джон має отримати зміни Джесіки та злити їх разом перед тим, як йому буде дозволено їх надіслати: [source,console] ----- @@ -167,12 +167,12 @@ From john@githost:simplegit + 049d078...fbff5bc master -> origin/master ----- -At this point, John's local repository looks something like this: +Наразі, локальне сховище Джона виглядає приблизно так: -.John's divergent history. -image::images/small-team-1.png[John's divergent history.] +.Історія Джона, що розбіглася. +image::images/small-team-1.png[Історія Джона, що розбіглася.] -John has a reference to the changes Jessica pushed up, but he has to merge them into his own work before he is allowed to push: +Джон має посилання на зміни, надіслані Джесікою, проте йому треба злити їх зі своєю власною роботою до того, як йому буде дозволено надіслати зміни: [source,console] ----- @@ -182,12 +182,12 @@ Merge made by recursive. 1 files changed, 1 insertions(+), 0 deletions(-) ----- -The merge goes smoothly – John's commit history now looks like this: +Злиття проходить гладко – тепер історія комітів Джона виглядає так: -.John's repository after merging `origin/master`. -image::images/small-team-2.png[John's repository after merging `origin/master`.] +.Репозиторій Джона після зливання `origin/master`. +image::images/small-team-2.png[Репозиторій Джона після зливання `origin/master`.] -Now, John can test his code to make sure it still works properly, and then he can push his new merged work up to the server: +Тепер, Джон може перевірити код, щоб переконатися, що все продовжує працювати належним чином, та потім може надіслати свою нову злиту роботу до сервера: [source,console] ----- @@ -197,19 +197,19 @@ To john@githost:simplegit.git fbff5bc..72bbc59 master -> master ----- -Finally, John's commit history looks like this: +Нарешті, історія комітів Джона виглядає так: -.John's history after pushing to the `origin` server. -image::images/small-team-3.png[John's history after pushing to the `origin` server.] +.Історія Джона після надсилання до сервера `origin`. +image::images/small-team-3.png[Історія Джона після надсилання до сервера `origin`.] -In the meantime, Jessica has been working on a topic branch. -She's created a topic branch called `issue54` and done three commits on that branch. -She hasn't fetched John's changes yet, so her commit history looks like this: +Тим часом, Джесіка працювала над тематичною гілкою. +Вона створила тематичну гілку під назвою `issue54` та створила в ній три коміти. +Вона не отримувала зміни Джона покищо, отже її історія комітів виглядає так: -.Jessica's topic branch. -image::images/small-team-4.png[Jessica's topic branch.] +.Тематична гілка Джесіки. +image::images/small-team-4.png[Тематична гілка Джесіки.] -Jessica wants to sync up with John, so she fetches: +Джесіка бажає синхронізуватися з Джоном, отже вона отримує зміни: [source,console] ----- @@ -220,14 +220,14 @@ From jessica@githost:simplegit fbff5bc..72bbc59 master -> origin/master ----- -That pulls down the work John has pushed up in the meantime. -Jessica's history now looks like this: +Це стягує роботу Джона, яку він встиг надіслати. +Історія Джесіки тепер виглядає так: -.Jessica's history after fetching John's changes. -image::images/small-team-5.png[Jessica's history after fetching John's changes.] +.Історія Джесіки після отримання змін Джона. +image::images/small-team-5.png[Історія Джесіки після отримання змін Джона.] -Jessica thinks her topic branch is ready, but she wants to know what she has to merge into her work so that she can push. -She runs `git log` to find out: +Джесіка вважає, що її тематична гілка готова, проте бажає знати, що їй доведеться зливати зі своєю роботою, щоб мати можливість надіслати зміни. +Вона виконує `git log`, щоб дізнатися: [source,console] ----- @@ -239,12 +239,12 @@ Date: Fri May 29 16:01:27 2009 -0700 removed invalid default value ----- -The `issue54..origin/master` syntax is a log filter that asks Git to only show the list of commits that are on the latter branch (in this case `origin/master`) that are not on the first branch (in this case `issue54`). We'll go over this syntax in detail in <<_commit_ranges>>. +Синтаксис `issue54..origin/master` є фільтром журналу, який просить Git показувати лише список комітів з другої гілки (у даному випадку `origin/master`), яких немає в першій гілці (у даному випадку `issue54`). Ми розглянемо цей синтаксис докладно в <<_commit_ranges>>. -For now, we can see from the output that there is a single commit that John has made that Jessica has not merged in. If she merges `origin/master`, that is the single commit that will modify her local work. +Покищо, ми можемо бачити з виводу, що існує єдиний коміт, який створив Джон та Джесіка ще не злила. Якщо вона зіллє `origin/master`, це єдиний коміт, який змінить її локальну працю. -Now, Jessica can merge her topic work into her master branch, merge John's work (`origin/master`) into her `master` branch, and then push back to the server again. -First, she switches back to her master branch to integrate all this work: +Тепер, Джесіка може злити її тематичну працю до своєї гілки master, зливає роботу Джона (`origin/master`) до гілки `master`, а потім надсилає зміни назад до сервера знову. +Спершу, вона переключається назад до своєї гілки master, щоб обʼєднати зі своєю роботою: [source,console] ----- @@ -254,8 +254,9 @@ Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. ----- She can merge either `origin/master` or `issue54` first – they're both upstream, so the order doesn't matter. -The end snapshot should be identical no matter which order she chooses; only the history will be slightly different. -She chooses to merge in `issue54` first: +Вона може злити спочатку хоч `origin/master`, хоч `issue54` – вони обидві готові, отже порядок не є важливим. +Відбиток у результаті буде однаковим незалежно від порядку, який вона вибере; лише історія буде трохи різною. +Вона вирішує злити спочатку `issue54`: [source,console] ----- @@ -267,8 +268,8 @@ Fast forward 2 files changed, 6 insertions(+), 1 deletions(-) ----- -No problems occur; as you can see it was a simple fast-forward. -Now Jessica merges in John's work (`origin/master`): +Ніякі проблеми не трапляються; як бачите, це просте перемотування вперед (fast-forward). +Тепер Джесіка зливає роботу Джона (`origin/master`): [source,console] ----- @@ -279,12 +280,12 @@ Merge made by recursive. 1 files changed, 1 insertions(+), 1 deletions(-) ----- -Everything merges cleanly, and Jessica's history looks like this: +Усе зливається чисто, й історія Джесіки виглядає так: -.Jessica's history after merging John's changes. -image::images/small-team-6.png[Jessica's history after merging John's changes.] +.Історія Джесіки після зливання змін Джона. +image::images/small-team-6.png[Історія Джесіки після зливання змін Джона.] -Now `origin/master` is reachable from Jessica's `master` branch, so she should be able to successfully push (assuming John hasn't pushed again in the meantime): +Тепер `origin/master` є досяжним з гілки `master` Джесіки, отже вона має бути в змозі успішно надіслати зміни (припускаючи, що Джон не надіслав щось знову тим часом): [source,console] ----- @@ -294,32 +295,32 @@ To jessica@githost:simplegit.git 72bbc59..8059c15 master -> master ----- -Each developer has committed a few times and merged each other's work successfully. +Кожен розробник створив декілька комітів та успішно зливав роботу іншого. -.Jessica's history after pushing all changes back to the server. -image::images/small-team-7.png[Jessica's history after pushing all changes back to the server.] +.Історія Джесіки після надсилання змін назад до сервера. +image::images/small-team-7.png[Історія Джесіки після надсилання змін назад до сервера.] -That is one of the simplest workflows. -You work for a while, generally in a topic branch, and merge into your master branch when it's ready to be integrated. -When you want to share that work, you merge it into your own master branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. -The general sequence is something like this: +Це один з найпростіших процесів роботи. +Ви працюєте деякий час, зазвичай у тематичній гілці, та зливаєте до своєї гілки master, коли все готово. +Коли ви бажаєте надати доступ до своєї роботи, треба злити її до власної гілки master, потім отримати (fetch) та злити `origin/master`, якщо вона змінилася, та нарешті надіслати гілку `master` до сервера. +Загальна послідовність виглядає приблизно так: -.General sequence of events for a simple multiple-developer Git workflow. -image::images/small-team-flow.png[General sequence of events for a simple multiple-developer Git workflow.] +.Загальна послідовність подій для простого процесу роботи декількох розробників з Git. +image::images/small-team-flow.png[Загальна послідовність подій для простого процесу роботи декількох розробників з Git.] -==== Private Managed Team +==== Закрита керована команда (((contributing, private managed team))) -In this next scenario, you'll look at contributor roles in a larger private group. -You'll learn how to work in an environment where small groups collaborate on features and then those team-based contributions are integrated by another party. +У цьому наступному варіанті, подивимось на ролі учасників у більшій закритій групі. +Ви дізнаєтесь, як працювати в середовищі, де невеличка група співпрацює над функціоналом, а потім їхні командні внески інтегруються кимось іншим. -Let's say that John and Jessica are working together on one feature, while Jessica and Josie are working on a second. -In this case, the company is using a type of integration-manager workflow where the work of the individual groups is integrated only by certain engineers, and the `master` branch of the main repo can be updated only by those engineers. -In this scenario, all work is done in team-based branches and pulled together by the integrators later. +Скажімо, Джон та Джесіка працюють разом над однією функцією, у той час як Джесіка з Джосі працюють над іншою. +У цьому випадку, компанія використовує різновид процесу роботи з менеджером інтеграції, в якому праця окремих груп інтегрується виключно окремими інженерами, і гілка `master` головного сховища може бути оновленою лише цими інженерами. +У цьому сценарії, вся праця відбувається у командних гілках, а пізніше стягується разом інтеграторами. -Let's follow Jessica's workflow as she works on her two features, collaborating in parallel with two different developers in this environment. -Assuming she already has her repository cloned, she decides to work on `featureA` first. -She creates a new branch for the feature and does some work on it there: +Прослідкуймо за процесом роботи Джесіки, адже вона працює над двома функціями та паралельно співпрацює з двома розробниками в цьому середовищі. +Припускаючи, що вона вже створила клон репозиторію, вона вирішує спочатку працювати над `featureA`. +Вона створює нову гілку для цієї функції та щось в ній робить: [source,console] ----- @@ -332,8 +333,8 @@ $ git commit -am 'add limit to log function' 1 files changed, 1 insertions(+), 1 deletions(-) ----- -At this point, she needs to share her work with John, so she pushes her `featureA` branch commits up to the server. -Jessica doesn't have push access to the `master` branch – only the integrators do – so she has to push to another branch in order to collaborate with John: +Тепер їй треба поділитись своєю роботою з Джоном, отже вона надсилає коміти своєї гілки `featureA` до сервера. +Джесіка не має доступу на запис до гілки `master` – він є лише в інтеграторів – отже вона має надсилати до іншої гілки, щоб співпрацювати з Джоном: [source,console] ----- @@ -343,9 +344,9 @@ To jessica@githost:simplegit.git * [new branch] featureA -> featureA ----- -Jessica e-mails John to tell him that she's pushed some work into a branch named `featureA` and he can look at it now. -While she waits for feedback from John, Jessica decides to start working on `featureB` with Josie. -To begin, she starts a new feature branch, basing it off the server's `master` branch: +Джесіка пише листа Джону, щоб повідомити про створену нею гілку `featureA` з її роботою, і тепер він може переглянути її. +Доки вона чекає на відгук від Джона, Джесіка вирішує розпочати працю над `featureB` разом з Джосі. +Спочатку, вона створює нову функціональну гілку, засновану на гілці `master` з сервера: [source,console] ----- @@ -355,7 +356,7 @@ $ git checkout -b featureB origin/master Switched to a new branch 'featureB' ----- -Now, Jessica makes a couple of commits on the `featureB` branch: +Тепер, Джесіка робить декілька комітів у гілці `featureB`: [source,console] ----- @@ -369,14 +370,14 @@ $ git commit -am 'add ls-files' 1 files changed, 5 insertions(+), 0 deletions(-) ----- -Jessica's repository looks like this: +Сховище Джесіки виглядає так: -.Jessica's initial commit history. -image::images/managed-team-1.png[Jessica's initial commit history.] +.Початкова історія комітів Джесіки. +image::images/managed-team-1.png[Початкова історія комітів Джесіки.] -She's ready to push up her work, but gets an e-mail from Josie that a branch with some initial work on it was already pushed to the server as `featureBee`. -Jessica first needs to merge those changes in with her own before she can push to the server. -She can then fetch Josie's changes down with `git fetch`: +Вона готова надсилати свою роботу, проте отримує листа від Джосі про те, що гілка з розпочатою роботою вже надіслана до сервера з ім’ям `featureBee`. +Джесіка спершу має злити ці зміни зі своїми, щоб мати змогу надіслати до сервера. +Вона може отримати зміни Джосі за допомогою `git fetch`: [source,console] ----- @@ -386,7 +387,7 @@ From jessica@githost:simplegit * [new branch] featureBee -> origin/featureBee ----- -Jessica can now merge this into the work she did with `git merge`: +Джесіка тепер може злити їх з власною працею за допомогою `git merge`: [source,console] ----- @@ -397,8 +398,9 @@ Merge made by recursive. 1 files changed, 4 insertions(+), 0 deletions(-) ----- -There is a bit of a problem – she needs to push the merged work in her `featureB` branch to the `featureBee` branch on the server. +Є маленька проблема – їй треба надіслати злиту в гілці `featureB` роботу надіслати до гілки `featureBee` на сервері. She can do so by specifying the local branch followed by a colon (:) followed by the remote branch to the `git push` command: +Вона може це зробити: треба задати команді `git push` локальну гілку, потім двокрапку (:), потім ім’я віддаленої гілки: [source,console] ----- @@ -408,12 +410,12 @@ To jessica@githost:simplegit.git fba9af8..cd685d1 featureB -> featureBee ----- -This is called a _refspec_. -See <<_refspec>> for a more detailed discussion of Git refspecs and different things you can do with them. -Also notice the `-u` flag; this is short for `--set-upstream`, which configures the branches for easier pushing and pulling later. +Це називається _визпос_ (refspec, визначення посилання). +Дивіться <<_refspec>> задля докладнішої дискусії про визпоси Git та різноманітні речі, які з ними можна робити. +Також зверніть увагу на опцію `-u`; це скорочення для `--set-upstream`, яка налаштовує гілки для легшого подальшого надсилання та отримання змін. -Next, John e-mails Jessica to say he's pushed some changes to the `featureA` branch and asks her to verify them. -She runs a `git fetch` to pull down those changes: +Далі, Джон пише Джесиці про те, що надіслав деякі зміни до гілки `featureA` та просить її перевірити їх. +Вона виконує `git fetch`, щоб отримати ці зміни: [source,console] ----- @@ -423,7 +425,7 @@ From jessica@githost:simplegit 3300904..aad881d featureA -> origin/featureA ----- -Then, she can see what has been changed with `git log`: +Потім може подивитися, що змінилося за допомогою `git log`: [source,console] ----- @@ -435,7 +437,7 @@ Date: Fri May 29 19:57:33 2009 -0700 changed log output to 30 from 25 ----- -Finally, she merges John's work into her own `featureA` branch: +Нарешті, вона зливає працю Джона з власною гілкою `featureA`: [source,console] ----- @@ -448,7 +450,7 @@ Fast forward 1 files changed, 9 insertions(+), 1 deletions(-) ----- -Jessica wants to tweak something, so she commits again and then pushes this back up to the server: +Джесіка бажає щось підлагодити, отже вона знову створює коміт та надсилає його назад до сервера: [source,console] ----- @@ -461,36 +463,37 @@ To jessica@githost:simplegit.git 3300904..774b3ed featureA -> featureA ----- -Jessica's commit history now looks something like this: +Історія комітів Джесіки тепер виглядає так: -.Jessica's history after committing on a feature branch. -image::images/managed-team-2.png[Jessica's history after committing on a feature branch.] +.Історія Джесіки після створення комітів у функціональних гілках. +image::images/managed-team-2.png[Історія Джесіки після створення комітів у функціональних гілках.] -Jessica, Josie, and John inform the integrators that the `featureA` and `featureBee` branches on the server are ready for integration into the mainline. -After the integrators merge these branches into the mainline, a fetch will bring down the new merge commit, making the history look like this: +Джесіка, Джосі та Джон повідомляють інтеграторів, що гілки `featureA` та `featureBee` на сервері готові для інтеграції до стрижневої гілки. +Після того, як інтегратори зіллють ці гілки до стрижневої, отримання змін додасть новий коміт злиття, що зробить історію такою: -.Jessica's history after merging both her topic branches. -image::images/managed-team-3.png[Jessica's history after merging both her topic branches.] +.Історія Джесіки після зливання обох її тематичних гілок. +image::images/managed-team-3.png[Історія Джесіки після зливання обох її тематичних гілок.] -Many groups switch to Git because of this ability to have multiple teams working in parallel, merging the different lines of work late in the process. -The ability of smaller subgroups of a team to collaborate via remote branches without necessarily having to involve or impede the entire team is a huge benefit of Git. -The sequence for the workflow you saw here is something like this: +Чимало груп переходять на Git через цю можливість декільком командам паралельно працювати, та зливати різні лінії роботи пізніше. +Здатність менших підгруп команди співпрацювати за допомогою віддалених гілок без необхідності залучати чи затримувати всю команду є великою перевагою Git. +Послідовність для процесу роботи, який ви бачили тут, виглядає приблизно так: -.Basic sequence of this managed-team workflow. -image::images/managed-team-flow.png[Basic sequence of this managed-team workflow.] +.Базова послідовність цього процесу роботи керованої команди. + +image::images/managed-team-flow.png[Базова послідовність цього процесу роботи керованої команди.] [[_public_project]] -==== Forked Public Project +==== Відкритий проект з форками (((contributing, public small project))) -Contributing to public projects is a bit different. -Because you don't have the permissions to directly update branches on the project, you have to get the work to the maintainers some other way. -This first example describes contributing via forking on Git hosts that support easy forking. -Many hosting sites support this (including GitHub, BitBucket, Google Code, repo.or.cz, and others), and many project maintainers expect this style of contribution. -The next section deals with projects that prefer to accept contributed patches via e-mail. +Внески до відкритих проектів роблять дещо інакше. +Оскільки у вас немає права оновлювати гілки проекту напряму, ви маєте доправити свої зміни до супроводжувачів іншим чином. +Перший приклад описує внески за допомогою форків на хостах Git, які підтримують легке створення форків. +Багато сайтів розгортання підтримують це (включно з GitHub, BitBucket, Google Code, repo.or.cz тощо), та багато супроводжувачів проектів очікують внесків у такому вигляді. +Наступна секція розгляне проекти, які бажають приймати внески електронною поштою у вигляді латок (patches). -First, you'll probably want to clone the main repository, create a topic branch for the patch or patch series you're planning to contribute, and do your work there. -The sequence looks basically like this: +Спочатку, ви вірогідно забажаєте створити клон головного сховища, створити тематичну гілку для латки чи низки латок, які ви плануєте внести, та попрацювати там. +Ось базова послідовність для цього: [source,console] ----- @@ -505,21 +508,21 @@ $ git commit [NOTE] ==== -You may want to use `rebase -i` to squash your work down to a single commit, or rearrange the work in the commits to make the patch easier for the maintainer to review – see <<_rewriting_history>> for more information about interactive rebasing. +Можливо, ви забажаєте використати `rebase -i`, щоб зчавити (squash) свою працю до єдиного коміту, або переставити коміти, щоб супроводжувачу було легше переглянути латку – дивіться <<_rewriting_history>> задля детальнішої інформації про інтерактивне перебазування. ==== -When your branch work is finished and you're ready to contribute it back to the maintainers, go to the original project page and click the ``Fork'' button, creating your own writable fork of the project. -You then need to add in this new repository URL as a second remote, in this case named `myfork`: +Колив ваша робота в гілці завершена, і ви готові направити внесок до супроводжувачів, перейдіть до сторінки оригінального проекту та натисніть кнопку ``Форк'', що створить ваш власний форк проекту, в який ви маєте право писати. +Потім вам потрібно додати URL цього нового сховища як друге віддалене сховище, у даному випадку названого `myfork`: [source,console] ----- $ git remote add myfork (url) ----- -Then you need to push your work up to it. -It's easiest to push the topic branch you're working on up to your repository, rather than merging into your master branch and pushing that up. -The reason is that if the work isn't accepted or is cherry picked, you don't have to rewind your master branch. -If the maintainers merge, rebase, or cherry-pick your work, you'll eventually get it back via pulling from their repository anyhow: +Потім треба надіслати до нього свою працю. +Найлегше надіслати тематичну гілку, над якою ви працюєте, до вашого сховища замість того, щоб зливати до вашої гілки master та надсилати її. +Так краще, адже якщо вашу роботу не приймуть, або її висмикнуть (cherry pick), то не доведеться перемотувати гілку master. +Якщо супроводжувачі зіллють, перебазують або висмикнуть вашу працю, ви зрештою отримаєте її при отриманні з їхнього сховища в будь-якому разі: [source,console] ----- @@ -527,11 +530,11 @@ $ git push -u myfork featureA ----- (((git commands, request-pull))) -When your work has been pushed up to your fork, you need to notify the maintainer. -This is often called a pull request, and you can either generate it via the website – GitHub has its own Pull Request mechanism that we'll go over in <<_github>> – or you can run the `git request-pull` command and e-mail the output to the project maintainer manually. +Коли ваша робота надіслана до вашого форку, потрібно повідомити супроводжувачів. +Це, зазвичай, називають pull request, і ви можете або згенерувати його за допомогою сайту – GitHub має власний механізм Pull Request, яким ми розглянемо в <<_github>> – або можете виконати команду `git request-pull` та надіслати її вивід поштою до супроводжувачів проекту вручну. -The `request-pull` command takes the base branch into which you want your topic branch pulled and the Git repository URL you want them to pull from, and outputs a summary of all the changes you're asking to be pulled in. -For instance, if Jessica wants to send John a pull request, and she's done two commits on the topic branch she just pushed up, she can run this: +Команда `request-pull` бере базову гілку, до якої ви бажаєте злити тематичну гілку, та URL Git сховища, з якого вони можуть отримати гілку, та виводить стислий опис всіх змін, які ви просите злити. +Наприклад, якщо Джесіка бажає надіслати Джонові pull request та вона зробила два коміти в тематичній гілці, які вона щойно надіслала, вона може виконати це: [source,console] ----- @@ -552,11 +555,11 @@ Jessica Smith (2): 1 files changed, 9 insertions(+), 1 deletions(-) ----- -The output can be sent to the maintainer–it tells them where the work was branched from, summarizes the commits, and tells where to pull this work from. +Вивід може бути надісланий супроводжувачу – у ньому повідомляється, звідки робота відгалузилась, підбиває підсумки комітів та каже звідки можна отримати ці зміни. -On a project for which you're not the maintainer, it's generally easier to have a branch like `master` always track `origin/master` and to do your work in topic branches that you can easily discard if they're rejected. -Having work themes isolated into topic branches also makes it easier for you to rebase your work if the tip of the main repository has moved in the meantime and your commits no longer apply cleanly. -For example, if you want to submit a second topic of work to the project, don't continue working on the topic branch you just pushed up – start over from the main repository's `master` branch: +У проекті, в якому ви не є супроводжувачем, зазвичай легше, щоб гілка `master` завжди слідкувала за `origin/master`, та працювати в тематичних гілках, які можна легко скасувати, якщо їх відкинули. +Ще однією перевагою ізолювання напрямків роботи в тематичних гілках є те, що це полегшує перебазування вашої праці, якщо вершина головного сховища пересунулась за цей час та ваші коміти більше не застосовуються чисто. +Наприклад, якщо ви бажаєте подати на розгляд другу тему до проекту, не продовжуйте працювати в щойно надісланій тематичній гілці – почніть спочатку з гілки `master` головного сховища. [source,console] ----- @@ -568,13 +571,13 @@ $ git push myfork featureB $ git fetch origin ----- -Now, each of your topics is contained within a silo – similar to a patch queue – that you can rewrite, rebase, and modify without the topics interfering or interdepending on each other, like so: +Тепер, кожна з ваших тем міститься в зерносховищі – щось схоже на чергу латок – їх можна переписувати, перебазовувати, змінювати без взаємних завад чи залежностей, наприклад: -.Initial commit history with `featureB` work. -image::images/public-small-1.png[Initial commit history with `featureB` work.] +.Початкова історія комітів з роботою `featureB`. +image::images/public-small-1.png[Початкова історія комітів з роботою `featureB`.] -Let's say the project maintainer has pulled in a bunch of other patches and tried your first branch, but it no longer cleanly merges. -In this case, you can try to rebase that branch on top of `origin/master`, resolve the conflicts for the maintainer, and then resubmit your changes: +Скажімо, супроводжувач проекту отримав купу інших латок та спробували вашу першу гілку, проте вона вже не зливається чисто. +У цьому випадку, ви можете спробувати перебазувати цю гілку поверху `origin/master`, розв’язати конфлікти для супроводжувачів, та надати свої зміни знову: [source,console] ----- @@ -583,18 +586,18 @@ $ git rebase origin/master $ git push -f myfork featureA ----- -This rewrites your history to now look like <>. +Це переписує вашу історію, і тепер вона виглядає як <>. [[psp_b]] -.Commit history after `featureA` work. -image::images/public-small-2.png[Commit history after `featureA` work.] +.Історія комітів після праці в `featureA`. +image::images/public-small-2.png[Історія комітів після праці в `featureA`.] -Because you rebased the branch, you have to specify the `-f` to your push command in order to be able to replace the `featureA` branch on the server with a commit that isn't a descendant of it. -An alternative would be to push this new work to a different branch on the server (perhaps called `featureAv2`). +Оскільки ви перебазували гілку, доводиться задати `-f` до команди push, щоб замінити гілку `featureA` на сервері комітом, який не є її нащадком. +Альтернативно, можна було надіслати цю нову працю до іншої гілки на сервері (можливо названу `featureAv2`). -Let's look at one more possible scenario: the maintainer has looked at work in your second branch and likes the concept but would like you to change an implementation detail. -You'll also take this opportunity to move the work to be based off the project's current `master` branch. -You start a new branch based off the current `origin/master` branch, squash the `featureB` changes there, resolve any conflicts, make the implementation change, and then push that up as a new branch: +Подивімося на ще один можливий сценарій: супроводжувач подивився на роботу в другій гілці та схвалює концепцію, проте бажає, щоб ви змінили якусь окрему річ у реалізації. +Ви також скористаєтесь цією можливістю, щоб перебазувати роботу на поточній гілці `master`. +Ви починаєте з нової гілки, відгалуженої від `origin/master`, зчавлюєте в ній зміни `featureB`, розв’язуєте конфлікти, робите зміну в реалізації, та потім надсилаєте зміни назад як нову гілку: (((git commands, merge, squash))) [source,console] @@ -606,25 +609,25 @@ $ git commit $ git push myfork featureBv2 ----- -The `--squash` option takes all the work on the merged branch and squashes it into one changeset producing the repository state as if a real merge happened, without actually making a merge commit. -This means your future commit will have one parent only and allows you to introduce all the changes from another branch and then make more changes before recording the new commit. -Also the `--no-commit` option can be useful to delay the merge commit in case of the default merge process. +Опція `--squash` бере всю роботу з гілки, яку зливають, та зчавлює її в один набір змін, в результаті отримуємо стан репозиторію, ніби справжнє злиття сталося проте без власне створення коміту злиття. +Це означає, що майбутні коміти матимуть лише одного батька, та дозволяє додати всі зміни з іншої гілки, а потім зробити ще деякі зміни до запису нового коміту. +Також опція `--no-commit` може бути корисною, щоб відкласти коміт злиття в разі типового процесу зливання. -Now you can send the maintainer a message that you've made the requested changes and they can find those changes in your `featureBv2` branch. +Тепер ви можете надіслати супроводжувачу повідомлення про те, що ви зробили доручені зміни та ці зміни можна знайти у вашій гілці `featureBv2`. -.Commit history after `featureBv2` work. -image::images/public-small-3.png[Commit history after `featureBv2` work.] +.Історія комітів після роботи над `featureBv2`. +image::images/public-small-3.png[Історія комітів після роботи над `featureBv2`.] [[_project_over_email]] -==== Public Project over E-Mail +==== Відкритий проект за допомогою електронної пошти (((contributing, public large project))) -Many projects have established procedures for accepting patches – you'll need to check the specific rules for each project, because they will differ. -Since there are several older, larger projects which accept patches via a developer mailing list, we'll go over an example of that now. +Багато проектів встановили процедури для прийняття латок – вам треба переглянути специфічні правила для кожного проекту, адже вони будуть різними. +Адже існує декілька старших, більших проектів, які приймають латки через поштовий розсилку розробників (developer mailing list), ми розглянемо приклад цього зараз. -The workflow is similar to the previous use case – you create topic branches for each patch series you work on. -The difference is how you submit them to the project. -Instead of forking the project and pushing to your own writable version, you generate e-mail versions of each commit series and e-mail them to the developer mailing list: +Процес роботи схожий на попередній випадок – ви створюєте тематичні гілки для кожного набору латок, над якими працюєте. +Різниця в тому, як ви надаєте їх проекту. +Замість створення форку проекту та надсилання до власної версії, треба згенерувати поштові версії кожної послідовності комітів та наділати їх поштою до поштової розсилки розробників: [source,console] ----- @@ -636,9 +639,9 @@ $ git commit ----- (((git commands, format-patch))) -Now you have two commits that you want to send to the mailing list. -You use `git format-patch` to generate the mbox-formatted files that you can e-mail to the list – it turns each commit into an e-mail message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body. -The nice thing about this is that applying a patch from an e-mail generated with `format-patch` preserves all the commit information properly. +Тепер у вас є два коміти, які ви бажаєте надіслати до поштової розсилки. +Ви використовуєте `git format-patch` щоб згенерувати файли у форматі mbox, які ви можете відправити електронною поштою до розсилки – вона перетворює кожен коміт на лист, у темі якого зазначено перший рядок повідомлення коміту, а решту повідомлення та латку записує в тіло листа. +Це дуже зручно тим, що застосування латки з листа, який згенеровано за допомогою `format-patch`, відновлює всю інформацію коміту правильно. [source,console] ----- @@ -647,9 +650,9 @@ $ git format-patch -M origin/master 0002-changed-log-output-to-30-from-25.patch ----- -The `format-patch` command prints out the names of the patch files it creates. -The `-M` switch tells Git to look for renames. -The files end up looking like this: +Команда `format-patch` друкує назви файлів з латками, які створює. +Перемикач `-M` каже Git шукати перейменування. +У результаті файли виглядають так: [source,console] ----- @@ -682,17 +685,17 @@ index 76f47bc..f9815f1 100644 2.1.0 ----- -You can also edit these patch files to add more information for the e-mail list that you don't want to show up in the commit message. -If you add text between the `---` line and the beginning of the patch (the `diff --git` line), then developers can read it; but applying the patch excludes it. +Ви також можете редагувати ці файли латок, щоб додати більше інформації до поштової розсилки, яку ви не бажаєте бачити в повідомленні коміту. +Якщо додати текст між рядком `---` та початком латки (рядок `diff --git`), то розробники зможуть прочитати його; проте застосування латки вилучає його. -To e-mail this to a mailing list, you can either paste the file into your e-mail program or send it via a command-line program. -Pasting the text often causes formatting issues, especially with ``smarter'' clients that don't preserve newlines and other whitespace appropriately. -Luckily, Git provides a tool to help you send properly formatted patches via IMAP, which may be easier for you. -We'll demonstrate how to send a patch via Gmail, which happens to be the e-mail agent we know best; you can read detailed instructions for a number of mail programs at the end of the aforementioned `Documentation/SubmittingPatches` file in the Git source code. +Щоб надіслати цього листа до поштової розсилки, ви можете або вставити файл до вашої поштової програми, або надіслати його за допомогою командного рядку. +Вставка тексту здебільшого призводить до помилок формату, особливо з ``розумнішими'' клієнтами, які не зберігають доречно розриви рядків та інші пробільні символи правильно. +На щастя, Git постачає інструмент, щоб допомогти з надсиланням правильно оформлених латок через IMAP, що може бути простішим. +Ми продемонструємо, як надіслати латку через Gmail, який є поштовим агентом, з яким ми найкраще знайомі; ви можете прочитати детальні інструкції для багатьох поштових програм наприкінці згаданого раніше файлу `Documentation/SubmittingPatches` вихідного коду Git. (((git commands, config)))(((email))) -First, you need to set up the imap section in your `~/.gitconfig` file. -You can set each value separately with a series of `git config` commands, or you can add them manually, but in the end your config file should look something like this: +Спершу, вам треба налаштувати секцію imap свого файлу `~/.gitconfig`. +Ви можете встановити кожне значення окремо декількома командами `git config`, або можете додати їх вручну, проте зрештою конфігураційний файл має виглядати приблизно так: [source,ini] ----- @@ -705,8 +708,8 @@ You can set each value separately with a series of `git config` commands, or you sslverify = false ----- -If your IMAP server doesn't use SSL, the last two lines probably aren't necessary, and the host value will be `imap://` instead of `imaps://`. -When that is set up, you can use `git imap-send` to place the patch series in the Drafts folder of the specified IMAP server: +Якщо ваш сервер IMAP не використовує SSL, останні два рядки вірогідно зайві, та значення host буде `imap://` замість `imaps://`. +Коли це налаштовано, ви можете використати `git imap-send`, щоб розмістити послідовність латок у директорії Чернетки (Drafts) зазначеного IMAP сервера: [source,console] ----- @@ -718,9 +721,9 @@ sending 2 messages 100% (2/2) done ----- -At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you're sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off. +Наразі, ви маєте бути в змозі перейти до своєї директорії Чернетки, змінити значення Кому (To) на поштову розсилку, до якої ви надсилаєте латку, можливо додати до Копії (CC) супроводжувача, або людину, відповідальну за цю секцію, та відправити листа. -You can also send the patches through an SMTP server. As before, you can set each value separately with a series of `git config` commands, or you can add them manually in the sendemail section in your `~/.gitconfig` file: +Ви також можете надіслати латки через SMTP сервер. Як і раніше, ви можете задати кожне значення окремо за допомогою декількох команд `git config`, або додати їх вручну до секції sendmail свого файлу `~/.gitconfig`: [source,ini] ----- @@ -731,7 +734,7 @@ You can also send the patches through an SMTP server. As before, you can set eac smtpserverport = 587 ----- -After this is done, you can use `git send-email` to send your patches: +Відтак, ви можете використати `git send-email`, щоб надсилати латки: [source,console] ----- @@ -744,7 +747,7 @@ Who should the emails be sent to? jessica@example.com Message-ID to be used as In-Reply-To for the first email? y ----- -Then, Git spits out a bunch of log information looking something like this for each patch you're sending: +Потім, Git друкує купу журнальної інформації, що виглядає приблизно так для кожної відправленої латки: [source,text] ----- @@ -764,8 +767,8 @@ References: Result: OK ----- -==== Summary +==== Підсумок -This section has covered a number of common workflows for dealing with several very different types of Git projects you're likely to encounter, and introduced a couple of new tools to help you manage this process. -Next, you'll see how to work the other side of the coin: maintaining a Git project. -You'll learn how to be a benevolent dictator or integration manager. +У цій секції розглянуто декілька поширених процесів роботи, які працюють з декількома дуже різними типами проектів Git, які ви можете зустріти, та представлено декілька нових інструментів, які допомагають з керуванням цим процесом. +Далі, ви побачите як працювати з іншого боку: супроводжувати проект Git. +Ви дізнаєтесь як бути доброзичливим диктатором або менеджером інтеграції. diff --git a/status.json b/status.json index 0bdb50a9..02f2c355 100644 --- a/status.json +++ b/status.json @@ -46,7 +46,7 @@ }, "05-distributed-git": { "1-distributed-git.asc": 100, - "sections/contributing.asc": 0, + "sections/contributing.asc": 100, "sections/distributed-workflows.asc": 100, "sections/maintaining.asc": 0 },