diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 56fc5c84e..f5033a186 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -1,95 +1,95 @@ -=== Account Setup and Configuration +=== Поставување сметка и конфигурација (((GitHub, user accounts))) -The first thing you need to do is set up a free user account. -Simply visit https://github.com[], choose a user name that isn't already taken, provide an email address and a password, and click the big green ``Sign up for GitHub'' button. +Првото нешто што треба да направите е да поставите бесплатна корисничка сметка. +Едноставно посетете https://github.com [], изберете корисничко име кое не е веќе направено, дадете е-поштенска адреса и лозинка, и кликнете на копчето "Пријавете се за GitHub". -.The GitHub sign-up form. -image::images/signup.png[The GitHub sign-up form.] +.GitHub форма за регистрација. +image::images/signup.png[GitHub форма за регистрација.] -The next thing you'll see is the pricing page for upgraded plans, but it's safe to ignore this for now. -GitHub will send you an email to verify the address you provided. -Go ahead and do this; it's pretty important (as we'll see later). +Следното нешто што ќе го видите е ценовната страница за надградени планови, но сега е безбедно да се игнорира ова. +GitHub ќе ви испрати е-пошта за да ја потврдите адресата што ја дадовте. +Оди напред и направете го ова; тоа е доста важно (како што ќе видиме подоцна). [NOTE] ==== -GitHub provides all of its functionality with free accounts, with the limitation that all of your projects are fully public (everyone has read access). -GitHub's paid plans also include the option of creating private projects, but we won't be covering those in this book. +GitHub ја обезбедува својата функционалност со бесплатни сметки, со ограничување дека сите ваши проекти се целосно јавни (секој има пристап за читање). +Платените планови на GitHub исто така вклучуваат опција за креирање на приватни проекти, но ние нема да ги покриеме тие во оваа книга. ==== -Clicking the Octocat logo at the top-left of the screen will take you to your dashboard page. -You're now ready to use GitHub. +Со кликнување на логото на Octocat во горниот лев агол од екранот ќе ве однесе до страната на вашата табла. +Сега сте подготвени да го користите GitHub. -==== SSH Access +==== SSH пристап (((SSH keys, with GitHub))) -As of right now, you're fully able to connect with Git repositories using the `https://` protocol, authenticating with the username and password you just set up. -However, to simply clone public projects, you don't even need to sign up - the account we just created comes into play when we fork projects and push to our forks a bit later. +Од сега, во целост сте во можност да се поврзете со Git складиштата користејќи го протоколот `https: //`, автентицирате со корисничкото име и лозинката која штотуку сте ја поставиле. +Сепак, за едноставно клонирање на јавни проекти, дури и не треба да се регистрирате - сметката што ја создадовме започнува со играње, кога ќе ги одвоиме проектите и малку подоцна ќе продолжиме со нашите вилушки. -If you'd like to use SSH remotes, you'll need to configure a public key. -(If you don't already have one, see <>.) -Open up your account settings using the link at the top-right of the window: +Ако сакате да користите SSH дистанционни, ќе треба да конфигурирате јавен клуч. +(Ако веќе не го имате, видете <>.) +Отворете ги поставките за вашиот профил користејќи ја врската во горниот десен агол од прозорецот: -.The ``Account settings'' link. -image::images/account-settings.png[The ``Account settings'' link.] +.``Account settings'' линк. +image::images/account-settings.png[``Account settings'' линк.] -Then select the ``SSH keys'' section along the left-hand side. +Потоа одберете го секцијата ``SSH keys''(клучеви) по должината на левата страна. -.The ``SSH keys'' link. -image::images/ssh-keys.png[The ``SSH keys'' link.] +.``SSH keys''(клучеви) линк. +image::images/ssh-keys.png[``SSH keys'' линк.] -From there, click the "`Add an SSH key`" button, give your key a name, paste the contents of your `~/.ssh/id_rsa.pub` (or whatever you named it) public-key file into the text area, and click ``Add key''. +Од таму, кликнете на копчето "Додај SSH копче", наведете го клучот со име, ставете ја содржината на вашата датотека "~ / .ssh / id_rsa.pub" (или што и да си ја навеле) датотеката со јавен клуч во текстот област и кликнете на `Додај клуч '. [NOTE] ==== -Be sure to name your SSH key something you can remember. -You can name each of your keys (e.g. "My Laptop" or "Work Account") so that if you need to revoke a key later, you can easily tell which one you're looking for. +Бидете сигурни дека името на вашиот SSH клуч е нешто што може да се запамети. +Можете да ги именувате секој од вашите клучеви (на пример, "Мојот лаптоп" или "Работна сметка"), така што ако треба да го откажете клучот подоцна, можете лесно да кажете кој сте го барате. ==== [[_personal_avatar]] -==== Your Avatar +==== Вашиот Аватар -Next, if you wish, you can replace the avatar that is generated for you with an image of your choosing. -First go to the ``Profile'' tab (above the SSH Keys tab) and click ``Upload new picture''. +Следно, ако сакате, можете да го замените аватарот кој е генериран за вас со слика на вашиот избор. +Прво оди на табулаторот "Профил" (над табот SSH тастатура) и кликнете ,, Upload new picture ''. -.The ``Profile'' link. +.``Профил'' линк. image::images/your-profile.png[The ``Profile'' link.] -We'll choose a copy of the Git logo that is on our hard drive and then we get a chance to crop it. +Ние ќе избереме копија од логото на Git што е на нашиот хард диск, а потоа добиваме шанса да го исечеме. -.Crop your avatar +.Исечете го вашиот аватар. image::images/avatar-crop.png[Crop your uploaded avatar.] -Now anywhere you interact on the site, people will see your avatar next to your username. +Сега насекаде каде што комуницирате на страницата, луѓето ќе го видат вашиот аватар веднаш до вашето корисничко име. -If you happen to have uploaded an avatar to the popular Gravatar service (often used for Wordpress accounts), that avatar will be used by default and you don't need to do this step. +Ако се случи да имате поставено аватар во популарната Gravatar услуга (често се користи за Wordpress сметки), тој аватар ќе се користи стандардно и нема потреба да го правите овој чекор. -==== Your Email Addresses +==== Вашите е-мејл адреси -The way that GitHub maps your Git commits to your user is by email address. -If you use multiple email addresses in your commits and you want GitHub to link them up properly, you need to add all the email addresses you have used to the Emails section of the admin section. +Начинот на кој GitHub ги мапира вашите Git обврски на вашиот корисник е по е-адреса. +Ако користите повеќе е-мејл адреси во вашите обврски и сакате GitHub да ги поврзе правилно, треба да ги додадете сите адреси на е-пошта што сте ги користеле во делот Е-пораки во делот за админ. [[_add_email_addresses]] -.Add email addresses +.Додавање на емаил адреси image::images/email-settings.png[Add all your email addresses.] -In <<_add_email_addresses>> we can see some of the different states that are possible. -The top address is verified and set as the primary address, meaning that is where you'll get any notifications and receipts. -The second address is verified and so can be set as the primary if you wish to switch them. -The final address is unverified, meaning that you can't make it your primary address. -If GitHub sees any of these in commit messages in any repository on the site, it will be linked to your user now. +Во <<_add_email_addresses>> можеме да видиме некои од различните држави што се можни. +Главната адреса е потврдена и поставена како примарна адреса, што значи дека ќе добиете известувања и потврди. +Втората адреса е потврдена и така може да се постави како примарна ако сакате да ги промените. +Конечната адреса не е потврдена, што значи дека не можете да ја направите вашата примарна адреса. +Ако GitHub гледа било кој од овие во изврши пораки во секое складиште на сајтот, тој ќе биде поврзан со вашиот корисник сега. -==== Two Factor Authentication +==== Двофакторска автентикација -Finally, for extra security, you should definitely set up Two-factor Authentication or ``2FA''. -Two-factor Authentication is an authentication mechanism that is becoming more and more popular recently to mitigate the risk of your account being compromised if your password is stolen somehow. -Turning it on will make GitHub ask you for two different methods of authentication, so that if one of them is compromised, an attacker will not be able to access your account. +Конечно, за дополнителна безбедност, дефинитивно треба да поставите Двофакторска автентикација или `` 2FA ''. +Двофакторската проверка на автентичност е механизам за автентикација кој неодамна станува се повеќе популарен за ублажување на ризикот од компромитација на вашата сметка, ако вашата лозинка е украдена некако. +Вклучувањето ќе го направи GitHub да ве праша за два различни методи на автентикација, така што ако еден од нив е компромитиран, напаѓачот нема да може да пристапи до вашата сметка. -You can find the Two-factor Authentication setup under the Security tab of your Account settings. +Можете да го најдете поставувањето на две фактори за автентикација под табулаторот за безбедност на поставките за вашата сметка. -.2FA in the Security Tab -image::images/2fa-1.png[2FA in the Security Tab] +.2ФА во табот за Безбедност +image::images/2fa-1.png[2ФА во табот за Безбедност] -If you click on the ``Set up two-factor authentication'' button, it will take you to a configuration page where you can choose to use a phone app to generate your secondary code (a ``time based one-time password''), or you can have GitHub send you a code via SMS each time you need to log in. +Ако кликнете на копчето `Постави дво-фактор за проверка', ќе ве одведе до страната за конфигурација каде што можете да одберете да користите телефонска апликација за да генерирате секундарен код ("времена лозинка за една употреба"), или можете да добиете GitHub код преку СМС-пораката секогаш кога ќе треба да се најавите. -After you choose which method you prefer and follow the instructions for setting up 2FA, your account will then be a little more secure and you will have to provide a code in addition to your password whenever you log into GitHub. +Откако ќе изберете кој метод сакате и следете ги инструкциите за поставување на 2FA, вашата сметка тогаш ќе биде малку посигурна и ќе мора да обезбедиш код покрај вашата лозинка секогаш кога ќе влезете во GitHub. diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 1372cdc91..a30507d45 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -1,66 +1,66 @@ -=== Contributing to a Project +=== Придонес кон проект -Now that our account is set up, let's walk through some details that could be useful in helping you contribute to an existing project. +Сега, кога нашата сметка е поставена, ајде да прошетаме низ некои детали кои би можеле да бидат корисни за да ви помогнеме да придонесете за постоечки проект. -==== Forking Projects +==== Формирање проекти (((forking))) -If you want to contribute to an existing project to which you don’t have push access, you can ``fork'' the project. -When you ``fork'' a project, GitHub will make a copy of the project that is entirely yours; it lives in your namespace, and you can push to it. +Ако сакате да придонесете за постоечки проект на кој немате притисок, можете да го "разоткриете" проектот. +Кога ќе "разделите" проект, GitHub ќе направи копија од проектот што е целосно ваш; таа живее во вашиот именски простор и може да притиснете. [NOTE] ==== -Historically, the term ``fork'' has been somewhat negative in context, meaning that someone took an open source project in a different direction, sometimes creating a competing project and splitting the contributors. -In GitHub, a ``fork'' is simply the same project in your own namespace, allowing you to make changes to a project publicly as a way to contribute in a more open manner. +Историски гледано, терминот `` вилушка '' е малку негативен во контекст, што значи дека некој зеде проект со отворен код во различен правец, понекогаш создавајќи конкурентен проект и поделба на соработниците. +Во GitHub, `` вилушка '' е едноставно ист проект во вашиот сопствен именски простор, овозможувајќи ви да ги промениш проектите јавно како начин да придонесете поотворено. ==== -This way, projects don’t have to worry about adding users as collaborators to give them push access. -People can fork a project, push to it, and contribute their changes back to the original repository by creating what's called a Pull Request, which we'll cover next. -This opens up a discussion thread with code review, and the owner and the contributor can then communicate about the change until the owner is happy with it, at which point the owner can merge it in. +На овој начин, проектите не мора да се грижат за додавање на корисници како соработници за да им овозможат пристап до нив. +Луѓето можат да се откажат од проект, да се придвижат кон него и да ги придонесат своите промени назад во оригиналното складиште, создавајќи го она што се нарекува Барање за повлекување, кое ќе го покриеме следно. +Ова отвора низа за дискусија со преглед на кодот, а сопственикот и соработникот потоа може да комуницираат за промената се додека сопственикот не се задоволи со него, во кој момент сопственикот може да го спои. -To fork a project, visit the project page and click the ``Fork'' button at the top-right of the page. +За да видете проект, посетете ја страницата на проектот и кликнете на копчето "Вилушка" во горниот десен агол на страницата. .The ``Fork'' button. image::images/forkbutton.png[The ``Fork'' button.] -After a few seconds, you'll be taken to your new project page, with your own writeable copy of the code. +По неколку секунди, ќе бидете префрлени на вашата нова страница со проектот, со своја сопствена копија од кодот кој може да се запише. [[ch06-github_flow]] -==== The GitHub Flow +==== GitHub Тек (((GitHub, Flow))) -GitHub is designed around a particular collaboration workflow, centered on Pull Requests. -This flow works whether you're collaborating with a tightly-knit team in a single shared repository, or a globally-distributed company or network of strangers contributing to a project through dozens of forks. -It is centered on the <> workflow covered in <>. +GitHub е дизајниран околу одреден процес на работа на соработка, центриран на барањата за повлекување. +Овој проток работи без разлика дали соработувате со тесно поврзан тим во едно заедничко складиште или глобално дистрибуирана компанија или мрежа на странци кои придонесуваат за проектот преку десетици вилушки. +Тој е центриран на работниот процес << ch03-git-branching # _topic_branch >>, опфатен во гранката на грандиозност >. -Here's how it generally works: +Еве како функционира генерално: -1. Fork the project -2. Create a topic branch from `master`. -3. Make some commits to improve the project. -4. Push this branch to your GitHub project. -5. Open a Pull Request on GitHub. -6. Discuss, and optionally continue committing. -7. The project owner merges or closes the Pull Request. +1. Вилушкајте го проектот +2. Креирајте гранка на тема од `master`. +3. Направете некои обврски за подобрување на проектот. +4. Притиснете ја оваа гранка во вашиот GitHub проект. +5. Отворете барање за повлекување на GitHub. +6. Дискутирајте и, опционално, продолжете со извршување. +7. Сопственикот на проектот го спојува или затвора Барањето за повлекување. -This is basically the Integration Manager workflow covered in <>, but instead of using email to communicate and review changes, teams use GitHub's web based tools. +Ова е, всушност, работниот процес за интеграција вклучен во << ch05-distributed-git # _integration_manager >>, но наместо да користат е-пошта за да комуницираат и да ги разгледуваат промените, тимовите ги користат веб-алатките на GitHub. -Let's walk through an example of proposing a change to an open source project hosted on GitHub using this flow. +Ајде да одиме низ еден пример за предлагање на промена на проект со отворен код, хостиран на GitHub користејќи го овој проток. -===== Creating a Pull Request +===== Креирање на барање за повлекување -Tony is looking for code to run on his Arduino programmable microcontroller and has found a great program file on GitHub at https://github.com/schacon/blink[]. +Тони бара код за да работи на неговиот програмски микропроцесор Arduino и најде одлична програмска датотека на GitHub на https://github.com/schacon/blink []. .The project we want to contribute to. image::images/blink-01-start.png[The project we want to contribute to.] -The only problem is that the blinking rate is too fast. We think it's much nicer to wait 3 seconds instead of 1 in between each state change. -So let's improve the program and submit it back to the project as a proposed change. +Единствениот проблем е тоа што стапката на трепкање е премногу брзо. Сметаме дека е многу поубаво да чекаме 3 секунди, наместо 1 помеѓу секоја промена на државата. +Значи, да ја подобриме програмата и да ја поднесеме назад кон проектот како предложена промена. -First, we click the 'Fork' button as mentioned earlier to get our own copy of the project. -Our user name here is ``tonychacon'' so our copy of this project is at `https://github.com/tonychacon/blink` and that's where we can edit it. -We will clone it locally, create a topic branch, make the code change and finally push that change back up to GitHub. +Прво, кликнуваме на копчето "Вилушка" како што беше споменато претходно за да добиеме сопствена копија од проектот. +Нашето корисничко име тука е `` tonychacon '', па нашата копија на овој проект е на 'https: // github.com / tonychacon / blink` и тоа е местото каде што можеме да го уредиме. +Ќе го клонираме локално, ќе создадеме тема на гранката, ќе го смениме кодот и конечно ќе ја вратиме промената назад до GitHub. [source,console] ---- @@ -105,111 +105,111 @@ To https://github.com/tonychacon/blink * [new branch] slow-blink -> slow-blink ---- -<1> Clone our fork of the project locally -<2> Create a descriptive topic branch -<3> Make our change to the code -<4> Check that the change is good -<5> Commit our change to the topic branch -<6> Push our new topic branch back up to our GitHub fork +<1> Клонирајте ја нашата вилушка на проектот локално +<2> Креирај дескриптивна гранка на тема +<3> Направете ја нашата промена на кодот +<4> Проверете дали промената е добра +<5> Поставете ја нашата промена во гранката на тема +<6> Притиснете ја нашата нова тема филијала назад до нашата вилушка GitHub -Now if we go back to our fork on GitHub, we can see that GitHub noticed that we pushed a new topic branch up and presents us with a big green button to check out our changes and open a Pull Request to the original project. +Сега, ако се вратиме на нашата вилушка на GitHub, можеме да видиме дека GitHub забележа дека сме натерале нова тема да се подели и ни претставува големо зелено копче за да ги провериме нашите промени и да отвориме барање за повлекување на оригиналниот проект. -You can alternatively go to the ``Branches'' page at `https://github.com///branches` to locate your branch and open a new Pull Request from there. +Како алтернатива, можете да отидете на страницата `` Филијали '' на `https://github.com/ / / branches" за да ја лоцирате вашата филијала и оттаму да отворите ново барање за повлекување. .Pull Request button image::images/blink-02-pr.png[Pull Request button] (((GitHub, pull requests))) -If we click that green button, we'll see a screen that asks us to give our Pull Request a title and description. -It is almost always worthwhile to put some effort into this, since a good description helps the owner of the original project determine what you were trying to do, whether your proposed changes are correct, and whether accepting the changes would improve the original project. +Ако го кликнеме тоа зелено копче, ќе видиме екран кој ќе побара од нас да му дадеме на нашите барања за повлекување на наслов и опис. +Секогаш е вредно да вложиме некои напори, бидејќи добар опис му помага на сопственикот на оригиналниот проект да утврди што се обидувате да направите, дали вашите предложени измени се точни и дали прифаќањето на промените ќе го подобри оригиналниот проект. -We also see a list of the commits in our topic branch that are ``ahead'' of the `master` branch (in this case, just the one) and a unified diff of all the changes that will be made should this branch get merged by the project owner. +Ние, исто така, видиме листа на обврските во нашата гранка на теми кои се "напред" на "господарната гранка" (во овој случај, само онаа) и обединета разлика на сите промени што ќе бидат направени, ако оваа гранка споени од сопственикот на проектот. .Pull Request creation page image::images/blink-03-pull-request-open.png[Pull Request creation] -When you hit the 'Create pull request' button on this screen, the owner of the project you forked will get a notification that someone is suggesting a change and will link to a page that has all of this information on it. +Кога ќе го достигнете копчето 'Креирај барање за повлекување' на овој екран, сопственикот на проектот кој сте го навеле добивате известување дека некој предлага сумање и ќе се поврзе со страница која ги има сите овие информации на неа. [NOTE] ==== -Though Pull Requests are used commonly for public projects like this when the contributor has a complete change ready to be made, it's also often used in internal projects _at the beginning_ of the development cycle. Since you can keep pushing to the topic branch even *after* the Pull Request is opened, it's often opened early and used as a way to iterate on work as a team within a context, rather than opened at the very end of the process. +Иако барањата за влечење се користат често за вакви јавни проекти, кога соработникот има комплетна промена подготвена да се направи, таа често се користи и во внатрешните проекти на почетокот на развојниот циклус. Бидејќи можете да продолжите да вршите притисок врз гранката на тема дури * по * се отвора Барањето за влечење, тоа често се отвора рано и се користи како начин да се повтори работата на тим во контекст, наместо да се отвори на самиот крај на процесот. ==== -===== Iterating on a Pull Request +===== Итерација на барањето за повлекување -At this point, the project owner can look at the suggested change and merge it, reject it or comment on it. Let's say that he likes the idea, but would prefer a slightly longer time for the light to be off than on. +Во овој момент, сопственикот на проектот може да ја разгледа предложената промена и да ја спои, да го одбие или да коментира. Да речеме дека му се допаѓа идејата, но би сакала малку подолго време за светлината да биде исклучена отколку натаму. -Where this conversation may take place over email in the workflows presented in <>, on GitHub this happens online. The project owner can review the unified diff and leave a comment by clicking on any of the lines. +Каде што овој разговор може да се одвива преку е-пошта во работните процеси презентирани во << ch05-distributed-git # ch05-distributed-git >>, на GitHub ова се случува онлајн. Сопственикот на проектот може да ја прегледа унифицираната разлика и да остави коментар со кликнување на која било од редовите. .Comment on a specific line of code in a Pull Request image::images/blink-04-pr-comment.png[PR line comment] -Once the maintainer makes this comment, the person who opened the Pull Request (and indeed, anyone else watching the repository) will get a notification. We'll go over customizing this later, but if he had email notifications turned on, Tony would get an email like this: +Откако одржувачот ќе го направи овој коментар, лицето кое го отворило барањето за потпишување (и навистина, некој друг што го следи складиштето) ќе добие известување. Ќе продолжиме да го прилагодуваме ова подоцна, но ако има вклучено известување преку е-пошта, Тони ќе добие е-пошта како оваа: [[_email_notification]] .Comments sent as email notifications image::images/blink-04-email.png[Email notification] -Anyone can also leave general comments on the Pull Request. In <<_pr_discussion>> we can see an example of the project owner both commenting on a line of code and then leaving a general comment in the discussion section. You can see that the code comments are brought into the conversation as well. +Секој може исто така да остави општи коментари за барањето за повлекување. Во << _ pr_discussion >> можеме да видиме пример на сопственикот на проектот коментирајќи ја линијата на кодот, а потоа оставајќи општ коментар во делот за дискусија. Можете да видите дека кодек коментари се доведени во разговорот, како и. [[_pr_discussion]] .Pull Request discussion page image::images/blink-05-general-comment.png[PR discussion page] -Now the contributor can see what they need to do in order to get their change accepted. -Luckily this is very straightforward. -Where over email you may have to re-roll your series and resubmit it to the mailing list, with GitHub you simply commit to the topic branch again and push, which will automatically update the Pull Request. -In <<_pr_final>> you can also see that the old code comment has been collapsed in the updated Pull Request, since it was made on a line that has since been changed. +Сега соработникот може да види што треба да направат за да ја прифатат нивната промена. +За среќа, ова е многу едноставно. +Каде преку е-маил можеби ќе треба да ја превртувате вашата серија и да ја поднесете повторно на мејлинг листата, со GitHub вие едноставно се обврзувате на гранката на тема повторно и притиснете, што автоматски ќе го ажурира барањето за повлекување. +Во << _ pr_final >> исто така можете да видите дека стариот коментар во коментарот е пропаднат во ажурираното барање за повлекување, бидејќи е направено на линија која оттогаш е променета. -Adding commits to an existing Pull Request doesn't trigger a notification, so once Tony has pushed his corrections he decides to leave a comment to inform the project owner that he made the requested change. +Додавањето на обврски кон постоечкото барање за повлекување не активира известување, па откако Тони ги исправи неговите исправки, тој одлучува да остави коментар за да го извести сопственикот на проектот дека ја направил бараната промена. [[_pr_final]] .Pull Request final image::images/blink-06-final.png[PR final] -An interesting thing to notice is that if you click on the ``Files Changed'' tab on this Pull Request, you'll get the ``unified'' diff -- that is, the total aggregate difference that would be introduced to your main branch if this topic branch was merged in. In `git diff` terms, it basically automatically shows you `git diff master...` for the branch this Pull Request is based on. See <> for more about this type of diff. +Интересно е да се забележи дека ако кликнете на табулаторот `` Датотеки смени '' на ова барање за повлекување, ќе го добиете `` унифициран '' разлик - односно вкупната разлика во вкупниот износ што ќе се внесе во вашиот главната гранка, ако оваа гранка на тема беше споена внатре. Во `git diff` термини, тој во основа автоматски ви покажува` git diff master ... `за гранката на која се заснова ова барање за повлекување. Види << ch05-distributed-git # _what_is_introduced >> за повеќе за овој тип на разлика. -The other thing you'll notice is that GitHub checks to see if the Pull Request merges cleanly and provides a button to do the merge for you on the server. This button only shows up if you have write access to the repository and a trivial merge is possible. If you click it GitHub will perform a ``non-fast-forward'' merge, meaning that even if the merge *could* be a fast-forward, it will still create a merge commit. +Другата работа што ќе забележите е дека GitHub проверува дали да се спореди барањето за повлекување и да се обезбеди копче за да се направи спојување за вас на серверот. Ова копче се појавува само ако имате пристап за запишување во складиштето и можно е тривијално спојување. Ако го кликнете, GitHub ќе изврши спојување со "не-брз напред", што значи дека дури и ако спојувањето * може да биде брзо напред, сепак ќе создаде спојување. -If you would prefer, you can simply pull the branch down and merge it locally. If you merge this branch into the `master` branch and push it to GitHub, the Pull Request will automatically be closed. +Ако сакате, можете едноставно да ја повлечете гранката и да ја споите локално. Ако се спојат оваа гранка во гранката `господар` и притиснете ја на GitHub, барањето за повлекување автоматски ќе се затвори. -This is the basic workflow that most GitHub projects use. Topic branches are created, Pull Requests are opened on them, a discussion ensues, possibly more work is done on the branch and eventually the request is either closed or merged. +Ова е основниот работен процес што го користат повеќето GitHub проекти. Теме гранките се создаваат, на нив се отвараат Барањата за повлекување, започнува дискусија, можеби повеќе работи се прават на филијалата и на крајот барањето е или затворено или споено. [NOTE] .Not Only Forks ==== -It's important to note that you can also open a Pull Request between two branches in the same repository. If you're working on a feature with someone and you both have write access to the project, you can push a topic branch to the repository and open a Pull Request on it to the `master` branch of that same project to initiate the code review and discussion process. No forking necessary. +Важно е да се напомене дека исто така можете да отворите барање за повлекување помеѓу две гранки во истото складиште. Ако работите со некоја функција со некој и двајцата имате пристап за запишување на проектот, можете да притиснете на гранка на тема во складиштето и да го отворите барањето за повлекување на неа до "master" филијалата на истиот проект за да го иницирате шифрата преглед и дискусија. Не е неопходно. ==== -==== Advanced Pull Requests +==== Напредно барање за повлекување -Now that we've covered the basics of contributing to a project on GitHub, let's cover a few interesting tips and tricks about Pull Requests so you can be more effective in using them. +Сега, кога ги покриваме основите на придонесот за проект на GitHub, ајде да покриеме неколку интересни совети и трикови за Потребните Барања за да можете да бидете поефикасни во користењето. -===== Pull Requests as Patches +===== Повлечете ги барањата како закрпи -It's important to understand that many projects don't really think of Pull Requests as queues of perfect patches that should apply cleanly in order, as most mailing list-based projects think of patch series contributions. Most GitHub projects think about Pull Request branches as iterative conversations around a proposed change, culminating in a unified diff that is applied by merging. +Важно е да се разбере дека многу проекти навистина не мислат на Пат Барања како редици на совршени закрпи кои треба да се применуваат чисто по редослед, бидејќи повеќето проекти засновани на списоци размислуваат за придонеси од сериите на печ. Повеќето GitHub проекти размислуваат за гранките за укинување на повик како итеративни разговори околу предложената промена, што кулминира со унифициран раздел кој се применува со спојување. -This is an important distinction, because generally the change is suggested before the code is thought to be perfect, which is far more rare with mailing list based patch series contributions. This enables an earlier conversation with the maintainers so that arriving at the proper solution is more of a community effort. When code is proposed with a Pull Request and the maintainers or community suggest a change, the patch series is generally not re-rolled, but instead the difference is pushed as a new commit to the branch, moving the conversation forward with the context of the previous work intact. +Ова е важна дистинкција, бидејќи генерално промената е предложена пред кодот да се смета за совршен, што е далеку поретко со прилози на сериски прилози базирани на мејлинг. Ова овозможува претходен разговор со одржувачите, така што пристигнувањето на соодветното решение е повеќе заеднички напор. Кога кодот е предложен со барање за повлекување, а одржувачите или заедницата сугерираат промена, серијата на мрежи генерално не се превртува, но наместо тоа, разликата се турка како нова обврска кон гранката, движејќи го разговорот напред со контекстот на претходната работа непроменета. -For instance, if you go back and look again at <<_pr_final>>, you'll notice that the contributor did not rebase his commit and send another Pull Request. Instead they added new commits and pushed them to the existing branch. This way if you go back and look at this Pull Request in the future, you can easily find all of the context of why decisions were made. Pushing the ``Merge'' button on the site purposefully creates a merge commit that references the Pull Request so that it's easy to go back and research the original conversation if necessary. +На пример, ако се вратиш повторно и погледнете повторно во << _ pr_final >>, ќе забележите дека соработникот не го повратил своето извршување и испрати друго барање за повлекување. Наместо тоа, тие додадоа нови обврски и ги туркаа до постојната гранка. На овој начин, ако се вратите назад и ќе го разгледате ова барање за повлекување во иднина, можете лесно да го најдете целиот контекст за тоа зошто биле донесени одлуки. Притискањето на копчето `Merge 'на страницата намерно создава обврска за спојување која го упатува Барањето за потпишување, така што лесно може да се врати и да се испита оригиналниот разговор ако е потребно. -===== Keeping up with Upstream +===== Одржување со Upstream -If your Pull Request becomes out of date or otherwise doesn't merge cleanly, you will want to fix it so the maintainer can easily merge it. GitHub will test this for you and let you know at the bottom of every Pull Request if the merge is trivial or not. +Ако Вашето барање за повлекување станува застарено или на друг начин не се спои чисто, ќе сакате да го поправите, така што одржувачот лесно може да се спои. GitHub ќе го тестира ова за вас и ќе ве извести на дното на секое барање за повлекување ако спојувањето е тривијално или не. [[_pr_fail]] .Pull Request does not merge cleanly image::images/pr-01-fail.png[PR merge failure] -If you see something like <<_pr_fail>>, you'll want to fix your branch so that it turns green and the maintainer doesn't have to do extra work. +Ако видите нешто како << _ pr_fail >>, ќе сакате да ја поправите вашата гранка, така што ќе стане зелена и одржувачот не мора да работи дополнително. -You have two main options in order to do this. You can either rebase your branch on top of whatever the target branch is (normally the `master` branch of the repository you forked), or you can merge the target branch into your branch. +Имате две главни опции за да го направите тоа. Можете да го ребалансирате филијалата на врвот на она што е целниот гранка (обично "господар" филијала на складиштето што сте го навеле), или можете да ја спои целната гранка во вашата гранка. -Most developers on GitHub will choose to do the latter, for the same reasons we just went over in the previous section. What matters is the history and the final merge, so rebasing isn't getting you much other than a slightly cleaner history and in return is *far* more difficult and error prone. +Повеќето програмери на GitHub ќе изберат да го направат вториот, од истите причини кои штотуку отидовме во претходниот дел. Она што е важно е историјата и финалното спојување, па така враќањето не ви дава многу повеќе од малку почиста историја, а за возврат е * далеку * потешко и склони кон грешка. -If you want to merge in the target branch to make your Pull Request mergeable, you would add the original repository as a new remote, fetch from it, merge the main branch of that repository into your topic branch, fix any issues and finally push it back up to the same branch you opened the Pull Request on. +Ако сакате да се спојат во филијалата на целни за да се спојат Барањето за повлекување, ќе го додадете оригиналното складиште како нов далечински управувач, донеси од него, спојте ја главната филијала на тоа складиште во вашата гранка на тема, поправете какви било проблеми и конечно притиснете назад до истата гранка што ја отворивте Барањето за влечење. -For example, let's say that in the ``tonychacon'' example we were using before, the original author made a change that would create a conflict in the Pull Request. Let's go through those steps. +На пример, да речеме дека во примерот ,, tonychacon '' што го користевме претходно, оригиналниот автор направил промена што би создала конфликт во барањето за повлекување. Ајде да одиме низ тие чекори. [source,console] ---- @@ -244,67 +244,67 @@ To https://github.com/tonychacon/blink ef4725c..3c8d735 slower-blink -> slow-blink ---- -<1> Add the original repository as a remote named ``upstream'' -<2> Fetch the newest work from that remote -<3> Merge the main branch of that repository into your topic branch -<4> Fix the conflict that occurred -<5> Push back up to the same topic branch +<1> Додајте го оригиналното складиште како далечинско наречено "нагорниот" +<2> Донеси ја најновата работа од тој далечински управувач +<3> Спојување на главната гранка на тоа складиште во вашата гранка на тема +<4> Исправи го конфликтот што се случи +<5> Придвижете се назад кон истата гранка -Once you do that, the Pull Request will be automatically updated and re-checked to see if it merges cleanly. +Откако ќе го направите тоа, барањето за повлекување ќе биде автоматски ажурирано и повторно проверено за да видат дали се спојува чисто. [[_pr_merge_fix]] .Pull Request now merges cleanly image::images/pr-02-merge-fix.png[PR fixed] -One of the great things about Git is that you can do that continuously. If you have a very long-running project, you can easily merge from the target branch over and over again and only have to deal with conflicts that have arisen since the last time that you merged, making the process very manageable. +Една од одличните работи за Git е тоа што можете постојано да го правите тоа. Ако имате многу долготраен проект, лесно можете да се спојат од целните гранки одново и одново и само треба да се справите со конфликти кои се појавиле од последниот пат кога сте се споиле, со што процесот е многу податлив. -If you absolutely wish to rebase the branch to clean it up, you can certainly do so, but it is highly encouraged to not force push over the branch that the Pull Request is already opened on. If other people have pulled it down and done more work on it, you run into all of the issues outlined in <>. Instead, push the rebased branch to a new branch on GitHub and open a brand new Pull Request referencing the old one, then close the original. +Ако апсолутно сакате да ја оспорите филијалата за да го исчистите, сигурно може да го сторите тоа, но многу е охрабрен да не го притискате гранката на која веќе е отворена Барањето за влечење. Ако другите луѓе го повлекоа и направија повеќе работа на тоа, ќе наидете на сите прашања наведени во << ch03-git-branching # _rebase_peril >>. Наместо тоа, притиснете го преработениот филијала во нова филијала на GitHub и отворете сосема ново барање за потпишување кое ќе го референцира стариот, а потоа затворете го оригиналот. -===== References +===== Референци -Your next question may be ``How do I reference the old Pull Request?''. It turns out there are many, many ways to reference other things almost anywhere you can write in GitHub. +Вашето следно прашање може да биде: "Како да го користам старото барање за повлекување?" Излезе дека има многу, многу начини да се повикувате на други работи речиси насекаде каде што можете да напишете во GitHub. -Let's start with how to cross-reference another Pull Request or an Issue. All Pull Requests and Issues are assigned numbers and they are unique within the project. For example, you can't have Pull Request #3 _and_ Issue #3. If you want to reference any Pull Request or Issue from any other one, you can simply put `#` in any comment or description. You can also be more specific if the Issue or Pull request lives somewhere else; write `username#` if you're referring to an Issue or Pull Request in a fork of the repository you're in, or `username/repo#` to reference something in another repository. +Ајде да започнеме со тоа како да се препратиме на друго барање за повлекување или проблем. Сите барања за повлекување и прашања се доделени броеви и тие се единствени во рамките на проектот. На пример, не можете да добивате Pull Request # 3 _and_ Issue # 3. Ако сакате да се повикате на било кое барање за повлекување од било кое друго, едноставно можете да ставите `# ` во кој било коментар или опис. Можете исто така да бидете поспецифични ако барањето за издавање или повлекување живее на друго место; напишете `корисничко име # `, ако упатувате на прашање или барање за повлекување во вилушка од складиштето во кое што сте, или `корисничко / репо # ` за да упатите нешто во друго складиште. -Let's look at an example. Say we rebased the branch in the previous example, created a new pull request for it, and now we want to reference the old pull request from the new one. We also want to reference an issue in the fork of the repository and an issue in a completely different project. We can fill out the description just like <<_pr_references>>. +Ајде да погледнеме еден пример. Да речеме дека ја прекршивме гранката во претходниот пример, создадовме ново барање за повлекување, и сега сакаме да го повикаме старото барање за повлекување од новиот. Ние исто така сакаме да се повикаме на прашање во вилушка на складиштето и прашање во сосема поинаков проект. Ние можеме да го пополниме описот како << _ pr_references >>. [[_pr_references]] .Cross references in a Pull Request. image::images/mentions-01-syntax.png[PR references] -When we submit this pull request, we'll see all of that rendered like <<_pr_references_render>>. +Кога ќе го поднесеме ова барање за повлекување, ќе видиме сето тоа изречено како << _ pr_references_render >>. [[_pr_references_render]] .Cross references rendered in a Pull Request. image::images/mentions-02-render.png[PR references rendered] -Notice that the full GitHub URL we put in there was shortened to just the information needed. +Забележете дека целосниот URL на GitHub што го ставаме таму беше скратен само со потребните информации. -Now if Tony goes back and closes out the original Pull Request, we can see that by mentioning it in the new one, GitHub has automatically created a trackback event in the Pull Request timeline. This means that anyone who visits this Pull Request and sees that it is closed can easily link back to the one that superseded it. The link will look something like <<_pr_closed>>. +Сега, ако Тони се врати и го затвора оригиналното барање за повлекување, можеме да видиме дека со споменување во новиот, GitHub автоматски создаде trackback настан во временската линија за повлекување. Ова значи дека секој што го посетува ова барање за повлекување и гледа дека е затворен, лесно може да се поврзе со оној кој го заменил. Врската ќе изгледа нешто како << _ pr_closed >>. [[_pr_closed]] .Link back to the new Pull Request in the closed Pull Request timeline. image::images/mentions-03-closed.png[PR closed] -In addition to issue numbers, you can also reference a specific commit by SHA-1. You have to specify a full 40 character SHA-1, but if GitHub sees that in a comment, it will link directly to the commit. Again, you can reference commits in forks or other repositories in the same way you did with issues. +Покрај броевите на броеви, исто така може да се повикате на одредена обврска од страна на SHA-1. Мора да наведете целосен карактер SHA-1 од 40 карактери, но ако GitHub го гледа тоа во коментар, тој ќе се поврзе директно со извршувањето. Повторно, можете да референцирате да се занимавате со вилушки или други складишта на ист начин како што правите со проблеми. -==== GitHub Flavored Markdown +==== GitHub со вкус на Markdown -Linking to other Issues is just the beginning of interesting things you can do with almost any text box on GitHub. In Issue and Pull Request descriptions, comments, code comments and more, you can use what is called ``GitHub Flavored Markdown''. Markdown is like writing in plain text but which is rendered richly. +Поврзувањето со други прашања е само почеток на интересни работи што можете да ги направите со речиси секое поле за текст на GitHub. Во Описот за Прашања и Потрага, коментари, кодови на коментари и повеќе, можете да го користите она што се нарекува `` GitHub со вкус на Markdown ''. Markdown е како да пишувате во обичен текст, но кој е богато прикажан. -See <<_example_markdown>> for an example of how comments or text can be written and then rendered using Markdown. +Погледнете << _ example_markdown >> за пример за тоа како може да се напишат коментари или текст, а потоа да се претстават со помош на Markdown. [[_example_markdown]] .An example of GitHub Flavored Markdown as written and as rendered. image::images/markdown-01-example.png[Example Markdown] -The GitHub flavor of Markdown adds more things you can do beyond the basic Markdown syntax. These can all be really useful when creating useful Pull Request or Issue comments or descriptions. +GitHub вкусот на Markdown додава повеќе работи што можете да ги направите надвор од основната синтакса на Markdown. Сите овие можат да бидат навистина корисни кога креирате корисни Барање за повлекување или издавање коментари или описи. -===== Task Lists +===== Листа на задачи -The first really useful GitHub specific Markdown feature, especially for use in Pull Requests, is the Task List. A task list is a list of checkboxes of things you want to get done. Putting them into an Issue or Pull Request normally indicates things that you want to get done before you consider the item complete. +Првата навистина корисна GitHub специфична Markdown функција, особено за употреба во барањата за повлекување, е листата на задачи. Листа на задачи е листа на полиња за работи кои сакате да ги направите. Ставањето на нив во прашање или барање за повлекување нормално укажува на работите што сакате да ги направите пред да го разгледате предметот да заврши. -You can create a task list like this: +Можете да креирате листа на задачи како што е ова: [source,text] ---- @@ -313,27 +313,27 @@ You can create a task list like this: - [ ] Document the code ---- -If we include this in the description of our Pull Request or Issue, we'll see it rendered like <<_eg_task_lists>> +Ако го вклучиме ова во описот на нашето барање за повлекување или проблем, ќе го видиме како << _ eg_task_lists >> [[_eg_task_lists]] .Task lists rendered in a Markdown comment. image::images/markdown-02-tasks.png[Example Task List] -This is often used in Pull Requests to indicate what all you would like to get done on the branch before the Pull Request will be ready to merge. The really cool part is that you can simply click the checkboxes to update the comment -- you don't have to edit the Markdown directly to check tasks off. +Ова често се користи во барањата за повлекување за да се покаже што би сакале да направите на филијалата пред да се појави барање за повлекување. Навистина кул дел е тоа што можете едноставно да кликнете на полињата за да го обновите коментарот - не мора да го уредувате Markdown директно за да ги проверите задачите. -What's more, GitHub will look for task lists in your Issues and Pull Requests and show them as metadata on the pages that list them out. For example, if you have a Pull Request with tasks and you look at the overview page of all Pull Requests, you can see how far done it is. This helps people break down Pull Requests into subtasks and helps other people track the progress of the branch. You can see an example of this in <<_task_list_progress>>. +Освен тоа, GitHub ќе бара листи со задачи во вашите Прашања и Повлекување барања и ќе ги прикаже како метаподатоци на страниците што ги наведуваат. На пример, ако имате барање за повлекување со задачи и гледате на страната за преглед на сите барања за повлекување, можете да видите колку е направено. Ова им помага на луѓето да ги срушат барањата за повлекување во подзадачи и им помага на другите луѓе да го следат напредокот на филијалата. Можете да видите пример за ова во << _ task_list_progress >>. [[_task_list_progress]] .Task list summary in the Pull Request list. image::images/markdown-03-task-summary.png[Example Task List] -These are incredibly useful when you open a Pull Request early and use it to track your progress through the implementation of the feature. +Овие се неверојатно корисни кога отворате Барање за повлекување рано и го користите за следење на вашиот напредок преку имплементација на функцијата. -===== Code Snippets +===== Код фрагменти -You can also add code snippets to comments. This is especially useful if you want to present something that you _could_ try to do before actually implementing it as a commit on your branch. This is also often used to add example code of what is not working or what this Pull Request could implement. +Можете исто така да додавате кодови на коментари за коментари. Ова е особено корисно ако сакате да презентирате нешто што може да се обидете да го направите пред да го имплементирате како залог на вашата гранка. Ова исто така често се користи за да се додаде примерен код за тоа што не работи или што би можело да го спроведе ова барање за повлекување. -To add a snippet of code you have to ``fence'' it in backticks. +За да додадете фрагмент од кодот, мора да го "оградите" во backticks. [source,text] ---- @@ -345,17 +345,17 @@ for(int i=0 ; i < 5 ; i++) ``` ---- -If you add a language name like we did there with 'java', GitHub will also try to syntax highlight the snippet. In the case of the above example, it would end up rendering like <<_md_code>>. +Ако додадете име на јазик како што го сторивме таму со "java", GitHub исто така ќе се обиде да синтакса нагласи фрагмент. Во случај на горенаведениот пример, тоа ќе заврши како рендерирање како << _ md_code >>. [[_md_code]] .Rendered fenced code example. image::images/markdown-04-fenced-code.png[Rendered fenced code] -===== Quoting +===== Цитирање -If you're responding to a small part of a long comment, you can selectively quote out of the other comment by preceding the lines with the `>` character. In fact, this is so common and so useful that there is a keyboard shortcut for it. If you highlight text in a comment that you want to directly reply to and hit the `r` key, it will quote that text in the comment box for you. +Ако реагирате на мал дел од долгите коментари, можете селективно да цитирате од другиот коментар од претходните линии со знакот `>`. Всушност, ова е толку вообичаено и толку корисно што за неа има кратенка на тастатурата. Ако нагласите текст во коментар за кој сакате директно да одговорите и да го притиснете копчето `r`, тој ќе го цитира тој текст во полето за коментари за вас. -The quotes look something like this: +Цитатите изгледаат вака: [source,text] ---- @@ -373,13 +373,13 @@ image::images/markdown-05-quote.png[Rendered quoting] ===== Emoji -Finally, you can also use emoji in your comments. This is actually used quite extensively in comments you see on many GitHub Issues and Pull Requests. There is even an emoji helper in GitHub. If you are typing a comment and you start with a `:` character, an autocompleter will help you find what you're looking for. +Конечно, можете исто така да користите емоти во вашите коментари. Ова всушност се користи доста опширно во коментарите што ги гледате на многу прашања на GitHub и Pull Requests. Постои дури и помошник за емоции во GitHub. Ако пишувате коментар и почнувате со знак `:`, автокомплетер ќе ви помогне да го пронајдете она што го барате. [[_md_emoji_auto]] .Emoji autocompleter in action. image::images/markdown-06-emoji-complete.png[Emoji autocompleter] -Emojis take the form of `::` anywhere in the comment. For instance, you could write something like this: +Emojis земаат форма на `: :` каде било во коментарот. На пример, би можеле да напишете нешто вака: [source,text] ---- @@ -392,28 +392,28 @@ I :eyes: that :bug: and I :cold_sweat:. :clap::tada::panda_face: ---- -When rendered, it would look something like <<_md_emoji>>. +Кога ќе биде изречена, ќе изгледа нешто како << _ md_emoji >>. [[_md_emoji]] .Heavy emoji commenting. image::images/markdown-07-emoji.png[Emoji] -Not that this is incredibly useful, but it does add an element of fun and emotion to a medium that is otherwise hard to convey emotion in. +Не дека ова е неверојатно корисно, но додава елемент на забава и емоција на медиум што инаку е тешко да се пренесе емоцијата. [NOTE] ==== -There are actually quite a number of web services that make use of emoji characters these days. A great cheat sheet to reference to find emoji that expresses what you want to say can be found at: +Всушност, постојат голем број на веб-услуги кои ги користат емотивите ликови овие денови. Одличен измамник за повикување на емоции што го изразуваат она што сакате да го кажете може да се најдат на: http://www.emoji-cheat-sheet.com ==== -===== Images +===== Слики -This isn't technically GitHub Flavored Markdown, but it is incredibly useful. In addition to adding Markdown image links to comments, which can be difficult to find and embed URLs for, GitHub allows you to drag and drop images into text areas to embed them. +Ова не е технички GitHub со вкус на Markdown, но тоа е неверојатно корисно. Во прилог на додавање на линкови на марканда на линкови до коментари, за кои може да биде тешко да се најдат и вградат URL адреси, GitHub ви овозможува да ги влечете и испуштате сликите во текстуални области за да ги вградите. [[_md_drag]] .Drag and drop images to upload them and auto-embed them. image::images/markdown-08-drag-drop.png[Drag and drop images] -If you look at <<_md_drag>>, you can see a small ``Parsed as Markdown'' hint above the text area. Clicking on that will give you a full cheat sheet of everything you can do with Markdown on GitHub. +Ако погледнете на << _ md_drag >>, можете да видите мал "` Парсери како Markdown "навестување над полето за текст. Кликнување на тоа ќе ви даде целосен измамник на се што можете да направите со Markdown на GitHub. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 5e254f801..8dcdc1b84 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -1,12 +1,12 @@ [[_maintaining_gh_project]] -=== Maintaining a Project +=== Одржување на проект -Now that we're comfortable contributing to a project, let's look at the other side: creating, maintaining and administering your own project. +Сега, кога сме удобно да придонесеме за еден проект, ајде да погледнеме на другата страна: создавање, одржување и администрирање на вашиот сопствен проект. -==== Creating a New Repository +==== Креирање на нов складиште -Let's create a new repository to share our project code with. -Start by clicking the ``New repository'' button on the right-hand side of the dashboard, or from the `+` button in the top toolbar next to your username as seen in <<_new_repo_dropdown>>. +Ајде да создадеме ново складиште со кое ќе го споделиме нашиот проект код. +Започнете со кликнување на копчето `` Нов репозиторија '' на десната страна на контролната табла или од копчето `+` во горната лента со алатки веднаш до вашето корисничко име како што се гледа во << _ new_repo_dropdown >>. .The ``Your repositories'' area. image::images/newrepo.png[The ``Your repositories'' area.] @@ -15,120 +15,120 @@ image::images/newrepo.png[The ``Your repositories'' area.] .The ``New repository'' dropdown. image::images/new-repo.png[The ``new repository'' dropdown.] -This takes you to the ``new repository'' form: +Ова ќе ве однесе до формула "нов складиште": .The ``new repository'' form. image::images/newrepoform.png[The ``new repository'' form.] -All you really have to do here is provide a project name; the rest of the fields are completely optional. -For now, just click the ``Create Repository'' button, and boom – you have a new repository on GitHub, named `/`. +Сите што навистина треба да направите тука е да обезбедите име на проектот; остатокот од полињата се целосно опционални. +За сега, едноставно кликнете на копчето `Креирај репозиториум 'и бум - имате ново складиште на GitHub, наречено` <корисничко име> / <име на проект> `. -Since you have no code there yet, GitHub will show you instructions for how to create a brand-new Git repository, or connect an existing Git project. -We won't belabor this here; if you need a refresher, check out <>. +Бидејќи немате уште уште еден код, GitHub ќе ви покаже инструкции за тоа како да креирате сосема нов Git складиште или да поврзете постоечки проект Git. +Ние нема да го објавиме ова тука; ако ви треба освежувач, проверете << ch02-git-basics-chapter # ch02-git-basics-chapter >>. -Now that your project is hosted on GitHub, you can give the URL to anyone you want to share your project with. -Every project on GitHub is accessible over HTTPS as `https://github.com//`, and over SSH as `git@github.com:/`. -Git can fetch from and push to both of these URLs, but they are access-controlled based on the credentials of the user connecting to them. +Сега, кога вашиот проект е хостиран на GitHub, можете да го дадете URL-то на секој со кого сакате да го споделите вашиот проект. +Секој проект на GitHub е достапен преку HTTPS како `https://github.com/ / ` и над SSH како `git@github.com: / `. +Git може да преземе од и да им помогнам на двата од овие УРЛ-адреси, но тие се контролирани со пристап врз база на ингеренциите на корисникот што се поврзува со нив. [NOTE] ==== -It is often preferable to share the HTTPS based URL for a public project, since the user does not have to have a GitHub account to access it for cloning. -Users will have to have an account and an uploaded SSH key to access your project if you give them the SSH URL. -The HTTPS one is also exactly the same URL they would paste into a browser to view the project there. +Често е подобро да се сподели HTTPS базиран URL за јавен проект, бидејќи корисникот не мора да има GitHub сметка за да го пристапи за клонирање. +Корисниците ќе мора да имаат сметка и подигнато SSH клуч за пристап до вашиот проект, ако им го дадете SSH URL-то. +HTTPS-от е исто така иста URL-адреса што тие ќе ја стават во прелистувачот за да го видат проектот таму. ==== -==== Adding Collaborators +==== Додавање на соработници -If you're working with other people who you want to give commit access to, you need to add them as ``collaborators''. -If Ben, Jeff, and Louise all sign up for accounts on GitHub, and you want to give them push access to your repository, you can add them to your project. -Doing so will give them ``push'' access, which means they have both read and write access to the project and Git repository. +Ако работите со други луѓе на кои сакате да им дадете пристап за пристап, треба да ги додадете како `` соработници ''. +Ако Бен, Џеф и Луиз се регистрираат за сметки на GitHub и сакате да им дадете пристап до вашето складиште, можете да ги додадете во вашиот проект. +Со тоа ќе им се даде пристап до "push", што значи дека имаат и пристап за читање и запишување на проектот и Git репозиториум. -Click the ``Settings'' link at the bottom of the right-hand sidebar. +Кликнете на врската "Поставувања" на дното на десната странична лента. .The repository settings link. image::images/reposettingslink.png[The repository settings link.] -Then select ``Collaborators'' from the menu on the left-hand side. -Then, just type a username into the box, and click ``Add collaborator.'' -You can repeat this as many times as you like to grant access to everyone you like. -If you need to revoke access, just click the ``X'' on the right-hand side of their row. +Потоа изберете "соработници" од менито на левата страна. +Потоа, едноставно внесете корисничко име во полето и кликнете `` Додај соработник. '' +Можете да го повторите ова онолку пати колку што сакате да им дадете пристап на сите што ги сакате. +Ако треба да го откажете пристапот, само кликнете на `` X '' на десната страна од нивниот ред. .Repository collaborators. image::images/collaborators.png[The repository collaborators box.] -==== Managing Pull Requests +==== Управување со барањата за повлекување -Now that you have a project with some code in it and maybe even a few collaborators who also have push access, let's go over what to do when you get a Pull Request yourself. +Сега кога имате проект со некој код во него, а можеби дури и неколку соработници кои исто така имаат притисни пристап, ајде да преминеме што да правиме кога ќе добиеш Барање за влечење. -Pull Requests can either come from a branch in a fork of your repository or they can come from another branch in the same repository. -The only difference is that the ones in a fork are often from people where you can't push to their branch and they can't push to yours, whereas with internal Pull Requests generally both parties can access the branch. +Барањата за повлекување или може да дојдат од гранка во вилушка на вашето складиште или тие можат да доаѓаат од друга гранка во истото складиште. +Единствената разлика е што оние во вилушка често се од луѓе каде што не можете да им помогнам на нивната гранка и тие не можат да им помогнам на вашите, додека со внатрешните Потребни барања генерално двете страни можат да пристапат до гранката. -For these examples, let's assume you are ``tonychacon'' and you've created a new Arduino code project named ``fade''. +За овие примери, да претпоставиме дека сте `` tonychacon '' и сте создале нов Arduino код проект наречен `` избледи ''. [[_email_notifications]] -===== Email Notifications +===== Известувања за е-пошта -Someone comes along and makes a change to your code and sends you a Pull Request. -You should get an email notifying you about the new Pull Request and it should look something like <<_email_pr>>. +Некој доаѓа заедно и прави промена на вашиот код и ви испраќа барање за повлекување. +Треба да добиете е-мејл за известување за новото барање за повлекување и треба да изгледа нешто како << _ email_pr >>. [[_email_pr]] .Email notification of a new Pull Request. image::images/maint-01-email.png[Pull Request email notification] -There are a few things to notice about this email. -It will give you a small diffstat -- a list of files that have changed in the Pull Request and by how much. -It gives you a link to the Pull Request on GitHub. -It also gives you a few URLs that you can use from the command line. +Има неколку работи што треба да ги забележите за оваа е-пошта. +Тоа ќе ви даде мал diffstat - листа на датотеки кои се променија во Потребното барање и колку. +Тоа ви дава линк до барањето за повлекување на GitHub. +Исто така, ви дава неколку URL-адреси што можете да ги користите од командната линија. -If you notice the line that says `git pull patch-1`, this is a simple way to merge in a remote branch without having to add a remote. -We went over this quickly in <>. -If you wish, you can create and switch to a topic branch and then run this command to merge in the Pull Request changes. +Ако ја забележите линијата која вели `git pull patch-1`, ова е едноставен начин да се спојат во оддалечена гранка без да мора да додадете далечински управувач. +Отидовме брзо ова во << ch05-distributed-git # _checking_out_remotes >>. +Ако сакате, можете да креирате и префрлите на гранка на тема и потоа стартувајте ја оваа команда за да се спојат во промените на барањето. -The other interesting URLs are the `.diff` and `.patch` URLs, which as you may guess, provide unified diff and patch versions of the Pull Request. -You could technically merge in the Pull Request work with something like this: +Другите интересни URL-и се адресите на ".diff" и ".patch", кои, како што може да претпоставите, обезбедуваат обединети разни и patch верзии на Pull Request. +Вие би можеле технички да се спојат во Работата со барање за повлекување со нешто слично: [source,console] ---- $ curl http://github.com/tonychacon/fade/pull/1.patch | git am ---- -===== Collaborating on the Pull Request +===== Соработка на барањето за повлекување -As we covered in <>, you can now have a conversation with the person who opened the Pull Request. -You can comment on specific lines of code, comment on whole commits or comment on the entire Pull Request itself, using GitHub Flavored Markdown everywhere. +Како што се опфатени во << ch06-github # ch06-github_flow >>, сега можете да разговарате со лицето кое го отворило барањето за влечење. +Можете да коментирате за конкретни линии на код, да коментирате за цели обврски или да коментирате за целото барање за повлекување, користејќи го GitHub Flavored Markdown насекаде. -Every time someone else comments on the Pull Request you will continue to get email notifications so you know there is activity happening. -They will each have a link to the Pull Request where the activity is happening and you can also directly respond to the email to comment on the Pull Request thread. +Секој пат кога некој друг ќе коментира за барањето за повлекување ќе продолжи да добива известувања преку e-mail, за да знаете дека се случува активност. +Секој од нив ќе има линк до Барањето за повлекување, каде што се случува активноста, а исто така можете директно да одговорите на е-поштата за да коментирате за низата за повлекување. .Responses to emails are included in the thread. image::images/maint-03-email-resp.png[Email response] -Once the code is in a place you like and want to merge it in, you can either pull the code down and merge it locally, either with the `git pull ` syntax we saw earlier, or by adding the fork as a remote and fetching and merging. +Откако кодот е на место кое ви се допаѓа и сакате да го вклучите, можете или да го повлечете кодот и да го споите локално, или со синтаксата `git pull ` што ја видовме претходно, или со додавање на вилушка како далечински и преземање и спојување. -If the merge is trivial, you can also just hit the ``Merge'' button on the GitHub site. -This will do a ``non-fast-forward'' merge, creating a merge commit even if a fast-forward merge was possible. -This means that no matter what, every time you hit the merge button, a merge commit is created. -As you can see in <<_merge_button>>, GitHub gives you all of this information if you click the hint link. +Ако спојувањето е тривијално, исто така можете само да го притиснете копчето `Merge '' на GitHub-страницата. +Ова ќе направи "не-брз напред" спојување, создавајќи залог за спојување дури и ако е можно брзо спојување. +Ова значи дека без оглед на тоа, секој пат кога ќе го достигнете копчето за спојување, се креира спојување. +Како што можете да видите во << _ merge_button >>, GitHub ви ги дава сите овие информации ако кликнете на линкот за навестување. [[_merge_button]] .Merge button and instructions for merging a Pull Request manually. image::images/maint-02-merge.png[Merge button] -If you decide you don't want to merge it, you can also just close the Pull Request and the person who opened it will be notified. +Ако одлучите дека не сакате да го споите, исто така можете само да го затворите барањето за повлекување и да го известите лицето кое го отворило. [[_pr_refs]] -===== Pull Request Refs +===== Барање за одмаглување -If you're dealing with a *lot* of Pull Requests and don't want to add a bunch of remotes or do one time pulls every time, there is a neat trick that GitHub allows you to do. -This is a bit of an advanced trick and we'll go over the details of this a bit more in <>, but it can be pretty useful. +Ако се занимавате со * многу * на Потребни Потврди и не сакате да додадете еден куп од далечински управувачи или да направите едно време да го повлечете секој пат, постои уреден трик што GitHub ви овозможува да го направите. +Ова е малку напреден трик и ние ќе ги надминеме деталите за ова малку повеќе во << ch10-git-internals # _refspec >>, но може да биде прилично корисно. -GitHub actually advertises the Pull Request branches for a repository as sort of pseudo-branches on the server. -By default you don't get them when you clone, but they are there in an obscured way and you can access them pretty easily. +GitHub всушност ги рекламира гранките за повлекување на барањето за складиште како вид на псевдо-филијали на серверот. +Стандардно, не ги добивате кога клонирате, но тие се таму на нејасен начин и можете лесно да пристапите до нив. -To demonstrate this, we're going to use a low-level command (often referred to as a ``plumbing'' command, which we'll read about more in <>) called `ls-remote`. -This command is generally not used in day-to-day Git operations but it's useful to show us what references are present on the server. +За да го демонстрираме ова, ние ќе користиме команда на ниско ниво (често нарекувана "водовод", која ќе ја прочитаме повеќе во << ch10-git-internals # _plumbing_porcelain >>), наречена ` ls-remote ". +Оваа команда генерално не се користи во секојдневни операции Git, но корисно е да ни покаже кои референци се присутни на серверот. -If we run this command against the ``blink'' repository we were using earlier, we will get a list of all the branches and tags and other references in the repository. +Ако ја извршуваме оваа команда против "blink" складиштето што го користевме порано, ќе добиеме листа на сите гранки и ознаки и други референци во складиштето. [source,console] ---- @@ -143,16 +143,16 @@ a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head 31a45fc257e8433c8d8804e3e848cf61c9d3166c refs/pull/4/merge ---- -Of course, if you're in your repository and you run `git ls-remote origin` or whatever remote you want to check, it will show you something similar to this. +Се разбира, ако сте во вашето складиште и извршувате `git ls-remote location` или што далечински сакате да проверите, тоа ќе ви покаже нешто слично на ова. -If the repository is on GitHub and you have any Pull Requests that have been opened, you'll get these references that are prefixed with `refs/pull/`. -These are basically branches, but since they're not under `refs/heads/` you don't get them normally when you clone or fetch from the server -- the process of fetching ignores them normally. +Ако складиштето е на GitHub и имате било какви Отвори за Повлекување кои се отворени, ќе ги добиете овие референци кои се префиксирани со `refs / pull /`. +Тие се во основа гранки, но бидејќи тие не се под `refs / heads /`, не ги добивате нормално кога клонирате или добивате од серверот - процесот на преземање ги игнорира нормално. -There are two references per Pull Request - the one that ends in `/head` points to exactly the same commit as the last commit in the Pull Request branch. -So if someone opens a Pull Request in our repository and their branch is named `bug-fix` and it points to commit `a5a775`, then in *our* repository we will not have a `bug-fix` branch (since that's in their fork), but we _will_ have `pull//head` that points to `a5a775`. -This means that we can pretty easily pull down every Pull Request branch in one go without having to add a bunch of remotes. +Постојат две референци по Барањето за повлекување - оној што завршува со `/ head` укажува на истата обврска како последната застапеност во гранката Барање за повлекување. +Значи, ако некој го отвори Барањето за повлекување во нашето складиште и нивната гранка се нарекува `bug-fix` и посочува да се изврши` a5a775`, тогаш во * нашето * складиште нема да имаме `branch fix` филијала (бидејќи тоа е во нивната вилушка), но ние ќе имаме `pull / / head` што укажува на` a5a775`. +Ова значи дека ние лесно можеме да ја повлечеме секоја филијала за повлекување на повик во една оди, без да мора да додадеме кутија од далечински управувачи. -Now, you could do something like fetching the reference directly. +Сега, можете да направите нешто како преземање на референцата директно. [source,console] ---- @@ -161,14 +161,14 @@ From https://github.com/libgit2/libgit2 * branch refs/pull/958/head -> FETCH_HEAD ---- -This tells Git, ``Connect to the `origin` remote, and download the ref named `refs/pull/958/head`.'' -Git happily obeys, and downloads everything you need to construct that ref, and puts a pointer to the commit you want under `.git/FETCH_HEAD`. -You can follow that up with `git merge FETCH_HEAD` into a branch you want to test it in, but that merge commit message looks a bit weird. -Also, if you're reviewing a *lot* of pull requests, this gets tedious. +Ова му кажува на Git, "Поврзете се со далечинскиот управувач" и повлечете го реф код наречен "refs / pull / 958 / head". ' +Git среќно се послужува и презема сè што ви е потребно за да го конструирате тој рефлектира и поставува покажувач кон саканата заложба под `.git / FETCH_HEAD`. +Можете да го следите тоа со `git спојување FETCH_HEAD` во гранка што сакате да ја тестирате, но таа порака за спојување изгледа малку чудно. +Исто така, ако разгледувате * многу * на барања за повлекување, ова станува досадно. -There's also a way to fetch _all_ of the pull requests, and keep them up to date whenever you connect to the remote. -Open up `.git/config` in your favorite editor, and look for the `origin` remote. -It should look a bit like this: +Исто така, постои начин да се донесат _all_ на барањата за повлекување, и да ги задржите во тек со секое поврзување со далечинскиот управувач. +Отворете `.git / config` во вашиот омилен уредувач и побарајте го далечинскиот управувач` потекло`. +Треба да изгледа малку вака: [source,ini] ---- @@ -177,10 +177,10 @@ It should look a bit like this: fetch = +refs/heads/*:refs/remotes/origin/* ---- -That line that begins with `fetch =` is a ``refspec.'' -It's a way of mapping names on the remote with names in your local `.git` directory. -This particular one tells Git, "the things on the remote that are under `refs/heads` should go in my local repository under `refs/remotes/origin`." -You can modify this section to add another refspec: +Таа линија што започнува со `fetch =` е `` refspec. '' +Тоа е начин на мапирање имиња на далечинскиот управувач со имиња во вашиот локален `.git` именик. +Ова особено кажува Git, "работите на далечинскиот управувач што се наоѓаат под" refs / heads "треба да одат во моето локално складиште под" refs / remotes / origin "." +Можете да го промените овој дел за да додадете уште еден рефлекс: [source,ini] ---- @@ -190,8 +190,8 @@ You can modify this section to add another refspec: fetch = +refs/pull/*/head:refs/remotes/origin/pr/* ---- -That last line tells Git, ``All the refs that look like `refs/pull/123/head` should be stored locally like `refs/remotes/origin/pr/123`.'' -Now, if you save that file, and do a `git fetch`: +Последната линија му кажува на Git, `` Сите рефлекти кои изгледаат како `refs / pull / 123 / head` треба да се складираат локално како` refs / remotes / origin / pr / 123`. '' +Сега, ако ја зачувате таа датотека и направете `git fetch`: [source,console] ---- @@ -203,8 +203,8 @@ $ git fetch # … ---- -Now all of the remote pull requests are represented locally with refs that act much like tracking branches; they're read-only, and they update when you do a fetch. -This makes it super easy to try the code from a pull request locally: +Сега сите барања за далечинско повлекување се претставени локално со рефлекти кои делуваат како проследени гранки; тие се само за читање, и тие се ажурираат кога ќе направите донеси. +Ова го прави супер лесно да се обиде кодот од барање за повлекување на локално ниво: [source,console] ---- @@ -214,86 +214,86 @@ Branch pr/2 set up to track remote branch pr/2 from origin. Switched to a new branch 'pr/2' ---- -The eagle-eyed among you would note the `head` on the end of the remote portion of the refspec. -There's also a `refs/pull/#/merge` ref on the GitHub side, which represents the commit that would result if you push the ``merge'' button on the site. -This can allow you to test the merge before even hitting the button. +На орел очи меѓу вас ќе се забележи на "главата" на крајот на далечинскиот дел од refspec. +Исто така има и "refs / pull / # / merge" ref на GitHub страна, што претставува залог што ќе резултира ако го притиснете копчето `` спојување '' на страницата. +Ова може да ви овозможи да го тестирате спојувањето пред да го притиснете копчето. -===== Pull Requests on Pull Requests +===== Повлечете Барања за Повлекување Барања -Not only can you open Pull Requests that target the main or `master` branch, you can actually open a Pull Request targeting any branch in the network. -In fact, you can even target another Pull Request. +Не само што може да ги отворите барањата за повлекување кои се насочени кон главната или `майстер` филијалата, всушност можете да отворите барање за повлекување насочено кон било која гранка во мрежата. +Всушност, можете дури и да наведете друго барање за повлекување. -If you see a Pull Request that is moving in the right direction and you have an idea for a change that depends on it or you're not sure is a good idea, or you just don't have push access to the target branch, you can open a Pull Request directly to it. +Ако видите Барање за влечење кое се движи во вистинската насока и имате идеја за промена која зависи од неа или не сте сигурни дека е добра идеја или едноставно немате пристап до тастатурата до целните гранки, можете директно да го отворите барањето за повлекување. -When you go to open a Pull Request, there is a box at the top of the page that specifies which branch you're requesting to pull to and which you're requesting to pull from. -If you hit the ``Edit'' button at the right of that box you can change not only the branches but also which fork. +Кога одите за да отворите барање за повлекување, има кутија на врвот на страницата која одредува која гранка барате да се повлече и од која барате да се повлечете. +Ако го притиснете копчето `` Измени '' десно од тоа поле, можете да ги промените не само гранките, туку и која вилушка. [[_pr_targets]] .Manually change the Pull Request target fork and branch. image::images/maint-04-target.png[PR targets] -Here you can fairly easily specify to merge your new branch into another Pull Request or another fork of the project. +Овде можете прилично лесно да одредите за да ја споите вашата нова гранка во друго барање за повлекување или друга вилушка на проектот. -==== Mentions and Notifications +==== Цели и известувања -GitHub also has a pretty nice notifications system built in that can come in handy when you have questions or need feedback from specific individuals or teams. +GitHub, исто така, има прилично убав систем за известувања изграден во тоа што може да ни се најде кога имате прашања или ви требаат повратни информации од одредени поединци или тимови. -In any comment you can start typing a `@` character and it will begin to autocomplete with the names and usernames of people who are collaborators or contributors in the project. +Во секој коментар можете да почнете да пишувате знак `@` и ќе започне автоматски да се заврши со имињата и корисничките имиња на луѓе кои се соработници или соработници во проектот. .Start typing @ to mention someone. image::images/maint-05-mentions.png[Mentions] -You can also mention a user who is not in that dropdown, but often the autocompleter can make it faster. +Можете исто така да споменете корисник кој не е во тоа паѓачко мени, но често автокомплетирот може да го направи побрз. -Once you post a comment with a user mention, that user will be notified. -This means that this can be a really effective way of pulling people into conversations rather than making them poll. -Very often in Pull Requests on GitHub people will pull in other people on their teams or in their company to review an Issue or Pull Request. +Откако ќе го објавите коментар со корисничко име, тој корисник ќе биде известен. +Ова значи дека ова може да биде навистина ефикасен начин за повлекување на луѓето во разговорите, наместо да ги прави анкетите. +Многу често во барањата за повлекување на GitHub луѓето ќе се повлечат во други луѓе во нивните тимови или во нивната компанија за да ги разгледаат прашањата за издавање или повлекување. -If someone gets mentioned on a Pull Request or Issue, they will be ``subscribed'' to it and will continue getting notifications any time some activity occurs on it. -You will also be subscribed to something if you opened it, if you're watching the repository or if you comment on something. -If you no longer wish to receive notifications, there is an ``Unsubscribe'' button on the page you can click to stop receiving updates on it. +Ако некој се споменува на барање за повлекување или проблем, тие ќе бидат "претплатени" на него и ќе продолжат да добиваат известувања секогаш кога ќе се случи некоја активност на неа. +Исто така, ќе се претплатите на нешто ако сте го отвориле, ако го гледате складиштето или ако коментирате за нешто. +Доколку повеќе не сакате да добивате известувања, на копчето "Отпишување" на страницата можете да кликнете за да престанете да добивате ажурирања на неа. .Unsubscribe from an Issue or Pull Request. image::images/maint-06-unsubscribe.png[Unsubscribe] -===== The Notifications Page +===== Страница за известувања -When we mention ``notifications'' here with respect to GitHub, we mean a specific way that GitHub tries to get in touch with you when events happen and there are a few different ways you can configure them. -If you go to the ``Notification center'' tab from the settings page, you can see some of the options you have. +Кога ги споменуваме "известувањата" тука во однос на GitHub, ние подразбираме специфичен начин на кој GitHub се обидува да стапи во контакт со вас кога се случуваат настани и постојат неколку различни начини на кои можете да ги конфигурирате. +Ако одите во табулаторот "Известување центар" од страницата со поставки, можете да видите некои од опциите кои ги имате. .Notification center options. image::images/maint-07-notifications.png[Notification center] -The two choices are to get notifications over ``Email'' and over ``Web'' and you can choose either, neither or both for when you actively participate in things and for activity on repositories you are watching. +Двата избори се да добијат известувања преку "Email" и над "Веб" и можете да изберете или, ниту за двете, кога активно учествувате во нештата и за активностите во складиштата што ги гледате. -====== Web Notifications +====== Веб известувања -Web notifications only exist on GitHub and you can only check them on GitHub. -If you have this option selected in your preferences and a notification is triggered for you, you will see a small blue dot over your notifications icon at the top of your screen as seen in <<_not_center>>. +Веб известувањата постојат само на GitHub и можете да ги проверите само на GitHub. +Ако ја изберете оваа опција во вашите претпочитани поставки и ќе се активира известување за вас, ќе видите мала сина точка над вашата икона за известувања на врвот на вашиот екран како што се гледа во << _ not_center >>. [[_not_center]] .Notification center. image::images/maint-08-notifications-page.png[Notification center] -If you click on that, you will see a list of all the items you have been notified about, grouped by project. -You can filter to the notifications of a specific project by clicking on its name in the left hand sidebar. -You can also acknowledge the notification by clicking the checkmark icon next to any notification, or acknowledge _all_ of the notifications in a project by clicking the checkmark at the top of the group. -There is also a mute button next to each checkmark that you can click to not receive any further notifications on that item. +Ако кликнете на тоа, ќе видите листа на сите предмети за кои сте известувани, групирани според проект. +Можете да филтрирате за известувања за одреден проект со кликнување на неговото име во левата страна лента. +Можете исто така да го потврдите известувањето со кликање на иконата за знаци покрај известувањето или потврдување на сите известувања во проект со кликнување на белешка на врвот на групата. +Исто така, постои копче за неми веднаш до секоја ознака за проверка која можете да кликнете за да не примате дополнителни известувања за таа ставка. -All of these tools are very useful for handling large numbers of notifications. -Many GitHub power users will simply turn off email notifications entirely and manage all of their notifications through this screen. +Сите овие алатки се многу корисни за ракување со голем број на известувања. +Многу корисници на енергија од GitHub едноставно ќе ги исклучат известувањата за е-пошта и ќе управуваат со сите нивни известувања преку овој екран. -====== Email Notifications +====== Известувања за е-пошта -Email notifications are the other way you can handle notifications through GitHub. -If you have this turned on you will get emails for each notification. -We saw examples of this in <<_email_notification>> and <<_email_pr>>. -The emails will also be threaded properly, which is nice if you're using a threading email client. +Е-пошта известувања се на друг начин со кој можете да се справите со известувања преку GitHub. +Ако го вклучите ова, ќе добивате е-пораки за секое известување. +Видовме пример за тоа во << _ email_notification >> и << _ email_pr >>. +Е-пораките, исто така, ќе бидат наведуваат правилно, што е убаво ако користите е-пошта клиент. -There is also a fair amount of metadata embedded in the headers of the emails that GitHub sends you, which can be really helpful for setting up custom filters and rules. +Постои, исто така, фер износ на метаподатоци вградени во насловите на пораките што ги испраќа GitHub, што може навистина да биде корисно за поставување на сопствени филтри и правила. -For instance, if we look at the actual email headers sent to Tony in the email shown in <<_email_pr>>, we will see the following among the information sent: +На пример, ако ги погледнеме актуелните заглавија на е-пошта испратени до Тони во е-поштата прикажана во << _ email_pr >>, меѓу испратените информации ќе ги видиме следните: [source,mbox] ---- @@ -308,71 +308,71 @@ List-Unsubscribe: ,... X-GitHub-Recipient-Address: tchacon@example.com ---- -There are a couple of interesting things here. -If you want to highlight or re-route emails to this particular project or even Pull Request, the information in `Message-ID` gives you all the data in `///` format. -If this were an issue, for example, the `` field would have been ``issues'' rather than ``pull''. +Тука има неколку интересни работи. +Ако сакате да ги означите или пренасочите е-пораките до овој конкретен проект или дури и барањето за повлекување, информациите во `Message-ID` ви ги даваат сите податоци во` / / / формат. +Ако ова беше проблем, на пример, полето `<тип>` би било `` прашања '', наместо `` повлече ''. -The `List-Post` and `List-Unsubscribe` fields mean that if you have a mail client that understands those, you can easily post to the list or ``Unsubscribe'' from the thread. -That would be essentially the same as clicking the ``mute'' button on the web version of the notification or ``Unsubscribe'' on the Issue or Pull Request page itself. +Полињата `List-Post` и` List-Unsubscribe` значи дека ако имате клиент-пошта што ги разбира тие, можете лесно да објавувате во листата или "Отпиши" од низата. +Тоа би било во суштина исто како и кликнувањето на копчето `` неми '' на веб-верзијата на известувањето или ,, Отпишување '' на самата страница за издавање или потпишување. -It's also worth noting that if you have both email and web notifications enabled and you read the email version of the notification, the web version will be marked as read as well if you have images allowed in your mail client. +Исто така вреди да се напомене дека ако имате овозможено и е-мејл и веб известувања и ја читате верзијата за е-пошта на известувањето, веб-верзијата ќе биде означена и како прочитана, ако имате слики дозволени во вашиот клиент за пошта. -==== Special Files +=== Специјални датотеки -There are a couple of special files that GitHub will notice if they are present in your repository. +Постојат неколку специјални датотеки што GitHub ќе ги забележи ако тие се присутни во вашето складиште. ==== README -The first is the `README` file, which can be of nearly any format that GitHub recognizes as prose. -For example, it could be `README`, `README.md`, `README.asciidoc`, etc. -If GitHub sees a README file in your source, it will render it on the landing page of the project. +Првата е датотеката `README`, која може да биде со скоро било кој формат кој GitHub го препознава како проза. +На пример, тоа би можело да биде `README`,` README.md`, `README.asciidoc`, итн. +Ако GitHub гледа датотека README во вашиот извор, таа ќе ја прикаже на целниот страница на проектот. -Many teams use this file to hold all the relevant project information for someone who might be new to the repository or project. -This generally includes things like: +Многу тимови ја користат оваа датотека за да ги содржат сите релевантни информации за проектот за некој кој може да биде нов во складиштето или проектот. +Ова обично вклучува работи како: -* What the project is for -* How to configure and install it -* An example of how to use it or get it running -* The license that the project is offered under -* How to contribute to it +* За што работи проектот +* Како да го конфигурирате и инсталирате +* Пример за тоа како да го користите или да го стартувате +* Лиценцата што проектот е понудена под +* Како да се придонесе кон тоа -Since GitHub will render this file, you can embed images or links in it for added ease of understanding. +Бидејќи GitHub ќе ја направи оваа датотека, можете да вградите слики или линкови во неа за да додадете лесно разбирање. -==== CONTRIBUTING +==== придонес -The other special file that GitHub recognizes is the `CONTRIBUTING` file. -If you have a file named `CONTRIBUTING` with any file extension, GitHub will show <<_contrib_file>> when anyone starts opening a Pull Request. +Другата специјална датотека што GitHub ја препознава е датотеката "ДОПОЛНИТЕЛНИ". +Ако имате датотека со име `ПРИДРУЖУВАЊЕ` со која било проширена датотека, GitHub ќе покаже << _ contrib_file >> кога некој почнува да отвора барање за повлекување. [[_contrib_file]] .Opening a Pull Request when a CONTRIBUTING file exists. image::images/maint-09-contrib.png[Contributing notice] -The idea here is that you can specify specific things you want or don't want in a Pull Request sent to your project. -This way people may actually read the guidelines before opening the Pull Request. +Идејата овде е дека можете да наведете конкретни работи што сакате или не сакате во Барањето за повлекување испратено до вашиот проект. +На овој начин луѓето всушност можат да ги прочитаат упатствата пред да го отворат барањето за повлекување. -==== Project Administration +==== Администрација на проекти -Generally there are not a lot of administrative things you can do with a single project, but there are a couple of items that might be of interest. +Општо земено, нема многу административни работи што можете да ги направите со еден проект, но има неколку елементи кои би можеле да бидат од интерес. -===== Changing the Default Branch +===== Промена на почетната гранка -If you are using a branch other than ``master'' as your default branch that you want people to open Pull Requests on or see by default, you can change that in your repository's settings page under the ``Options'' tab. +Ако користите друга гранка освен "господар" како стандардна гранка за која сакате луѓето да ги отворат Повлече барањата или стандардно гледаат, можете да го промените тоа во страницата со поставки на вашето складиште под табулаторот "Опции". [[_default_branch]] .Change the default branch for a project. image::images/maint-10-default-branch.png[Default branch] -Simply change the default branch in the dropdown and that will be the default for all major operations from then on, including which branch is checked out by default when someone clones the repository. +Едноставно променете ја стандардната гранка во паѓачкото мени и тоа ќе биде стандардно за сите поголеми операции од тогаш, вклучувајќи ја и која гранка се стандардно проверува кога некој клонира складиштето. -===== Transferring a Project +===== Пренесување на проект -If you would like to transfer a project to another user or an organization in GitHub, there is a ``Transfer ownership'' option at the bottom of the same ``Options'' tab of your repository settings page that allows you to do this. +Ако сакате да префрлите проект на друг корисник или организација во GitHub, постои опција `` Трансфер на сопственост '' на дното на истата картичка 'Опции' на страницата за поставувања на складиште кое ви овозможува да го направите ова . [[_transfer_project]] .Transfer a project to another GitHub user or Organization. image::images/maint-11-transfer.png[Transfer] -This is helpful if you are abandoning a project and someone wants to take it over, or if your project is getting bigger and want to move it into an organization. +Ова е корисно ако го напуштате проектот и некој сака да го превземете, или ако вашиот проект станува поголем и сакате да го преместите во некоја организација. -Not only does this move the repository along with all its watchers and stars to another place, it also sets up a redirect from your URL to the new place. -It will also redirect clones and fetches from Git, not just web requests. +Ова не само што го поместува складиштето заедно со сите негови гледачи и ѕвезди на друго место, туку исто така поставува пренасочување од вашиот URL до новото место. +Исто така, ќе ги пренасочува клоновите и гревовите од Git, а не само веб-барањата. diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index f3137e5dc..cfa0a5b9f 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -1,72 +1,72 @@ [[ch06-github_orgs]] -=== Managing an organization +=== Управување со организација (((GitHub, organizations))) -In addition to single-user accounts, GitHub has what are called Organizations. -Like personal accounts, Organizational accounts have a namespace where all their projects exist, but many other things are different. -These accounts represent a group of people with shared ownership of projects, and there are many tools to manage subgroups of those people. -Normally these accounts are used for Open Source groups (such as ``perl'' or ``rails'') or companies (such as ``google'' or ``twitter''). +Во прилог на сметки за еден корисник, GitHub ги има и оние што се нарекуваат Организации. +Како лични сметки, организациските сметки имаат именски простор каде сите нивни проекти постојат, но многу други работи се различни. +Овие сметки претставуваат група на луѓе со заедничка сопственост на проекти, и постојат многу алатки за управување со подгрупи на тие луѓе. +Нормално, овие сметки се користат за групи со отворен код (како што се `` perl '' или `` шините '') или компании (како што се `` google '' или `` twitter ''). -==== Organization Basics +==== Основи на организацијата -An organization is pretty easy to create; just click on the ``+'' icon at the top-right of any GitHub page, and select ``New organization'' from the menu. +Организација е прилично лесно да се создаде; само кликнете на иконата `` + '' во горниот десен агол на секоја страница на GitHub и од менито изберете "Нова организација". .The ``New organization'' menu item. image::images/neworg.png[The ``New organization'' menu item.] -First you'll need to name your organization and provide an email address for a main point of contact for the group. -Then you can invite other users to be co-owners of the account if you want to. +Прво, ќе треба да ја именувате вашата организација и да обезбедите е-адреса за главна точка за контакт за групата. +Потоа можете да поканите други корисници да бидат ко-сопственици на сметката ако сакате. -Follow these steps and you'll soon be the owner of a brand-new organization. -Like personal accounts, organizations are free if everything you plan to store there will be open source. +Следете ги овие чекори и наскоро ќе бидете сопственик на сосема нова организација. +Како лични сметки, организациите се бесплатни ако сè што планирате да го складирате таму ќе биде со отворен код. -As an owner in an organization, when you fork a repository, you'll have the choice of forking it to your organization's namespace. -When you create new repositories you can create them either under your personal account or under any of the organizations that you are an owner in. -You also automatically ``watch'' any new repository created under these organizations. +Како сопственик во некоја организација, кога ќе го разиграте складиштето, ќе имате можност да го наместите на именскиот простор на вашата организација. +Кога креирате нови складишта, можете да ги создадете или под вашата лична сметка или под било која од организациите во кои сте сопственик. +Вие исто така автоматски `` гледате '' секое ново складиште креирано под овие организации. -Just like in <<_personal_avatar>>, you can upload an avatar for your organization to personalize it a bit. -Also just like personal accounts, you have a landing page for the organization that lists all of your repositories and can be viewed by other people. +Исто како и во << _ personal_avatar >>, можете да испратите аватар за вашата организација да го персонализирате малку. +Исто така, исто како и личните сметки, имате целна страница за организацијата во која се наведени сите ваши складишта и може да бидат видени од други луѓе. -Now let's cover some of the things that are a bit different with an organizational account. +Сега да ги покриеме некои од работите кои се малку различни со организациска сметка. -==== Teams +==== Тимови -Organizations are associated with individual people by way of teams, which are simply a grouping of individual user accounts and repositories within the organization and what kind of access those people have in those repositories. +Организации се поврзани со индивидуални луѓе преку тимови, кои се едноставно групирање на индивидуални кориснички сметки и складишта во рамките на организацијата и каков вид пристап имаат тие луѓе во тие складишта. -For example, say your company has three repositories: `frontend`, `backend`, and `deployscripts`. -You'd want your HTML/CSS/JavaScript developers to have access to `frontend` and maybe `backend`, and your Operations people to have access to `backend` and `deployscripts`. -Teams make this easy, without having to manage the collaborators for every individual repository. +На пример, велат дека вашата компанија има три складишта: `frontend`,` backend` и `deployscripts`. +Ќе сакате вашите развивачи на HTML / CSS / JavaScript да имаат пристап до `frontend`, а можеби` backend`, а вашите оператори да имаат пристап до `backend` и` deployscripts`. +Тимовите го прават тоа лесно, без да мора да управуваат со соработниците за секое поединечно складиште. -The Organization page shows you a simple dashboard of all the repositories, users and teams that are under this organization. +Страницата Организација ви покажува едноставна табла на сите складишта, корисници и тимови кои се под оваа организација. [[_org_page]] .The Organization page. image::images/orgs-01-page.png[] -To manage your Teams, you can click on the Teams sidebar on the right hand side of the page in <<_org_page>>. -This will bring you to a page you can use to add members to the team, add repositories to the team or manage the settings and access control levels for the team. -Each team can have read only, read/write or administrative access to the repositories. -You can change that level by clicking the ``Settings'' button in <<_team_page>>. +За да управувате со вашите тимови, можете да кликнете на страничната лента Тимови на десната страна на страницата во << _ org_page >>. +Ова ќе ве однесе на страница што можете да ја користите за да додадете членови во тимот, да додадете складишта во тимот или да управувате со поставките и нивоата за контрола на пристап за тимот. +Секој тим може да има само читање, читање / запишување или административен пристап до складиштата. +Можете да го промените тоа ниво со кликнување на копчето `` Settings '' во << _ team_page >>. [[_team_page]] .The Team page. image::images/orgs-02-teams.png[] -When you invite someone to a team, they will get an email letting them know they've been invited. +Кога ќе поканите некого во тим, тие ќе добијат е-маил допуштајќи им да знаат дека биле поканети. -Additionally, team `@mentions` (such as `@acmecorp/frontend`) work much the same as they do with individual users, except that *all* members of the team are then subscribed to the thread. -This is useful if you want the attention from someone on a team, but you don't know exactly who to ask. +Покрај тоа, тимот `@ mentions` (како што се` @ acmecorp / frontend`) функционира исто како и кај индивидуалните корисници, освен што * сите * членови на тимот потоа се претплатени на низата. +Ова е корисно ако сакате внимание од некој во тимот, но не знаете точно кој да праша. -A user can belong to any number of teams, so don't limit yourself to only access-control teams. -Special-interest teams like `ux`, `css`, or `refactoring` are useful for certain kinds of questions, and others like `legal` and `colorblind` for an entirely different kind. +Корисникот може да припаѓа на било кој број на тимови, па не се ограничувајте само на тимовите за контрола на пристап. +Тимови со посебен интерес како `ux`,` css` или `refactoring` се корисни за одредени видови прашања, а други како` legal` и `colorblind` за сосема поинаков вид. -==== Audit Log +==== Извештај за ревизија -Organizations also give owners access to all the information about what went on under the organization. -You can go to the 'Audit Log' tab and see what events have happened at an organization level, who did them and where in the world they were done. +Организации, исто така, им овозможуваат на сопствениците пристап до сите информации за тоа што се случувало во рамките на организацијата. +Можете да отидете на табулаторот "Ревизија на дневникот" и да видиме кои настани се случиле на ниво на организација, кои ги направиле и каде во светот биле направени. [[_the_audit_log]] .The Audit log. image::images/orgs-03-audit.png[] -You can also filter down to specific types of events, specific places or specific people. +Можете исто така да се филтрирате на одредени типови на настани, одредени места или конкретни луѓе. \ No newline at end of file diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 6bfb16e77..71c9811c3 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -1,63 +1,63 @@ -=== Scripting GitHub +=== Скриптирање на GitHub -So now we've covered all of the major features and workflows of GitHub, but any large group or project will have customizations they may want to make or external services they may want to integrate. +Значи сега ги опфаќаме сите главни карактеристики и работни текови на GitHub, но секоја голема група или проект ќе има прилагодувања што можеби ќе сакаат да ги направат или надворешни услуги што можеби ќе сакаат да ги интегрираат. -Luckily for us, GitHub is really quite hackable in many ways. -In this section we'll cover how to use the GitHub hooks system and its API to make GitHub work how we want it to. +За среќа, за нас, GitHub е навистина прифатлив на многу начини. +Во овој дел ќе покриеме како да го користиме системот GitHub и неговите API за да го направат GitHub да работи како сакаме. -==== Services and Hooks +==== Услуги и Куки -The Hooks and Services section of GitHub repository administration is the easiest way to have GitHub interact with external systems. +Одделот за куки и услуги на администрацијата на складиштето GitHub е најлесниот начин да се комуницира GitHub со надворешни системи. -===== Services +===== Услуги -First we'll take a look at Services. -Both the Hooks and Services integrations can be found in the Settings section of your repository, where we previously looked at adding Collaborators and changing the default branch of your project. -Under the ``Webhooks and Services'' tab you will see something like <<_services_hooks>>. +Прво ќе ги разгледаме Услугите. +И интеграциите на "Куки" и "Услуги" може да се најдат во делот за поставувања на вашето складиште, каде што претходно размислувавме да додаваме соработници и да ја смениме стандардната гранка на вашиот проект. +Под табот "Веб-книги и услуги" ќе видите нешто како << _ services_hooks >>. [[_services_hooks]] .Services and Hooks configuration section. image::images/scripting-01-services.png[Services and hooks] -There are dozens of services you can choose from, most of them integrations into other commercial and open source systems. -Most of them are for Continuous Integration services, bug and issue trackers, chat room systems and documentation systems. -We'll walk through setting up a very simple one, the Email hook. -If you choose ``email'' from the ``Add Service'' dropdown, you'll get a configuration screen like <<_service_config>>. +Постојат десетици услуги од кои можете да изберете, од кои повеќето се интегрира во други комерцијални и софтвер со отворен код. +Повеќето од нив се за услугите за континуирана интеграција, бубачки и издавачи, системи за разговор и системи за документација. +Ние ќе одиме преку поставување на многу едноставна, е-пошта кука. +Ако изберете "email" од паѓачкото мени "Add Service", ќе добиете конфигурациски екран како << _ service_config >>. [[_service_config]] .Email service configuration. image::images/scripting-02-email-service.png[Email service] -In this case, if we hit the ``Add service'' button, the email address we specified will get an email every time someone pushes to the repository. -Services can listen for lots of different types of events, but most only listen for push events and then do something with that data. +Во овој случај, ако го достигнеме копчето "Додај услуга", адресата на е-поштата што ја наведовме ќе добие е-пошта секој пат кога некој ќе турка до складиштето. +Услугите можат да слушаат многу различни типови на настани, но повеќето само слушаат за притисни настани, а потоа прават нешто со тие податоци. -If there is a system you are using that you would like to integrate with GitHub, you should check here to see if there is an existing service integration available. -For example, if you're using Jenkins to run tests on your codebase, you can enable the Jenkins builtin service integration to kick off a test run every time someone pushes to your repository. +Ако постои систем кој го користите што би сакале да се интегрирате со GitHub, треба да проверите тука за да видите дали постои достапна интеграција на сервисите. +На пример, ако користите Jenkins да извршувате тестови на вашата codebase, можете да ја овозможите Jenkins вградената интеграција на сервиси за да започнете тест пробни секој пат кога некој ќе турка до вашето складиште. -===== Hooks +===== Куки -If you need something more specific or you want to integrate with a service or site that is not included in this list, you can instead use the more generic hooks system. -GitHub repository hooks are pretty simple. -You specify a URL and GitHub will post an HTTP payload to that URL on any event you want. +Ако ви треба нешто поспецифично или сакате да се интегрирате со некоја услуга или сайт кој не е вклучен во оваа листа, наместо тоа, можете да го користите системот со повеќе генерички куки. +Куките за складирање на GitHub се прилично едноставни. +Вие наведете URL и GitHub ќе објави HTTP носивост на таа УРЛ на кој било настан што го сакате. -Generally the way this works is you can setup a small web service to listen for a GitHub hook payload and then do something with the data when it is received. +Генерално, начинот на кој работи е, можете да поставите мала веб-услуга за да слушате GitHub товар и потоа да направите нешто со податоците кога ќе се примат. -To enable a hook, you click the ``Add webhook'' button in <<_services_hooks>>. -This will bring you to a page that looks like <<_web_hook>>. +За да овозможите кука, кликнете на копчето `Додај webhook '' во << _ services_hooks >>. +Ова ќе ве однесе на страница што изгледа како << _ web_hook >>. [[_web_hook]] .Web hook configuration. image::images/scripting-03-webhook.png[Web hook] -The configuration for a web hook is pretty simple. -In most cases you simply enter a URL and a secret key and hit ``Add webhook''. -There are a few options for which events you want GitHub to send you a payload for -- the default is to only get a payload for the `push` event, when someone pushes new code to any branch of your repository. +Конфигурацијата за веб-кука е прилично едноставна. +Во повеќето случаи, едноставно внесете URL и таен клуч и кликнете "Додај webhook". +Постојат неколку опции за кои настани сакате GitHub да ви испрати товар - стандардно е да се добие само товар за настанот, кога некој турка нов код во која било гранка на вашето складиште. -Let's see a small example of a web service you may set up to handle a web hook. -We'll use the Ruby web framework Sinatra since it's fairly concise and you should be able to easily see what we're doing. +Ајде да видиме мал пример на веб-сервис што може да го поставите за да се справи со веб-јамка. +Ќе ја користиме рубинската веб-структура Синатра, бидејќи е прилично концизна и треба лесно да видите што правиме. -Let's say we want to get an email if a specific person pushes to a specific branch of our project modifying a specific file. -We could fairly easily do that with code like this: +Да речеме дека сакаме да добиеме е-пошта ако одредена личност турка до одредена гранка на нашиот проект, модифицирајќи ја специфичната датотека. +Ние можеме прилично лесно да го сториме тоа со код вака: [source,ruby] ---- @@ -93,37 +93,37 @@ post '/payload' do end ---- -Here we're taking the JSON payload that GitHub delivers us and looking up who pushed it, what branch they pushed to and what files were touched in all the commits that were pushed. -Then we check that against our criteria and send an email if it matches. +Овде земаме JSON корист што GitHub нè испорачува и гледа во тоа кој го турна, на која гранка се туркаа и кои датотеки беа допрени во сите извршени задачи. +Потоа го проверуваме тоа според нашите критериуми и испраќаме е-пошта ако се совпаѓа. -In order to develop and test something like this, you have a nice developer console in the same screen where you set the hook up. -You can see the last few deliveries that GitHub has tried to make for that webhook. -For each hook you can dig down into when it was delivered, if it was successful and the body and headers for both the request and the response. -This makes it incredibly easy to test and debug your hooks. +Со цел да се развие и тестира нешто слично, имате убава конзола за програмери на истиот екран каде што ќе ја поставите куката. +Можете да ги видите последните неколку испораки што GitHub се обиде да ги направи за тој webhook. +За секоја кука можете да ископате кога ќе се испорача, ако е успешна и телото и заглавјата за барањето и за одговорот. +Ова го прави неверојатно лесен за тестирање и дебагирање на вашите куки. [[_web_hook_debug]] .Web hook debugging information. image::images/scripting-04-webhook-debug.png[Webhook debug] -The other great feature of this is that you can redeliver any of the payloads to test your service easily. +Другата одлична карактеристика на ова е што можете да го вратите било кој товар за лесно тестирање на вашата услуга. -For more information on how to write webhooks and all the different event types you can listen for, go to the GitHub Developer documentation at https://developer.github.com/webhooks/ +За повеќе информации за тоа како да напишете webhooks и сите различни типови на настани што можете да ги слушате, одете до документацијата за програмери GitHub на https://developer.github.com/webhooks/ -==== The GitHub API +==== GitHub API (((GitHub, API))) -Services and hooks give you a way to receive push notifications about events that happen on your repositories, but what if you need more information about these events? -What if you need to automate something like adding collaborators or labeling issues? +Услугите и куките ви даваат начин да добивате известувања за настаните што се случуваат во вашите складишта, но што ако ви требаат повеќе информации за овие настани? +Што ако треба да автоматизирате нешто како додавање на соработници или проблеми со етикетирање? -This is where the GitHub API comes in handy. -GitHub has tons of API endpoints for doing nearly anything you can do on the website in an automated fashion. -In this section we'll learn how to authenticate and connect to the API, how to comment on an issue and how to change the status of a Pull Request through the API. +Ова е местото каде што GitHub API е во корист. +GitHub има тони API крајни точки за правење речиси нешто што можете да го направите на веб-сајтот на автоматизиран начин. +Во овој дел ќе научиме како да се идентификуваме и да се поврземе со API, како да коментираме за некое прашање и како да го смените статусот на барање за повлекување преку API. -==== Basic Usage +==== Основна употреба -The most basic thing you can do is a simple GET request on an endpoint that doesn't require authentication. -This could be a user or read-only information on an open source project. -For example, if we want to know more about a user named ``schacon'', we can run something like this: +Најосновното нешто што можете да го направите е едноставно барање за ГЕТ на крајната точка која не бара автентикација. +Ова може да биде корисник или само за читање информации за проект со отворен код. +На пример, ако сакаме да дознаеме повеќе за корисник наречен `` schacon '', можеме да работиме вака: [source,javascript] ---- @@ -141,8 +141,8 @@ $ curl https://api.github.com/users/schacon } ---- -There are tons of endpoints like this to get information about organizations, projects, issues, commits -- just about anything you can publicly see on GitHub. -You can even use the API to render arbitrary Markdown or find a `.gitignore` template. +Постојат тони на крајните точки како што е ова за да добиете информации за организации, проекти, прашања, обврски - само за нешто што јавно може да го видите на GitHub. +Можете дури да го користите API за да направите произволен Markdown или да пронајдете шаблон `.gitignore`. [source,javascript] ---- @@ -166,32 +166,32 @@ hs_err_pid* ---- -==== Commenting on an Issue +==== Коментирајќи за проблемот -However, if you want to do an action on the website such as comment on an Issue or Pull Request or if you want to view or interact with private content, you'll need to authenticate. +Меѓутоа, ако сакате да направите некоја акција на веб-страница како што е коментар за прашање или барање за повлекување, или ако сакате да гледате или да комуницирате со приватна содржина, ќе треба да се идентификувате. -There are several ways to authenticate. -You can use basic authentication with just your username and password, but generally it's a better idea to use a personal access token. -You can generate this from the ``Applications'' tab of your settings page. +Постојат неколку начини за автентикација. +Можете да ја користите основната автентикација само со вашето корисничко име и лозинка, но генерално е подобра идеја да користите личен пристапен знак. +Можете да генерирате ова од табулаторот "Апликации" на вашата страница за поставки. [[_access_token]] .Generate your access token from the ``Applications'' tab of your settings page. image::images/scripting-05-access-token.png[Access Token] -It will ask you which scopes you want for this token and a description. -Make sure to use a good description so you feel comfortable removing the token when your script or application is no longer used. +Тоа ќе ве праша за кои области сакате за овој знак и опис. +Осигурајте се дека користите добар опис, за да се чувствувате удобно да го отстраните токенот кога вашата скрипта или апликација веќе не се користи. -GitHub will only show you the token once, so be sure to copy it. -You can now use this to authenticate in your script instead of using a username and password. -This is nice because you can limit the scope of what you want to do and the token is revocable. +GitHub само ќе ви го прикаже токен еднаш, па не заборавајте да го копирате. +Сега можете да го користите ова за да се идентификувате во вашата скрипта, наместо да користите корисничко име и лозинка. +Ова е убаво затоа што можете да го ограничите опсегот на она што сакате да го направите и токен да се отповика. -This also has the added advantage of increasing your rate limit. -Without authenticating, you will be limited to 60 requests per hour. -If you authenticate you can make up to 5,000 requests per hour. +Ова, исто така, има додадена предност за зголемување на вашата стапка. +Без проверка на автентичност, ќе бидете ограничени на 60 барања на час. +Ако се идентификувате, можете да направите до 5.000 барања на час. -So let's use it to make a comment on one of our issues. -Let's say we want to leave a comment on a specific issue, Issue #6. -To do so we have to do an HTTP POST request to `repos///issues//comments` with the token we just generated as an Authorization header. +Значи, да го искористиме за да дадеме коментар за едно од нашите проблеми. +Да речеме дека сакаме да оставиме коментар за одредено прашање, број 6. +За да го сториме тоа, ние треба да направиме HTTP POST барање до `repos / / / issues / / comments" со токенот кој штотуку го генериравме како заглавие за авторизација. [source,javascript] ---- @@ -215,23 +215,23 @@ $ curl -H "Content-Type: application/json" \ } ---- -Now if you go to that issue, you can see the comment that we just successfully posted as in <<_api_comment>>. +Сега, ако одите во тоа прашање, можете да го видите коментарот што ние едноставно успешно го објавивме како во << _ api_comment >>. [[_api_comment]] .A comment posted from the GitHub API. image::images/scripting-06-comment.png[API Comment] -You can use the API to do just about anything you can do on the website -- creating and setting milestones, assigning people to Issues and Pull Requests, creating and changing labels, accessing commit data, creating new commits and branches, opening, closing or merging Pull Requests, creating and editing teams, commenting on lines of code in a Pull Request, searching the site and on and on. +Можете да го користите API за да направите само нешто што можете да го направите на веб-страницата - креирање и поставување на пресвртници, доделување на луѓе на Issues and Pull Requests, креирање и менување етикети, пристап до податоци за извршување, создавање на нови обврски и филијали, отворање, затворање или спојување на барањата за влечење, креирање и уредување тимови, коментирање на линиите на код во барање за повлекување, пребарување на страницата и на и натаму. -==== Changing the Status of a Pull Request +==== Промена на статусот на барањето за потпишување -There is one final example we'll look at since it's really useful if you're working with Pull Requests. -Each commit can have one or more statuses associated with it and there is an API to add and query that status. +Постои еден последен пример што ќе го разгледаме, бидејќи тоа е навистина корисно ако работите со Потребно за повлекување. +Секоја посветеност може да има еден или повеќе статуси поврзани со него и има API за да го додаде и побара тој статус. -Most of the Continuous Integration and testing services make use of this API to react to pushes by testing the code that was pushed, and then report back if that commit has passed all the tests. -You could also use this to check if the commit message is properly formatted, if the submitter followed all your contribution guidelines, if the commit was validly signed -- any number of things. +Повеќето од услугите за континуирана интеграција и тестирање го користат овој API за да реагираат на туркање со тестирање на кодот кој бил турнат, а потоа да се пријави ако таа обврска ги поминала сите тестови. +Исто така, можете да го користите ова за да проверите дали пораката за извршување е правилно форматирана, ако подносителот ги следеше сите упатства за придонес, ако извршувањето беше валидно потпишано - било кој број работи. -Let's say you set up a webhook on your repository that hits a small web service that checks for a `Signed-off-by` string in the commit message. +Да речеме дека поставувате webhook на вашето складиште кое удира на мала веб-услуга која проверува за низа од "потпишана-надвор" во пораката за извршување. [source,ruby] ---- @@ -276,27 +276,27 @@ post '/payload' do end ---- -Hopefully this is fairly simple to follow. -In this web hook handler we look through each commit that was just pushed, we look for the string 'Signed-off-by' in the commit message and finally we POST via HTTP to the `/repos///statuses/` API endpoint with the status. +Се надевам дека ова е прилично едноставно да се следи. +Во овој управувач за веб-јамка гледаме низ секој извршен настан кој штотуку го туркавме, бараме низа "Signed-off-by" во пораката за извршување и конечно ќе поставиме преку HTTP на `/ repos / / / statuses / `крајната точка на API со статус. -In this case you can send a state ('success', 'failure', 'error'), a description of what happened, a target URL the user can go to for more information and a ``context'' in case there are multiple statuses for a single commit. -For example, a testing service may provide a status and a validation service like this may also provide a status -- the ``context'' field is how they're differentiated. +Во овој случај, можете да испратите држава ('успех', 'неуспех', 'грешка'), опис на она што се случило, целна адреса за која корисникот може да оди за повеќе информации и `` контекст '' во случај да постојат повеќе статуси за една посветеност. +На пример, сервисот за тестирање може да обезбеди статус и службата за валидација како оваа, исто така, може да обезбеди статус - полето `` context '' е како тие се диференцирани. -If someone opens a new Pull Request on GitHub and this hook is set up, you may see something like <<_commit_status>>. +Ако некој отвори ново барање за повлекување на GitHub и оваа кука е поставена, може да видите нешто како << commit_status >>. [[_commit_status]] .Commit status via the API. image::images/scripting-07-status.png[Commit status] -You can now see a little green check mark next to the commit that has a ``Signed-off-by'' string in the message and a red cross through the one where the author forgot to sign off. -You can also see that the Pull Request takes the status of the last commit on the branch and warns you if it is a failure. -This is really useful if you're using this API for test results so you don't accidentally merge something where the last commit is failing tests. +Сега можете да видите малку зелена ознака за обележување до извршувањето кое има порака `` Отпишано-оф-по '' во пораката и црвен крст преку оној во кој авторот заборавил да се потпише. +Исто така можете да видите дека барањето за повлекување го зема статусот на последното извршување на филијалата и ве предупредува дали е неуспех. +Ова е навистина корисно ако го користите овој API за резултатите од тестот, па не случајно може да се спојат нешто каде што последната заложба е неуспешни тестови. ==== Octokit -Though we've been doing nearly everything through `curl` and simple HTTP requests in these examples, several open-source libraries exist that make this API available in a more idiomatic way. -At the time of this writing, the supported languages include Go, Objective-C, Ruby, and .NET. -Check out http://github.com/octokit[] for more information on these, as they handle much of the HTTP for you. +Иако во овие примери практикуваме скоро сè преку `curl` и едноставни HTTP-барања, постојат неколку библиотеки со отворен код кои го прават овој API достапен на поизразено начин. +Во времето на ова пишување, поддржаните јазици вклучуваат Go, Objective-C, Ruby и .NET. +Проверете http://github.com/octokit [] за повеќе информации за овие, бидејќи тие се справи со голем дел од HTTP за вас. -Hopefully these tools can help you customize and modify GitHub to work better for your specific workflows. -For complete documentation on the entire API as well as guides for common tasks, check out https://developer.github.com[]. +Се надевам дека овие алатки може да ви помогнат да го прилагодите и менувате GitHub за да работат подобро за вашите конкретни работни процеси. +За комплетна документација за целиот API, како и водичи за вообичаени задачи, проверете https://developer.github.com [].