Github гайд: различия между версиями

Материал из Lost Paradise 14
Нет описания правки
Метка: отменено
(редакция 3.5, требуются картинки)
 
(не показана 21 промежуточная версия 3 участников)
Строка 1: Строка 1:
<h1 id="git-for-the-ss14-developer">Git for the SS14 Developer</h1>
= <center><big>'''Git для разработчика Космической Станции 14''' </big></center> =
<p>If you&#39;ve ever followed a hackily written guide to Git or opened up one of the many incredibly bloated modern git GUIs like GitKraken, you probably recognize that Git can be <em>really confusing</em>. The purpose of this guide is to give you just the information you need to develop properly for SS14 and give you the resources to learn more if necessary.</p>
Если вы когда-либо следовали халтурно написанному руководству по Git или открывали один из многих невероятно раздутых современных графических интерфейсов git, таких как GitKraken, вы, вероятно, понимаете, что Git может быть действительно запутанным. Цель этого руководства - предоставить вам только информацию, необходимую для правильной разработки для SS14, и предоставить ресурсы для изучения большего, если необходимо.
<p>Here are some more resources for learning about Git:</p>
<ul>
<li><a href="https://git-scm.com/book/en/v2">The Git-SCM online book</a></li>
<li><a href="https://www.atlassian.com/git/tutorials/setting-up-a-repository">Atlassian&#39;s git guides</a>. Good guides for some more advanced stuff</li>
<li><a href="https://ohshitgit.com/">Oh shit, Git?!</a>, a list of solutions to common git problems. This one will come in handy.</li>
<li><a href="https://learngitbranching.js.org/">Learn Git Branching</a>. This one is interactive, and very in-depth, but you <strong>will have learned Git by the end of it</strong>. Recommended for intermediate Git users.</li>
</ul>
<h2 id="1-setting-up-git-itself">1. Setting up Git itself</h2>
<p>```admonish danger &quot;DO NOT USE GITKRAKEN&quot;
For the love of god do not install GitKraken or GitHub Desktop. I have felt nothing but endless CBT trying to help people using either of them. I know GitKraken looks all professional and GH Desktop is nice and simple but please do not use either of them unless you know what you are doing.</p>
<pre><code>
If you were following our <span class="hljs-strong">**"Setting up a Development Environment"**</span> guide, you probably already have Git installed. If not, go to [<span class="hljs-string">their website</span>](<span class="hljs-link">https://git-scm.org</span>) and install it now. This will install the Git backend, as well as Git Bash (if you select that option)--one of the many ways you can actually use Git.  


If you're on Linux, you'll probably just be using Git through your terminal or whichever IDE you've chosen, and chances are you have it installed already.
Вот еще несколько ресурсов для изучения Git:


I highly recommend at least trying Git Bash (as will a lot of our developers), but there are friendlier alternatives many use that I'll be showing steps for here as well:
Онлайн-книга [https://git-scm.com/book/ru/v2 Git-SCM]


<span class="hljs-bullet">- </span>[<span class="hljs-string">TortoiseGit</span>](<span class="hljs-link">https://tortoisegit.org/</span>) -- old but gold Git GUI that shows info in the file explorer menu and makes basic stuff a breeze
[https://www.atlassian.com/git/tutorials/setting-up-a-repository Руководство Atlassian по Git]. Довольно простое и понятное.
<span class="hljs-bullet">- </span>[<span class="hljs-string">SmartGit</span>](<span class="hljs-link">https://www.syntevo.com/smartgit/</span>) -- fully featured Git GUI that's very customizable and simple to use


I won't have steps for these (I'm recommending these after I initially wrote this guide) but after trying some more there are other very, very good options:
[https://ohshitgit.com/ О черт, Git?!] список решений распространенных проблем с git. Этот вам тоже понадобится.


<span class="hljs-bullet">- </span>[<span class="hljs-string">Fork</span>](<span class="hljs-link">https://git-fork.com/</span>) -- fast and extremely ergonomic GUI, my personal favorite. "Non-free", but it's WinRAR-level non-free, so it's basically free. Has support for partial staging of
Изучите так-же [https://learngitbranching.js.org/?locale=ru_RU ветвление Git]. На данном сайте вы сможете познакомиться со всеми необходимыми функциями гита путём практики.  
<span class="hljs-bullet">- </span>[<span class="hljs-string">Sublime Merge</span>](<span class="hljs-link">https://www.sublimemerge.com/</span>) -- very similar to Fork, looks and feels great and I've gotten a lot of recommendations for it, though I haven't used it much. Also has support for partial staging.


Most IDEs have some form of Git integration as well. [<span class="hljs-string">JetBrains Rider</span>](<span class="hljs-link">https://www.jetbrains.com/rider/</span>)'s Git integration is really good (and I personally recommend Rider for everything SS14-development related). I don't recommend Visual Studio's Git integration, because it's.. not very good.
==Настройка вашего Git==
Ради всего святого, не используйте '''GitHub Desktop'''. Мы знаем, что '''GitHub Desktop''' красив и прост, но, пожалуйста, не используйте его, если вы не знаете, что делаете. Если вы следовали нашему руководству "Настройка среды разработки", у вас, вероятно, уже установлен Git. Если нет, перейдите на их [https://git-scm.com/ сайт] и установите его сейчас. Это позволит установить серверную часть Git, а также Git Bash (если вы выберете эту опцию) - один из многих способов, которыми вы действительно можете использовать Git.


While you're here, install <span class="hljs-code">`Python 3.7+`</span> as well if you don't have it already. You can do that [<span class="hljs-string">here</span>](<span class="hljs-link">https://www.python.org/</span>) for Windows and Mac, and if you're on Linux you almost certainly have Python installed already. If you don't, figure it out yourself, dork!
Если вы используете Linux, вы, вероятно, просто будете использовать Git через свой терминал или любую другую IDE, которую вы выбрали, и, скорее всего, она у вас уже установлена.


<span class="xml"><span class="hljs-tag">&lt;<span class="hljs-name">hr</span>&gt;</span></span>
Я настоятельно рекомендую хотя бы раз попробовать Git Bash (как и многие наши разработчики), но есть более удобные альтернативы, которые многие используют, и здесь я также покажу шаги для них:


<span class="hljs-code">```admonish danger "Name and Email privacy"
'''[https://tortoisegit.org/ TortoiseGit]''' - старый, но до сих пор актуальный графический интерфейс Git, который отображает информацию в меню проводника файлов и упрощает базовые вещи. '''[https://www.syntevo.com/smartgit/ SmartGit]''' - полнофункциональный графический интерфейс Git, в котором можно настроить многое под себя, а так-же простой в использовании.
When [setting up your `user.name` and `user.email`](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup#_your_identity), know that these are publicly displayed on all commits that you create. If you want to keep your information private, you can set `user.name` to your username instead of your real name, and `user.email` to the one provided by GitHub when the [`Keep my email addresses private`](https://github.com/settings/emails#toggle_visibility) setting is checked in [GitHub Email Settings](https://github.com/settings/emails#primary_email_select_label).</span>
</code></pre><p>Now that you have Git installed, I recommend you read up a bit on the basics of it first and get acquainted with whatever git client you&#39;re working with, whether its just command-line (Git Bash) or anything else.</p>
<p>We&#39;re going to run through the process of setting up a Git environment for Space Station 14 so that you can <strong>contribute code through pull requests, create your own codebase</strong>, or just <strong>check out the history of the project.</strong></p>
<h3 id="1-1-why-are-we-even-using-git-">1.1 Why are we even using Git?</h3>
<p>Git is <strong>version-control software</strong>--basically, it&#39;s an easy way to track changes to the code, and manage those changes without headaches. It&#39;s an invaluable tool for software development, because it easily lets you make new changes, view different changes, see who made changes, etc. without having to coordinate and tabulate everything yourself.</p>
<p>GitHub is an online service that hosts Git <strong>repositories</strong> (codebases) for easy collaboration. It&#39;s perfect for a codebase like SS14, with lots of contributors and lots of history. It also means that we&#39;re <em>open-source</em>--anyone can go to our GitHub and download the code!</p>
<h2 id="2-setting-up-your-repositories">2. Setting up your repositories</h2>
<p>Like I said before, a repository is just a codebase. Repositories contain some <strong>branches</strong>, and those branches contain different <strong>commits</strong>. You might have heard of both of these--I&#39;ll talk more about them in depth later.</p>
<p>A <strong>remote</strong> repository is just a repository&#39;s that&#39;s on GitHub. A <strong>local</strong> repository is one that&#39;s actually on your computer.</p>
<h3 id="2-1-creating-your-remote-repository">2.1 Creating your remote repository</h3>
<p>First, let&#39;s make our own remote repository fork of Space Station 14. You&#39;ll need a GitHub account for this, of course. &#39;Forking&#39; it like this just means you&#39;re copying all of the repository&#39;s history and changes into your own remote repository so that you can do stuff freely to the code.</p>
<p>Your remote repository doesn&#39;t automatically update with changes from the original SS14 repo--you&#39;ll have to do that yourself, which I&#39;ll talk about later.</p>
<p>Navigate to the <a href="https://github.com/space-wizards/space-station-14">Space Station 14 repository</a> and click here:</p>
<p><img src="https://i.imgur.com/lAHNHdD.png" alt=""></p>
<p>From there, it&#39;ll ask you where to fork it and what to name it--just to your regular account, and name it whatever you please! I&#39;d stick with <code>space-station-14</code> if you just want to help out with development, though.</p>
<h3 id="2-2-creating-your-local-repository">2.2 Creating your local repository</h3>
<p>Now, we&#39;ll need to download our remote repository onto our computer (<strong>cloning</strong>) so we can add <del>20 pairs of clown shoes to every locker</del> some changes to it. You <em>can</em> technically change your remote repository (GitHub has some nice tools), but having it on your computer means you use IDEs like Visual Studio or Rider to build the game and run tests, as well as handle Git stuff easily.</p>
<p>For every step, there will be screenshots and instructions for Git Bash, SmartGit, and TortoiseGit on Windows.</p>
<p>Navigate to somewhere on your computer where you want to put the local repository, and:</p>
<details><summary>TortoiseGit</summary>
<p>


Right click to see TortoiseGit&#39;s context menu stuff:
Есть другие, возможно более привычные вам альтернативы:


<img src="https://i.imgur.com/QGmrQmH.png" alt="">
'''[https://git-fork.com/ Fork]''' - понятный, эргономичный интерфейс, отличный вариант. "Платный", но на деле платный на уровне WinRAR, так что по сути он бесплатный. Имеет поддержку частичной промежуточной обработки.


</p>
'''[https://www.sublimemerge.com/ Sublime Merge]''' - очень похож на Fork. Также имеет поддержку частичной промежуточной обработки.
</details>


<details><summary>SmartGit</summary>
Большинство IDE также имеют ту или иную форму интеграции с Git. Интеграция с Git в JetBrains Rider.
<p>


Open up SmartGit and navigate to the desired location, then:
Не рекомендуется использовать Git-интерфейс в Visual Studio, поскольку в большинстве своём он ужасен. Лучший и рекомендуемый вариант это [https://www.jetbrains.com/rider/ JetBrains Rider].


<img src="https://i.imgur.com/C3JBYR6.png" alt="">
И пока вы здесь, установите также Python 3.7+, если у вас его еще нет. Вы можете сделать это [https://www.python.org/downloads/ здесь] для Windows и Mac, а если вы используете Linux, у вас почти наверняка уже установлен Python.
{|
|+
!При [https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup#_your_identity настройке вашего логина и почты] помните, что они публично отображаются во всех создаваемых вами коммит-файлах. Если вы хотите скрыть от остальных свою другую деятельность, вы можете это сделать через [https://github.com/settings/emails#toggle_visibility настройки приватности].
|-
|Теперь, когда у вас установлен Git, я рекомендую вам сначала немного ознакомиться с его основами и ознакомиться с любым клиентом git, с которым вы работаете, будь то просто командная строка (Git Bash) или что-либо еще.
Мы собираемся запустить процесс настройки среды Git для Space Station 14, чтобы вы могли вносить код с помощью запросов на извлечение, создавать свою собственную кодовую базу или просто просматривать историю проекта.
|}


</p>
===Зачем мы вообще используем Git?===
</details>
Git - это самая удобная платформа где можно контролировать каждую версию - по сути, это простой способ отслеживать изменения в коде и управлять этими изменениями без головной боли. Это бесценный инструмент для разработки программного обеспечения, потому что он позволяет легко вносить новые изменения, просматривать различные изменения, видеть, кто внес изменения, и т.д. без необходимости координировать и сводить все в таблицу самостоятельно.


<details><summary>Git Bash</summary>
GitHub - это онлайн-сервис, в котором размещены репозитории Git для удобства совместной работы. Он идеально подходит для такой базы кода, как SS14, с большим количеством участников и богатой историей. Это также означает, что у нас открытый исходный код - любой может зайти на [https://github.com/Lost-Paradise-Project/Lost-Paradise/tree/master наш GitHub] и скачать код!
<p>


Right click:
== Настройка вашего репозитория==
Как я уже говорилось ранее, репозиторий - это просто база кода. Репозитории содержат некоторые ветви, и эти ветви содержат разные коммиты. Возможно, вы слышали об обоих из них и знаете как работать, если прошли курс выше.


<img src="https://i.imgur.com/kIYnm16.png" alt="">
Удаленный (главный) репозиторий - это просто репозиторий, который находится на GitHub. Локальный репозиторий - это тот, который фактически находится на вашем компьютере и с которым работаете вы!


</p>
===Создание локального репозитория===
</details>
Сначала давайте создадим нашу собственную ветку удаленного репозитория Space Station 14. Для этого, конечно, вам понадобится учетная запись на GitHub. Такое "разветвление" просто означает, что вы копируете всю историю репозитория и изменения в свой собственный репозиторий, чтобы вы могли свободно вносить изменения в код и проверять их.


<hr>
Ваш локальный репозиторий не обновляется автоматически изменениями из исходного репозитория SS14 - вам придется сделать это самостоятельно, о чём мы поговорим позже.


<p>Then, we&#39;ll enter the command for cloning <strong>our</strong> remote repository--not the <code>space-wizards/space-station-14</code> repository.</p>
Перейдите в репозиторий Lost-Paradise и создайте ветвь [https://github.com/Lost-Paradise-Project/Lost-Paradise/fork здесь]:
<details><summary>TortoiseGit</summary>
<p>


<img src="https://i.imgur.com/3HzCnjm.png" alt="">
После этого он спросит вас, где разместить его и как назвать - не переживайте, никто не узнает как вы его назвали. Назовите его так, как вам заблагорассудится!
<img src="https://i.imgur.com/a7vhKcC.png" alt="">


Теперь нам нужно загрузить наш удаленный репозиторий на ваш компьютер (клонировать), чтобы мы могли добавить 20 пар клоунской обуви в каждый шкафчик. Технически вы можете изменить свой удаленный репозиторий (на GitHub есть несколько полезных инструментов), но наличие его на вашем компьютере означает, что вы используете IDE, такие как Visual Studio или Rider, для сборки игры и запуска тестов, а также для простой обработки материалов Git.


</p>
Теперь, на вашем компьютере, куда вы хотите поместить локальный репозиторий, и затем мы введем команду для клонирования нашего удаленного репозитория - не репозитория Einstein engine / RobustToolbox.
</details> 


<details><summary>SmartGit</summary>
После всех этих махинаций, у вас будет локальный репозиторий, который теперь вы можете изменять! Однако предстоит выполнить еще некоторые настройки.
<p>


<img src="https://i.imgur.com/YyJm5fx.png" alt="">
===Проблемы с субмодулями===
Обратите на это внимание! Если вы этого не сделаете, вы получите множество странных ошибок о том, что материал недоступен, когда вы будете пытаться запустить билд.


У Space Station 14 есть много субмодулей, в первую очередь наш движок, RobustToolbox. Субмодули - это просто репозитории внутри репозитория. Не переживайте, их обновление можно автоматизировать.


</p>
У нас есть программа автоматического обновления субмодулей, поэтому вам не нужно беспокоиться о постоянном запуске git submodule update --init --recursive (команда для ручного обновления субмодулей).
</details>


<details><summary>Git Bash</summary>
Запустите RUN_THIS.py внутри репозитория, который вы загрузили с помощью Python. Предпочтительно также с терминала (python RUN_THIS.py или python3 RUN_THIS.py). Это должно занять несколько секунд, поэтому, если это мгновенно остановится, вы, вероятно, не используете Python 3.7+ или что-то в этом роде.
<p>


<img src="https://i.imgur.com/Xn4AQLf.png" alt="">
Если вы используете Windows и вас перенаправляют в Microsoft Store или при попытке запустить приведенную выше команду в вашем терминале появляется сообщение о том, что Python не установлен, вам необходимо отключить ярлык Microsoft, который может вызывать эту проблему. Вы можете сделать это, выполнив поиск "Управление псевдонимами выполнения приложений" в поиске Windows, а затем отключив две ссылки на Python.


Then <strong>c</strong>hange <strong>d</strong>irectory using:
Однако, если вы хотите изменить движок напрямую или хотите обновить субмодуль вручную (автоматическое обновление иногда может быть затруднительным), создайте файл с именем DISABLE_SUBMODULE_AUTOUPDATE внутри BuildChecker / directory.
<code>cd space-station-14</code>


(This may be different if you cloned another fork, it&#39;s almost always being the same as the repository name)
Если вам когда-нибудь понадобится вручную обновить RobustToolbox по какой-либо причине, вы можете использовать cd RobustToolbox; git checkout версии 0.4.87 (замените версию 0.4.87 последней версией RobustToolbox), затем вы можете использовать cd ..\, чтобы вернуться в свое репозиторий SS14. Это также пример использования cd для навигации по файлам, не выходя из командной строки.


Every Git command will look something like this--<code>git</code> and then a keyword like <code>add</code>, <code>commit</code>, <code>pull</code>, etc.
==Настройка локального репозитория==
Когда вы клонировали свой локальный репозиторий, мы можем приступить к следующему этапу. Учтите, теперь у вас появился свой локальный сервер.  


</p>
Локальные серверы - это просто именованные URL-адреса удаленных репозиториев, которые отслеживает Git, чтобы вы могли выполнять такие действия, как загрузка новых изменений в код или загрузка (pull) кода в ваш разветвленный репозиторий.
</details>


<hr>
В этом случае автоматически добавляемый удаленный репозиторий называется origin и указывает на <nowiki>https://github.com</nowiki> /[имя пользователя-здесь]/space-station-14 (или как там вы назвали удаленный репозиторий).


<p>After this completes, you have a local repository that you can now modify! There&#39;s still some more setup to go through, though.</p>
Одна проблема: у нас нигде нет ссылки на исходный удаленный репозиторий space-wizards / einstein-engines. Как мы собираемся обновлять наш локальный репозиторий без него? Легко, просто время от времени будут производиться апстримы, то есть общее обновление сборки, с которым мы можем работать.
<h3 id="2-3-submodule-woes">2.3 Submodule woes</h3>
== Ветвления и коммиты==
<p><strong>Pay attention to this!</strong> If you don&#39;t do this, you&#39;ll get a lot of weird errors about stuff not being available when you actually try to build the game.</p>
Ветви и коммиты - это две наиболее важные концепции в Git, и большая часть работы, которую вы выполняете, будет вращаться вокруг них.
<p>Space Station 14 has a <em>lot</em> of submodules--most notably our engine, RobustToolbox. Submodules are just repositories inside a repository, and they need to be updated manually by you. Or do they?</p>
<p>We have an automatic submodule updater so you don’t have to worry about running <code>git submodule update --init --recursive</code> (the command for manually updating submodules) all the time.</p>
<p>Run <code>RUN_THIS.py</code> inside the repo you downloaded with Python. Preferably from a terminal too (<code>python RUN_THIS.py</code> or <code>python3 RUN_THIS.py</code>). This should take a few seconds so if it instantly stops you probably aren’t using Python 3.7+ or something.</p>
<p>If you are on Windows and get redirected to the Microsoft Store or encounter a message in your terminal claiming that Python is not installed when you attempt to run the above command, you will need to disable the Microsoft shortcut that might be causing this issue. You can do this by searching for <code>Manage App Execution Aliases</code> in the Windows search and then turning off the two Python references.</p>
<p>If you do want to modify the engine directly however, or you want to update the submodule manually (the auto updating can be a pain occasionally), make a file called DISABLE_SUBMODULE_AUTOUPDATE inside the BuildChecker/ directory.</p>
<p>If you ever need to manually update RobustToolbox for whatever reason you can use <code>cd RobustToolbox; git checkout v0.4.87</code>(replace <code>v0.4.87</code> with the latest RobustToolbox release) then you can use <code>cd..\</code> to get back into your SS14 repo. This is also an example of using <code>cd</code> to navigate files from the comfort of your command line.</p>
<h2 id="3-setting-up-remotes">3. Setting up remotes</h2>
<p>When you cloned your remote repository, a <strong>remote</strong> was automatically added to your local repository. <strong>Remotes</strong> are just named URLs to remote repositories that Git keeps track of so you can do stuff like download (pull) new changes to the code or upload (push) code to your forked repository. </p>
<p>In this case, the remote automatically added is called<code>origin</code> and it points to <code>https://github.com/[username-here]/space-station-14</code> (or whatever you named the remote repository).</p>
<p>One issue: we don&#39;t have a reference to the original <code>space-wizards/space-station-14</code> remote repository anywhere! How are we supposed to update our local repository without it? So let&#39;s make sure we&#39;ve navigated inside our local repo&#39;s folder, and we&#39;ll add a new remote:</p>
<details><summary>TortoiseGit</summary>
<p>


<img src="https://i.imgur.com/yANaYWI.png" alt="">
===Что такое коммит? ===
<img src="https://i.imgur.com/cjbhMEN.png" alt="">
Как я упоминал ранее, коммиты - это просто упакованные изменения в коде, готовые к загрузке в репозиторий. Как разработчик, вы выбираете, какие изменения будут внесены в коммит и когда эти изменения будут зафиксированы. Фиксация относится к созданию коммита, и это, по сути, создает точку сохранения, к которой вы можете вернуться в любое время.


К коммит-кодам прикреплены автор, временная метка, сообщение и некоторые изменения кода. У них также есть действительно длинный "хэш коммита", уникальный идентификатор, используемый для обозначения различных коммитов.


</p>
Коммиты - это то, как создается история: на самом деле вы можете просмотреть историю каждого отдельного коммита, сделанного в репозитории SS14, с самого начала, что довольно круто:
</details>


<details><summary>SmartGit</summary>
===Что такое ветка?===
<p>
Ветви очень, очень важны. По сути, это просто список изменений в коде (коммитов). Ветвь по умолчанию - "master", и все наши серверы используют эту ветвь для компиляции кода.


<img src="https://i.imgur.com/LXCpgVo.png" alt="">
Вы практически всегда находитесь "на ветке", когда работаете со своим кодом, и вы можете легко переключиться, над какой веткой вы работаете.
<img src="https://i.imgur.com/ZHIHPJC.png" alt="">


Как правило, ветви называются в честь того, над чем вы собираетесь в них работать, но на самом деле не имеет значения, как они называются.


</p>
Вы можете создавать столько ветвей, сколько захотите. Когда вы создаете ветку, она "разветвляется" (ни хрена себе, правда?) из текущей ветки, в которой вы находитесь, и становится отдельной независимой ветвью, к которой вы можете добавлять коммиты.
</details>
====Слияние ветвей====
Ветви можно объединить в единую. Именно так функции интегрируются в основную основную ветку. Слияние просто означает "взять специальные коммиты из этой ветки и применить их к другой ветке". Вы можете объединить любые две ветви вместе.


<details><summary>Git Bash</summary>
Иногда это не удается, потому что обе ветви изменяют одну и ту же часть файла противоречивыми способами, и в этом случае вы получите конфликт слияния - подробнее об этом позже.
<p>


<img src="https://i.imgur.com/00ETpii.png" alt="">
Запросы на извлечение с GitHub на самом деле являются "запросом на слияние" - вы говорите, что хотите объединить коммиты из вашей ветки в другую ветку, обычно их основную. Подробнее об этом позже.


</p>
Запросы на извлечение очень хорошо показывают всю эту информацию.
</details>


<hr>
В этом запросе на извлечение Sweeped начал с создания новой ветки. Поскольку теперь у него была свежая ветка, свободная от помех, с которой он мог работать, он начал работать над этой функцией и создавал коммиты, чтобы "сохранять свой прогресс" всякий раз, когда он чувствовал, что это необходимо. Эти коммиты добавлялись в ветку последовательно, и вы можете видеть эволюцию ветки по мере написания большего количества кода. Подробнее о запросах на извлечение мы поговорим позже.
====Но почемууу?====
Хорошо, технически, конечно, вы можете просто выполнить всю свою работу в главной ветке и извлечь запрос оттуда. Но создание разных ветвей позволяет легко понять, где вы находитесь, сколько изменений вы внесли, и дает возможность работать над несколькими функциями одновременно.


<p>All this does is add a new remote named <code>upstream</code> that points to the original <code>space-wizards/space-station-14</code> repository. Now we can receive updates from the main repository whenever we want! (see below on how to do that). </p>
Мы также закроем ваш локальный репозиторий (далее именуемый ЛР), если он находится в вашей основной ветке (это может очень легко вызвать проблемы), поэтому не делайте этого.
<p>The convention is to call the remote pointing to the original repository <code>upstream</code> but you can technically call it whatever you like. I&#39;ll be referring to it as &#39;the upstream&#39;, though, and it&#39;s terminology Git guides use as well.</p>
<p><strong>Addendum for fork/downstream developers:</strong> If a downstream repository you wish to contribute to is set up as a direct fork (IE: GitHub shows a &quot;forked from&quot; label underneath the repo&#39;s name), then you&#39;ll additionally want to add that fork as a remote (but if the fork isn&#39;t set up that way, you can ignore this). You can do this in a way similar to how you&#39;ve added the upstream as a remote (just use the fork&#39;s GitHub link as the remote URL), but be sure to substitute the remote name of <code>upstream</code> with any name you deem appropriate. Your own fork does not have to be a fork of the downstream&#39;s fork for this; all that matters is that the commit history in the individual branches you push to your own remote line up with the commit history of wherever you&#39;re intending to PR your changes to.</p>
<p>```admonish warning title=&quot;Before working on your first PR to the space-wizards repo&quot;
Please make sure you read through the <a href="https://github.com/space-wizards/space-station-14/issues/8524">Freezes &amp; Restrictions</a> and ensure your idea does not fall into the freezes or if your PR requires some prerequisite before being made. </p>
<pre><code>
## <span class="hljs-number">4</span>. Branching &amp; Commits


Branches <span class="hljs-keyword">and</span> commits are two <span class="hljs-keyword">of</span> the most important concepts <span class="hljs-keyword">in</span> Git, <span class="hljs-keyword">and</span> most <span class="hljs-keyword">of</span> the work you do will revolve around them.
===Создание и работа с ветвями===
Создавать ветки довольно просто. Давайте создадим новую ветку под названием funny-feature:


### <span class="hljs-number">4.1</span> Whats a commit?
Теперь вы можете свободно работать с этой веткой, как вам заблагорассудится, не опасаясь испортить свою важнейшую главную ветку.


Like I mentioned before, **commits** are just packaged up changes <span class="hljs-keyword">to</span> the code. As the developer, you choose which changes go into a commit <span class="hljs-keyword">and</span> <span class="hljs-keyword">when</span> <span class="hljs-keyword">to</span> commit those changes. **Committing** refers <span class="hljs-keyword">to</span> creating a commit, <span class="hljs-keyword">and</span> it essentially makes a save point that you can go back <span class="hljs-keyword">to</span> at any <span class="hljs-built_in">time</span>.
Переключаться между ветками довольно просто: это называется проверкой ветки. Когда вы это сделаете, ваши файлы и папки локально будут изменены в соответствии с веткой, поэтому Git будет кричать на вас, если у вас есть локальные изменения, и вы попытаетесь их проверить.


Commits have an author, timestamp, a message, <span class="hljs-keyword">and</span> some code changes attached <span class="hljs-keyword">to</span> them. They also have a really long <span class="hljs-symbol">'commit</span> hash', a unique identifier used <span class="hljs-keyword">to</span> refer <span class="hljs-keyword">to</span> different commits.
Проверка ветки:


Commits are how history <span class="hljs-keyword">is</span> built up<span class="hljs-comment">--you can actually view the history of every single commit made to the SS14 repository from the beginning, which is pretty cool:</span>
Затем внесите любые локальные изменения, какие захотите! На самом деле это не имеет значения. Создайте новый файл, удалите все, измените одну строку в файле и т.д. Это не повлияет на вашу главную ветку, потому что теперь это земля с забавными функциями!


![](https://i.imgur.com/HQDdw6h.png)
===Подготовка и фиксация изменений в вашей ветке===
Еще одна важная вещь: прежде чем вы сможете зафиксировать свои изменения, вы должны добавить их в промежуточную область. Все это означает, что вы указываете, какие файлы вы хотите зафиксировать. Это полезно, потому что вы почти никогда не хотите фиксировать изменения субмодуля, поэтому вы избегаете этого, не добавляя их в промежуточную область.


(done <span class="hljs-keyword">with</span> `git log <span class="hljs-comment">--reverse`)</span>
Как упоминалось ранее, коммиты всегда сопровождаются сообщением, которое представляет собой всего лишь краткое, обязательное описание того, что делается в этом коммите. Или вы можете быть новичком и называть каждый коммит "changes stuff", решать вам.


### <span class="hljs-number">4.2</span> What<span class="hljs-symbol">'s</span> a branch?
Если вы хотите посмотреть, что вы изменили в данный момент и что находится в промежуточной области, это довольно просто. Вы вполне можете зайти и просмотреть историю изменений прежде чем загружать ваши наработки. Если же вас всё устраивает, то переходим к следующему этапу.


**Branches** are very, very important. They<span class="hljs-symbol">'re</span> basically just a list <span class="hljs-keyword">of</span> changes <span class="hljs-keyword">to</span> the code (commits). The <span class="hljs-keyword">default</span> branch <span class="hljs-keyword">is</span> <span class="hljs-symbol">'master</span>', <span class="hljs-keyword">and</span> <span class="hljs-keyword">all</span> <span class="hljs-keyword">of</span> our servers <span class="hljs-keyword">use</span> that branch <span class="hljs-keyword">to</span> compile the code.


You<span class="hljs-symbol">'re</span> pretty much always <span class="hljs-symbol">'on</span> a branch' <span class="hljs-keyword">when</span> you<span class="hljs-symbol">'re</span> working <span class="hljs-keyword">with</span> your code, <span class="hljs-keyword">and</span> you can switch which branch you<span class="hljs-symbol">'re</span> working <span class="hljs-keyword">on</span> easily.
Теперь, когда вы убедились, что все эти изменения выглядят хорошо, мы добавим их в промежуточную область и зафиксируем (некоторые графические интерфейсы Git делают это за один шаг)


Generally, branches are named <span class="hljs-keyword">for</span> whatever you<span class="hljs-symbol">'re</span> going <span class="hljs-keyword">to</span> be working <span class="hljs-keyword">on</span> <span class="hljs-keyword">in</span> them, but it doesn<span class="hljs-symbol">'t</span> *really* matter what they<span class="hljs-symbol">'re</span> named.
Вау, мы зафиксировали наши изменения в ветке! Теперь, когда они зафиксированы, они остаются в истории ветки навсегда (вроде как). Теперь мы можем многое сделать: объединить нашу забавную функцию с нашей локальной главной веткой (если мы по какой-то причине захотим), загрузить (протолкнуть) нашу забавную функцию в наш удаленный репозиторий или полностью уничтожить ветку (среди прочего). Мы выберем нажатие на ветку и отправим запрос на извлечение прямо сейчас.


You can make as many branches as you like. <span class="hljs-keyword">When</span> you create a branch, it <span class="hljs-symbol">'branches</span> <span class="hljs-keyword">out</span>' (no shit, really?) from the current branch you<span class="hljs-symbol">'re</span> <span class="hljs-keyword">on</span> <span class="hljs-keyword">and</span> becomes its own independent thing you can add commits <span class="hljs-keyword">to</span>.  
==Извлечение и загрузка вашего ПР==
Запрос на извлечение зависит от GitHub. Это просто означает, что вы хотите, чтобы кодовая база объединила ваши изменения в одной из ваших ветвей в одну из своих ветвей - обычно в их главную ветвь. Прежде чем мы сможем это сделать, наш удаленный репозиторий GitHub (origin) должен знать о прекрасных ветвях и коммит-кодах, которые мы создали локально, поэтому мы загружаем или отправляем эти изменения на удаленный сервер.


![](https://i.imgur.com/ByMugxu.png=<span class="hljs-number">500</span>x300)
===Загрузка коммитов===
Теперь, когда мы зафиксировали ваши изменения, их довольно легко загрузить. Имейте в виду, что при использовании этих команд Git, вероятно, запросит ваши учетные данные на GitHub, чтобы он мог убедиться, что вам разрешено отправлять запросы на этот удаленный сервер.


<span class="hljs-keyword">In</span> this diagram, each little node <span class="hljs-keyword">is</span> a different commit, <span class="hljs-keyword">and</span> each color <span class="hljs-keyword">is</span> a different branch.
При отправке изменений мы указываем удаленный репозиторий, в который мы отправляем коммит, и локальную ветку. Достаточно просто.


#### Branch merging
Отправляем нашу ветку в наш удаленный репозиторий (origin).


Branches are important because they can be **merged** together. This <span class="hljs-keyword">is</span> how features are integrated into the main `master` branch. A **merge** just means <span class="hljs-symbol">'take</span> the special commits from this branch, <span class="hljs-keyword">and</span> apply them <span class="hljs-keyword">to</span> another branch'. You can merge any two branches together.
Теперь самое интересное:Добавьте описание, красивое название, прежде чем подтвердить загрузку вашего обновления в репозиторий, и вот, вполне вероятно что рано или поздно ваша идея станет частью нашей сборки Lost Paradise!
==Обновление нашего репозитория ==
Возможно, прошло некоторое время, неделя или две, с момента вашего последнего запроса на извлечение, и вы хотели бы сделать еще один. Прежде чем вы что-либо предпримете, вам нужно загрузить изменения кода из основного репозитория SS14 в ваш локальный репозиторий. Если вы этого не сделаете, у вас будет устаревший код, и ваши локальные изменения могут не соответствовать тому, как на самом деле будет работать игра - вы даже можете столкнуться с конфликтами слияния при попытке.


Sometimes this doesn<span class="hljs-symbol">'t</span> go well, because both branches modify the same part <span class="hljs-keyword">in</span> a <span class="hljs-keyword">file</span> <span class="hljs-keyword">in</span> contradictory ways, <span class="hljs-keyword">in</span> which <span class="hljs-keyword">case</span> you<span class="hljs-symbol">'ll</span> get a **merge conflict**<span class="hljs-comment">--more on that in the addendums.</span>
Есть два способа обновить ваш репозиторий. Оба метода предполагают, что у вас правильно настроен вышестоящий удаленный сервер - если нет, вернитесь к предыдущему разделу руководства. И, конечно, если вы разрабатываете для нисходящего репозитория, то вам захочется заменить нисходящий репозиторий тем, что вы назвали нисходящим репозиторием на шаге 4, чтобы убедиться, что вы работаете с файлами этого нисходящего репозитория, а не с файлами восходящего репозитория. Убедитесь, что вы всегда проходите процесс обновления при переключении между внесением вклада в форк и внесением вклада в восходящий поток, в противном случае вы неизбежно закончите тем, что либо передадите всю историю нисходящего потока в восходящий поток, либо передадите ссылки на нисходящий поток, которые немедленно вступят в конфликт.


GitHub pull requests are really a <span class="hljs-symbol">'merge</span> request'<span class="hljs-comment">--you're saying that you want to merge the commits on your branch into another branch, usually their `master`. More on that later.</span>
Первый метод, fetch + merge , дает вам больше контроля, но может сбить с толку. Второй метод, pulling, прост и непринужден, но не дает вам особого контроля. Однако обычно все, что вам нужно - это pulling .


Pull requests show <span class="hljs-keyword">all</span> this info very well:
=== Fetch + merge метод===
Выборка относится к загрузке новых ветвей и коммитов из удаленного репозитория, но пока ничего с ними не делает (локально ничего изменено не будет). После того, как мы получим изменения из нашего вышестоящего удаленного хранилища (основного репозитория SS14), мы объединим их в нашу локальную главную ветвь.


![](https://i.imgur.com/YAOWX5R.png)
Когда вы извлекаете удаленный сервер, он загружает эти ветки в ваш локальный репозиторий и добавляет к ним имя удаленного сервера с косой чертой. Итак, когда вы извлекаете upstream , он создает ветку с именем upstream / master . В качестве бонуса вы можете оформить заказ на эту удаленную ветку напрямую, если хотите, и даже создать локальную ветку на ее основе, что особенно полезно, если вы работаете не только с восходящим потоком.
![](https://i.imgur.com/nWWy3J4.png)


<span class="hljs-keyword">In</span> this pull request, Swept started <span class="hljs-keyword">out</span> by creating a <span class="hljs-keyword">new</span> branch. Since he now had a fresh branch free <span class="hljs-keyword">of</span> interference <span class="hljs-keyword">to</span> work <span class="hljs-keyword">with</span>, he started working <span class="hljs-keyword">on</span> the feature <span class="hljs-keyword">and</span> created commits <span class="hljs-keyword">to</span> <span class="hljs-symbol">'save</span> his progress' whenever he felt it was necessary. These commits were added <span class="hljs-keyword">to</span> the branch sequentially, <span class="hljs-keyword">and</span> you can see the evolution <span class="hljs-keyword">of</span> the branch as more code was written. We<span class="hljs-symbol">'ll</span> talk more about pull requests later.
Сначала давайте сделаем выборку с нашего вышестоящего пульта дистанционного управления. Это займет немного времени.


#### But whyyy?
Теперь мы объединим те изменения, которые мы только что загрузили, в нашу основную ветку. Здесь вам не обязательно выполнять слияние с master; вы также можете выполнить слияние с другой веткой. Если вы просто хотели "ускорить" обновление одной из ваших веток, чтобы убедиться, что ваш PR актуален, вы можете вместо этого объединиться с этой веткой.


Okay, technically, sure, you can just do <span class="hljs-keyword">all</span> <span class="hljs-keyword">of</span> your work <span class="hljs-keyword">on</span> the `master` branch <span class="hljs-keyword">and</span> pull request from there. But, creating different branches makes it easy <span class="hljs-keyword">to</span> understand where you are, how many changes you<span class="hljs-symbol">'ve</span> made, <span class="hljs-keyword">and</span> it makes it possible <span class="hljs-keyword">to</span> work <span class="hljs-keyword">on</span> multiple features at once.
Проверьте ветку, с которой вы хотите объединить контент!


Also we<span class="hljs-symbol">'ll</span> close your PR <span class="hljs-keyword">if</span> it<span class="hljs-symbol">'s</span> from your `master` branch (it can very easily cause issues) so don<span class="hljs-symbol">'t</span> do it.
===Способ pull===
Pull, по сути своей это загрузка новых ветвей и коммитов из удаленного репозитория, а затем объединению их в ветку на вашем локальном репозитории. Это часто проще, потому что в Git есть хорошая система для автоматического определения, с какого пульта вы хотите выполнить выборку (но это не всегда работает чисто).


### <span class="hljs-number">4.3</span> Making <span class="hljs-keyword">and</span> working <span class="hljs-keyword">with</span> branches
Это гораздо проще предыдущего метода.


Making branches <span class="hljs-keyword">is</span> pretty easy. Let<span class="hljs-symbol">'s</span> make a <span class="hljs-keyword">new</span> branch called `funny-feature`:
Мы подключимся к нашему удаленному серверу (основному репозиторию SS14) и скажем ему, чтобы он объединился с нашей локальной главной веткой.


&lt;details&gt;&lt;summary&gt;TortoiseGit&lt;/summary&gt;
Сначала оформите свою главную ветку. Мы рассмотрели это ранее. Затем,
&lt;p&gt;


![](https://i.imgur.com/OGkblCk.png)
TortoiseGit
![](https://i.imgur.com/ZPfzFcm.png)


&lt;/p&gt;
SmartGit
&lt;/details&gt;


&lt;details&gt;&lt;summary&gt;SmartGit&lt;/summary&gt;
Git Bash
&lt;p&gt;


![](https://i.imgur.com/pK1oyfz.png)
Если любой из методов прошел успешно, вы успешно обновили свою основную ветку (или любую другую ветку, которую вы выбрали для обновления)! Делайте это регулярно и всегда перед началом работы над новой веткой.
![](https://i.imgur.com/<span class="hljs-number">5</span>MZ6Ocv.png)


&lt;/p&gt;
==<center>Дополнения</center>==
&lt;/details&gt;


&lt;details&gt;&lt;summary&gt;Git Bash&lt;/summary&gt;
==Что нужно иметь в виду?==
&lt;p&gt;
Вы более или менее изучили рабочий процесс разработки функций для SS14 с точки зрения Git, но вот некоторые вещи, которые мы действительно хотели бы донести до вашего сознания:


![](https://i.imgur.com/kOc9rfe.png)
При создании новой функции всегда создавайте новую ветвь от master, прежде чем что-либо менять. Если вы случайно внесете изменения в чужую ветку, вам будет не до веселья, но это поправимо, ведь всегда есть предыдущие версии.  


You may notice that the <span class="hljs-built_in">bit</span> <span class="hljs-keyword">in</span> parentheses (master) changed <span class="hljs-keyword">to</span> (funny-feature)! Incredible!
Никогда, никогда не делайте коммиты в RobustToolbox или в любые субмодули, подобные Lidgren. Лучше спросить совета у разработчиков. В локальном репозитории верхнего уровня эти субмодули считаются "файлами", поэтому их легко случайно создать и изменить.Не делайте этого. Смотрите ниже, как исправить ваши ошибки, если это произойдет. Если вам нужна дополнительная помощь с Git, не стесняйтесь спрашивать в Lost Paradise #дать имя разделу.


The `-b` <span class="hljs-keyword">in</span> `git checkout` here means <span class="hljs-symbol">'checkout</span> this branch, <span class="hljs-keyword">and</span> create it <span class="hljs-keyword">if</span> it doesn<span class="hljs-symbol">'t</span> exist.'
==Краткий пример рабочего процесса==
Чтобы собрать все в голове и обобщить все это, вот пример рабочего процесса для выполнения нескольких запросов на извлечение с использованием команд Git Bash.


&lt;/p&gt;
git checkout master # Прежде чем мы создадим новую ветку, мы должны перейти на master .
&lt;/details&gt;


&lt;hr&gt;
git fetch upstream # Мы извлекаем любые новые изменения из репозитория SS14


Now, you can work freely <span class="hljs-keyword">with</span> this branch as you please without fear <span class="hljs-keyword">of</span> messing up your <span class="hljs-keyword">all</span>-important master branch.
git merge upstream / master # и объединяем их в нашу главную ветку.


Switching between branches <span class="hljs-keyword">is</span> pretty easy: it<span class="hljs-symbol">'s</span> called **checking <span class="hljs-keyword">out</span>** a branch. <span class="hljs-keyword">When</span> you do this, your files <span class="hljs-keyword">and</span> folders locally will be changed <span class="hljs-keyword">to</span> match the branch, so Git will yell at you <span class="hljs-keyword">if</span> you have local changes <span class="hljs-keyword">and</span> you try <span class="hljs-keyword">to</span> check <span class="hljs-keyword">out</span>.
git checkout -b my-new-feature # Создайте новую ветку для функции↵...локальные изменения позже...


Checking <span class="hljs-keyword">out</span> a branch:
git add -A # Добавьте все наши локальные изменения в промежуточную область


&lt;details&gt;&lt;summary&gt;TortoiseGit&lt;/summary&gt;
git commit -m "Исправьте взрывы спагетти" # Зафиксируйте их
&lt;p&gt;


![](https://i.imgur.com/UThKrCK.png)
git push origin my-new-feature # и отправьте их на наш удаленный сервер


&lt;/p&gt;
&lt;/details&gt;


&lt;details&gt;&lt;summary&gt;SmartGit&lt;/summary&gt;
&lt;p&gt;


![](https://i.imgur.com/fzC1pVm.png)
Теперь вы захотите поработать над чем-то другим.


&lt;/p&gt;
git checkout master
&lt;/details&gt;


&lt;details&gt;&lt;summary&gt;Git Bash&lt;/summary&gt;
Прошло не слишком много времени, и ничего важного не было объединено,
&lt;p&gt;


![](https://i.imgur.com/DqWEdY5.png)
поэтому я не буду снова извлекать и объединять изменения - просто создам новую ветку.


&lt;/p&gt;
git checkout -b еще одна функция↵...локальные изменения позже...
&lt;/details&gt;


&lt;hr&gt;
git add -A


<span class="hljs-keyword">Then</span>, make whatever local changes you want! It doesn<span class="hljs-symbol">'t</span> really matter. Make a <span class="hljs-keyword">new</span> <span class="hljs-keyword">file</span>, delete everything, change one <span class="hljs-literal">line</span> <span class="hljs-keyword">in</span> a <span class="hljs-keyword">file</span>, etc. It won<span class="hljs-symbol">'t</span> affect your `master` branch, because this <span class="hljs-keyword">is</span>`funny-feature` land now!
git commit -m "Удаляет ядерные оперативники"


### <span class="hljs-number">4.4</span> Staging <span class="hljs-keyword">and</span> committing changes <span class="hljs-keyword">to</span> your branch


One more important thing: Before you can `commit` your changes, you have <span class="hljs-keyword">to</span> `add` your changes <span class="hljs-keyword">to</span> the **staging area**. <span class="hljs-keyword">All</span> this means <span class="hljs-keyword">is</span> that you<span class="hljs-symbol">'re</span> specifying which files you want <span class="hljs-keyword">to</span> commit. This <span class="hljs-keyword">is</span> helpful, because you *almost never* want <span class="hljs-keyword">to</span> commit submodule changes, so you avoid that by <span class="hljs-keyword">not</span> adding them <span class="hljs-keyword">to</span> the staging area.


As mentioned before, commits always come <span class="hljs-keyword">with</span> a message, which <span class="hljs-keyword">is</span> just a short, imperative description <span class="hljs-keyword">of</span> what<span class="hljs-symbol">'s</span> being done <span class="hljs-keyword">in</span> that commit. <span class="hljs-keyword">Or</span> you can be a chad <span class="hljs-keyword">and</span> name every commit <span class="hljs-string">"changes stuff"</span>, up <span class="hljs-keyword">to</span> you.
Я внёс изменение, но потом понял, что мой коммит был совершенно неправильным.


<span class="hljs-keyword">If</span> you want <span class="hljs-keyword">to</span> see what you<span class="hljs-symbol">'ve</span> currently changed, <span class="hljs-keyword">and</span> what<span class="hljs-symbol">'s</span> <span class="hljs-keyword">in</span> the staging area, it<span class="hljs-symbol">'s</span> pretty easy:
и я вернусь к этому позже.


&lt;details&gt;&lt;summary&gt;TortoiseGit&lt;/summary&gt;
git revert HEAD
&lt;p&gt;


![](https://i.imgur.com/xmZKKWJ.png)
git checkout master


TortoiseGit also shows changed files/folders (a red icon <span class="hljs-keyword">in</span> the bottom right) <span class="hljs-keyword">in</span> the Windows Explorer which <span class="hljs-keyword">is</span> really nice <span class="hljs-keyword">and</span> why I have it installed <span class="hljs-keyword">in</span> the first place.


&lt;/p&gt;
&lt;/details&gt;


&lt;details&gt;&lt;summary&gt;SmartGit&lt;/summary&gt;
'''... неделю спустя...'''
&lt;p&gt;


![](https://i.imgur.com/ROsurs1.png)
Было объединено много нового материала, так что давайте обновим нашу ветку.


This <span class="hljs-keyword">is</span> assuming you installed SmartGit <span class="hljs-keyword">with</span> the option that the main window shows diffs <span class="hljs-keyword">and</span> status. <span class="hljs-keyword">If</span> you didn<span class="hljs-symbol">'t</span>, I don<span class="hljs-symbol">'t</span> really know where it <span class="hljs-keyword">is</span>.
git fetch upstream


&lt;/p&gt;
git merge upstream / master master
&lt;/details&gt;


&lt;details&gt;&lt;summary&gt;Git Bash&lt;/summary&gt;
git checkout другая функция
&lt;p&gt;


![](https://i.imgur.com/UeMjAHj.png)
git merge master


&lt;/p&gt;
&lt;/details&gt;


&lt;hr&gt;


Now that you<span class="hljs-symbol">'ve</span> verified that <span class="hljs-keyword">all</span> <span class="hljs-keyword">of</span> these changes look good, we<span class="hljs-symbol">'ll</span> add them <span class="hljs-keyword">to</span> the staging area <span class="hljs-keyword">and</span> commit them (some Git GUIs do this <span class="hljs-keyword">in</span> one step)
Теперь мы внесем изменения и снова запустим, на этот раз правильно.


&lt;details&gt;&lt;summary&gt;TortoiseGit&lt;/summary&gt;
...локальные изменения позже..
&lt;p&gt;


![](https://i.imgur.com/ltIASro.png)
git add -A
![](https://i.imgur.com/BIa9r6c.png)


&lt;/p&gt;
git commit -m "Добавляет игровой режим Highlander"
&lt;/details&gt;


&lt;details&gt;&lt;summary&gt;SmartGit&lt;/summary&gt;
git push origin another-feature
&lt;p&gt;


![](https://i.imgur.com/RYUL7u3.png)
![](https://i.imgur.com/Du7HqRV.png)


&lt;/p&gt;
&lt;/details&gt;


&lt;details&gt;&lt;summary&gt;Git Bash&lt;/summary&gt;
Созданы оба ПР, оба были объединены, на этом мы закончили
&lt;p&gt;


![](https://i.imgur.com/mpKk5L1.png)
мастер оформления заказа git


&lt;/p&gt;
ветка git -d my-new-feature # Удалить обе старые ветки
&lt;/details&gt;


&lt;hr&gt;
ветка git -d another-feature


Woo, we<span class="hljs-symbol">'ve</span> committed our changes <span class="hljs-keyword">to</span> a branch! Now that they<span class="hljs-symbol">'re</span> committed, they<span class="hljs-symbol">'re</span> <span class="hljs-keyword">in</span> the history <span class="hljs-keyword">of</span> the branch forever (sort <span class="hljs-keyword">of</span>). We can do a lot <span class="hljs-keyword">of</span> things now: merge our `funny-feature` into our local `master` branch (<span class="hljs-keyword">if</span> we wanted, <span class="hljs-keyword">for</span> some reason), upload (push) our `funny-feature` branch <span class="hljs-keyword">to</span> our remote repository, <span class="hljs-keyword">or</span> nuke the branch entirely (among other things). We<span class="hljs-symbol">'ll</span> opt <span class="hljs-keyword">for</span> pushing the branch <span class="hljs-keyword">and</span> making a pull request now.
==Глоссарий: Внутренние махинации Git==
Просто для справки, вот небольшой глоссарий концепций и терминов Git, объясненный чуть более подробно, и все это в одном месте.


## <span class="hljs-number">5</span>. Pushing <span class="hljs-keyword">and</span> making a PR
'Ветви' это автономные версии кодовой базы, в которые вы можете добавлять коммиты. Ветка по умолчанию - master, но вы можете создавать столько, сколько захотите.


A **pull request** <span class="hljs-keyword">is</span> a GitHub-specific thing. It just means that you want a codebase <span class="hljs-keyword">to</span> merge your changes <span class="hljs-keyword">on</span> one <span class="hljs-keyword">of</span> your branches into one <span class="hljs-keyword">of</span> their branches<span class="hljs-comment">--usually to their `master` branch. Before we can do this, our remote GitHub repository (origin) needs to know about the beautiful branches and commits we've created locally, so we upload or **push** those changes to the remote.</span>
"Репозитории" - это, по сути, просто папки, в которые вы можете использовать Git для внесения изменений и отслеживания внесенных изменений. Локальные репозитории - это репозитории, которые есть у вас на компьютере, а удаленные репозитории - это репозитории, размещенные на веб-сайтах, таких как GitHub. Репозитории состоят из множества ветвей.


### <span class="hljs-number">5.1</span> Pushing commits
'Remotes' - это названия удаленных репозиториев и ссылки на них, которые может использовать ваш локальный репозиторий.


It<span class="hljs-symbol">'s</span> pretty easy <span class="hljs-keyword">to</span> push our changes now that we<span class="hljs-symbol">'ve</span> committed them. Be aware that, <span class="hljs-keyword">when</span> using these commands, Git <span class="hljs-keyword">is</span> probably going <span class="hljs-keyword">to</span> ask <span class="hljs-keyword">for</span> your GitHub credentials so that it can verify that you<span class="hljs-symbol">'re</span> allowed <span class="hljs-keyword">to</span> push <span class="hljs-keyword">to</span> that remote.
'Субмодули' - это репозитории, расположенные внутри другого репозитория.


<span class="hljs-keyword">When</span> pushing changes, we specify the *remote* repository that we<span class="hljs-symbol">'re</span> pushing <span class="hljs-keyword">to</span> <span class="hljs-keyword">and</span> the *local* branch that we<span class="hljs-symbol">'re</span> pushing. Simple enough.
"Форки" - это репозитории, основанные на другом репозитории. Если вы собираетесь отправить запрос на извлечение в репозиторий SS14, вам нужно сначала разветвить его.


Pushing our branch <span class="hljs-keyword">to</span> our remote repository (origin):
"Рабочее дерево" - это просто каждый файл и папка, а также то, чего нет в репозитории.↵ "Промежуточный" означает добавление (с помощью git add) изменений из вашего рабочего дерева в "промежуточную область", где с ним можно выполнять некоторые действия


&lt;details&gt;&lt;summary&gt;TortoiseGit&lt;/summary&gt;
"Коммиты" - это моментальные снимки рабочего дерева репозитория в данный момент времени. По сути, точка сохранения. "Фиксация" - это просто список файлов, которые были изменены с момента последней фиксации, а "зафиксированные" изменения - это изменения, которые вы "подготовили".
&lt;p&gt;


![](https://i.imgur.com/bWS5Kdk.png)
"Проверка" - это процесс переключения на другую ветку, чтобы вы могли поработать с ней или просмотреть ее изменения локально.
![](https://i.imgur.com/Irv1e5k.png)


Selecting <span class="hljs-symbol">'push</span> <span class="hljs-keyword">all</span> branches' does what it says <span class="hljs-keyword">on</span> the tin. Can be useful.
"Слияние" - это процесс интеграции изменений из одной ветки в другую ветку.


&lt;/p&gt;
"Конфликты слияния" возникают, когда интеграция изменений из одной ветви в другую не может быть выполнена автоматически, потому что они оба изменяют одну и ту же область в файле, или их изменения каким-либо другим образом взаимоисключают друг друга.
&lt;/details&gt;


&lt;details&gt;&lt;summary&gt;SmartGit&lt;/summary&gt;
"Выборка" означает получение веток и коммитов удаленного репозитория, но не на самом деле.. пока что с ними ничего не делается. Вы просто обновите их, если захотите оформить заказ или объединить их позже.
&lt;p&gt;


![](https://i.imgur.com/s82VnNn.png)
"Pull" - это процесс интеграции изменений из ветки удаленного репозитория в вашу локальную ветку.
![](https://i.imgur.com/VP8PuCq.png)


&lt;/p&gt;
"Pull request" - это специфичное для GitHub действие, которое позволяет вам запросить, чтобы ваша локальная ветка и все ее изменения были объединены в ветку другого репозитория.
&lt;/details&gt;


&lt;details&gt;&lt;summary&gt;Git Bash&lt;/summary&gt;
"Проталкивание" - это процесс интеграции ваших локальных изменений в удаленный репозиторий.
&lt;p&gt;


![](https://i.imgur.com/<span class="hljs-number">7</span>FJqzkL.png)
Существует гораздо больше команд и концепций, чем эта, но это все, что вам действительно нужно знать для базовой работы по разработке.


&lt;/p&gt;
===Полезные советы и подсказки===
&lt;/details&gt;
Есть некоторые вещи, которые я не описал, но в какой-то момент вам почти неизбежно придется это сделать. Я быстро опишу все это исключительно как команды git в Git Bash, но их не так уж сложно вычислить в других программах (те же ключевые слова, просто поищите их). Я рекомендую использовать их конкретные руководства, потому что я недостаточно хорошо знаю TortoiseGit / SmartGit / GitKraken / Github Desktop, чтобы помочь вам с более продвинутыми материалами.


### <span class="hljs-number">5.2</span> Making a pull request
Одно замечание, поскольку оно часто встречается здесь: HEAD - это причудливое название коммита, над которым вы сейчас работаете. Не более того. Технически ветви также являются причудливыми названиями для коммитов, но вам пока не обязательно это знать.


Now, the fun part. We<span class="hljs-symbol">'ll</span> go <span class="hljs-keyword">to</span> GitHub now <span class="hljs-keyword">and</span> make a pull request <span class="hljs-keyword">for</span> our funny feature.
Многие из них, мы надеемся вы запомнили читая строки выше.


![](https://i.imgur.com/YNmEMtG.png)
===Решение конфликтов слияния===
В работе. Когда-нибудь появится гайд получше.


Add a description, a nice title, some screenshots, <span class="hljs-keyword">and</span> hopefully it gets merged.
Противный маленький разработчик сказал вам "исправить конфликты самому", иначе ваш ПР "не будет объединен". Что за мудак! К счастью, это не слишком сложно.


## <span class="hljs-number">6</span>. Updating our repository
Во-первых, вы захотите обновить свою локальную главную ветку. Смотрите выше, как это сделать.


Maybe it<span class="hljs-symbol">'s</span> been a <span class="hljs-keyword">while</span>, a week <span class="hljs-keyword">or</span> two, since your last pull request, <span class="hljs-keyword">and</span> you<span class="hljs-symbol">'d</span> like <span class="hljs-keyword">to</span> make another. Before you do anything, you need <span class="hljs-keyword">to</span> download (**pull**) the code changes from the main SS14 repository into your local repository. <span class="hljs-keyword">If</span> you don<span class="hljs-symbol">'t</span>, you<span class="hljs-symbol">'ll</span> have <span class="hljs-keyword">out</span>-<span class="hljs-keyword">of</span>-date code <span class="hljs-keyword">and</span> your local changes may <span class="hljs-keyword">not</span> be accurate <span class="hljs-keyword">to</span> how the game will actually run<span class="hljs-comment">--you might even get **merge conflicts** when you try to PR.</span>
Когда вы запускаете git merge master [локальная ветка], он либо сделает это чисто (йюхуу!), либо скажет вам, что вы должны разрешить конфликты (уээээ).


There are two ways <span class="hljs-keyword">to</span> update your repository. Both methods <span class="hljs-keyword">assume</span> you have the `upstream` remote set up properly<span class="hljs-comment">--if not, go back to earlier in the guide. And of course, if you're developing for a downstream, then you'll want to substitute `upstream` for whatever you named the downstream repo in step 4, to make sure that you're working with that downstream's files instead of upstream's. Make sure you *always* go through the update process when switching between contributing to a fork, and contributing to upstream, otherwise you'll inevitably end up either PRing the entire history of a downstream to upstream, or making PRs to downstream that immediately conflict.</span>
Все, что вам нужно сделать для разрешения конфликтов вручную, это зайти в конфликтующие файлы, удалить всю ерунду типа >>>>HEAD и ===== <<<<master (просто указывает, откуда произошли изменения), а затем отредактировать файл так, чтобы он должным образом интегрировал оба набора изменений. Иногда это легко, иногда сложно. Если это сложно, вы, вероятно, знаете, что делаете. После этого просто git commit.


The first method, **fetch+merge**, gives you more control but can be confusing. The second method, **pulling**, <span class="hljs-keyword">is</span> simple <span class="hljs-keyword">and</span> easy but doesn<span class="hljs-symbol">'t</span> give you much control. However, pulling <span class="hljs-keyword">is</span> usually <span class="hljs-keyword">all</span> you need.
У Atlassian есть [https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts '''хороший гайд на эту тему'''].


### <span class="hljs-number">6.1</span> Fetch + merge method
===Проверка истории===
журнал git -oneline - ваш друг. Он показывает короткие хэши коммитов (уникальные идентификаторы для коммитов), их сообщения, а также их ветви и теги.


**Fetching** refers <span class="hljs-keyword">to</span> downloading the <span class="hljs-keyword">new</span> branches <span class="hljs-keyword">and</span> commits from a remote repository<span class="hljs-comment">--but not doing anything with them just yet (nothing locally will be changed). After we fetch changes from our `upstream` remote (the main SS14 repository), we'll merge them into our local `master` branch.</span>
=== Избавление от локальных изменений===
Возможно, вы случайно внесли изменения, которых не хотели, и вам не хочется утруждать себя созданием совершенно новой ветки или чего-то в этом роде, но вы еще не зафиксировали эти изменения.


<span class="hljs-keyword">When</span> you fetch a remote, it downloads those branches <span class="hljs-keyword">to</span> your local repository <span class="hljs-keyword">and</span> prepends them <span class="hljs-keyword">with</span> the remotes name <span class="hljs-keyword">and</span> a slash. So, <span class="hljs-keyword">when</span> you fetch `upstream`, it<span class="hljs-symbol">'ll</span> make a branch called `upstream/master`. As a bonus, you can checkout this remote branch directly <span class="hljs-keyword">if</span> you<span class="hljs-symbol">'d</span> like, <span class="hljs-keyword">and</span> even create a local branch based off it, which <span class="hljs-keyword">is</span> especially useful <span class="hljs-keyword">if</span> you<span class="hljs-symbol">'re</span> working <span class="hljs-keyword">with</span> more than just upstream.
git reset --hard HEAD #Это просто означает "измените рабочее дерево на текущий коммит перед любыми локальными изменениями. Или иначе." Вы не сможете восстановить эти локальные изменения, если сделаете это, так что будьте осторожны.


===Unstaging changes [перевести кому-то адекватному]===
Ah shit, I just staged RobustToolbox by accident. No fear!


First, let<span class="hljs-symbol">'s</span> fetch from our `upstream` remote. It<span class="hljs-symbol">'ll</span> take a little <span class="hljs-built_in">bit</span> <span class="hljs-keyword">to</span> complete.
git reset HEAD [file]
Alternatively, to unstage everything:


&lt;details&gt;&lt;summary&gt;TortoiseGit&lt;/summary&gt;
git reset HEAD
&lt;p&gt;


![](https://i.imgur.com/<span class="hljs-number">3</span>cWun8b.png)
=== Возврат сделанного вами коммита ===
![](https://i.imgur.com/XGgXRY0.png)
О черт, твой эротический ксеноморф попала в коммит раньше времени или ты случайно зафиксировал субмодуль! Что теперь? Что ж, есть два решения:


Make sure you <span class="hljs-keyword">select</span> `upstream` <span class="hljs-keyword">and</span> <span class="hljs-keyword">not</span> origin!
git revert HEAD #Это создает новый коммит, отменяющий текущий коммит, а затем фиксирует его.


&lt;/p&gt;
Если вы хотите отменить другой коммит, вы можете проверить его хэш в git log --oneline, а затем вызвать git revert [commit hash]. У Git есть более надежная система для этого; вы можете выполнить git revert HEAD ~ 1, чтобы отменить коммит перед вашим текущим, или git revert HEAD ~ 2, чтобы отменить коммит перед этим. Символ ~ 1 просто означает "1 фиксация перед HEAD".
&lt;/details&gt;


&lt;details&gt;&lt;summary&gt;SmartGit&lt;/summary&gt;
В качестве альтернативы,
&lt;p&gt;


![](https://i.imgur.com/CNFFJJ8.png)
git reset --hard HEAD ~ 1


I think smartgit fetches from <span class="hljs-keyword">all</span> remotes <span class="hljs-keyword">when</span> you click this?????
Я не рекомендую делать это, если вы полностью не осознаете, что делаете.


<span class="hljs-keyword">If</span> it doesn<span class="hljs-symbol">'t</span> <span class="hljs-keyword">and</span> it just fetches from origin, go <span class="hljs-keyword">to</span> the bottom left <span class="hljs-keyword">and</span> do this:
Когда вы ДЕЙСТВИТЕЛЬНО не хотите, чтобы кто-нибудь узнал о том эротическом ксеноморфе, которого вы только что создали. Этот метод переписывает историю, поэтому он не самый лучший для среды совместной работы. Если вы сделаете это, вам нужно будет принудительно нажать (git push origin [branch] --force), иначе это не сработает. Принудительное нажатие может быть опасным, поэтому, опять же, убедитесь, что вы знаете, что делаете.


![](https://i.imgur.com/<span class="hljs-number">8</span>rF0tz5.png)
===Проверка изменений PR на локальном уровне===
Ладно, это немного сложно. Есть пара способов сделать это:


&lt;/p&gt;
====Github CLI====
&lt;/details&gt;
Установите модную CLI от github и сделайте это:


&lt;details&gt;&lt;summary&gt;Git Bash&lt;/summary&gt;
gh pr checkout [номер pr]
&lt;p&gt;


![](https://i.imgur.com/aJvW9PX.png)
====Измена .git/config====
Go into your .git folder (hidden by default--may need to enable showing hidden folders in Windows), and open up the 'config' file. There should be a bit that looks something like:


Here nothing happened because I just fetched, but it<span class="hljs-symbol">'ll</span> take a <span class="hljs-keyword">while</span>.
[remote "upstream"] url = https://github.com/space-wizards/space-station-14 fetch = +refs/heads/*:refs/remotes/upstream/*


&lt;/p&gt;
Добавьте к этому строку, которая читает fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*, таким образом, эта секция теперь должна выглядеть следующим образом:
&lt;/details&gt;


&lt;hr&gt;
[remote "upstream"]
        url = https://github.com/space-wizards/space-station-14
        fetch = +refs/heads/*:refs/remotes/upstream/*
        fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*


Now, we<span class="hljs-symbol">'ll</span> merge those changes we just downloaded into our `master` branch. You don<span class="hljs-symbol">'t</span> have <span class="hljs-keyword">to</span> merge into master here; you can merge into another branch, too. <span class="hljs-keyword">If</span> you just wanted <span class="hljs-keyword">to</span> <span class="hljs-symbol">'fast</span>-forward' update one <span class="hljs-keyword">of</span> your branches <span class="hljs-keyword">to</span> make sure your PR <span class="hljs-keyword">is</span> up <span class="hljs-keyword">to</span> date, you can merge into that branch instead.
Теперь git извлекает данные вверх по течению. Этот метод хорош, если вы полноценный разработчик, а не волонтёр, но он также .. извлекает каждую ветку, которая все еще работает, из каждого открытого PR, так что это не вариант, если вам нужно только что-то конкретное.  


Check <span class="hljs-keyword">out</span> the branch you want <span class="hljs-keyword">to</span> merge <span class="hljs-keyword">to</span>. <span class="hljs-keyword">Then</span>,
Отсюда вы можете выполнить git checkout upstream / pr /[номер pr], чтобы проверить их ветку. По сути, это то, что делает GitHub CLI, но менее сложный.


&lt;details&gt;&lt;summary&gt;TortoiseGit&lt;/summary&gt;
====Добавление нового PR (персональный репозиторий)====
&lt;p&gt;
Этот метод немного сосёт, потому что он занимает некоторое время, но если вы хотите проверить чужой форк игры и их ответвления, это наиболее подходящий вариант.


![](https://i.imgur.com/<span class="hljs-number">8</span>lUaEFt.png)
На самом деле не так сложно, но это сбивает с толку, если вы не очень хорошо знаете Git.  
![](https://i.imgur.com/<span class="hljs-number">7</span>BvBPYY.png)


&lt;/p&gt;
Настройте удаленный доступ к удаленному репозиторию пользователя, извлеките их ветки, а затем извлеките их ветку:
&lt;/details&gt;


&lt;details&gt;&lt;summary&gt;SmartGit&lt;/summary&gt;
удаленное добавление git [имя пользователя] <nowiki>https://github.com</nowiki> /[имя пользователя] / space-station-14
&lt;p&gt;


![](https://i.imgur.com/n8cc2DN.png)
git fetch [имя пользователя]↵git checkout [имя пользователя] / [название филиала]
![](https://i.imgur.com/aRSawAo.png)


&lt;/p&gt;
Это также позволяет вам отправлять ссылки на их удаленный филиал, если вы того пожелаете.
&lt;/details&gt;
 
&lt;details&gt;&lt;summary&gt;Git Bash&lt;/summary&gt;
&lt;p&gt;
 
![](https://i.imgur.com/H2L8pOp.png)
 
You can also `git merge upstream/master [branch-<span class="hljs-keyword">to</span>-merge-<span class="hljs-keyword">to</span>]
 
&lt;/p&gt;
&lt;/details&gt;
 
### <span class="hljs-number">6.2</span> Pull method
 
**Pulling** refers <span class="hljs-keyword">to</span> **fetching** (downloading) the <span class="hljs-keyword">new</span> branches <span class="hljs-keyword">and</span> commits from a remote repository, <span class="hljs-keyword">and</span> <span class="hljs-keyword">then</span> merging them into a branch. Pulling <span class="hljs-keyword">is</span> often easier because Git has a nice system <span class="hljs-keyword">for</span> automatically figuring <span class="hljs-keyword">out</span> which remote you want <span class="hljs-keyword">to</span> fetch from (but it doesn<span class="hljs-symbol">'t</span> always work cleanly).
 
Pulling <span class="hljs-keyword">is</span> usually simpler <span class="hljs-keyword">and</span> a lot easier <span class="hljs-keyword">to</span> do.
 
We<span class="hljs-symbol">'ll</span> **pull** from our `upstream` remote (the main SS14 repo) <span class="hljs-keyword">and</span> tell it <span class="hljs-keyword">to</span> merge into our local `master` branch.
 
First, checkout your `master` branch. We covered this earlier. <span class="hljs-keyword">Then</span>,
 
&lt;details&gt;&lt;summary&gt;TortoiseGit&lt;/summary&gt;
&lt;p&gt;
 
![](https://i.imgur.com/XMUt6cv.png)
![](https://i.imgur.com/NHVlZ4W.png)
 
&lt;/p&gt;
&lt;/details&gt;
 
&lt;details&gt;&lt;summary&gt;SmartGit&lt;/summary&gt;
&lt;p&gt;
 
![](https://i.imgur.com/ANqpcph.png)
![](https://i.imgur.com/kvv058A.png)
![](https://i.imgur.com/k0scDB8.png)
 
&lt;/p&gt;
&lt;/details&gt;
 
&lt;details&gt;&lt;summary&gt;Git Bash&lt;/summary&gt;
&lt;p&gt;
 
![](https://i.imgur.com/OfHut9Y.png)
 
&lt;/p&gt;
&lt;/details&gt;
 
&lt;hr&gt;
 
<span class="hljs-keyword">If</span> either method went well, you<span class="hljs-symbol">'ve</span> successfully updated your master branch (<span class="hljs-keyword">or</span> whichever branch you chose <span class="hljs-keyword">to</span> update)! Do this regularly, <span class="hljs-keyword">and</span> always before you start work <span class="hljs-keyword">on</span> a <span class="hljs-keyword">new</span> branch.
 
# Addendums
 
## <span class="hljs-number">1</span>. Things <span class="hljs-keyword">to</span> keep <span class="hljs-keyword">in</span> mind
 
You<span class="hljs-symbol">'ve</span> more <span class="hljs-keyword">or</span> less learned the workflow <span class="hljs-keyword">for</span> developing features <span class="hljs-keyword">for</span> SS14 Git-wise, but here<span class="hljs-symbol">'s</span> some things I<span class="hljs-symbol">'d</span> really like <span class="hljs-keyword">to</span> hammer into your mind:
- <span class="hljs-keyword">When</span> creating a <span class="hljs-keyword">new</span> feature, *always always always* create a <span class="hljs-keyword">new</span> branch off <span class="hljs-keyword">of</span> `master` before committing anything. <span class="hljs-keyword">If</span> you accidentally commit your physics changes <span class="hljs-keyword">to</span> your bike horn branch, you<span class="hljs-symbol">'re</span> <span class="hljs-keyword">not</span> <span class="hljs-keyword">in</span> <span class="hljs-keyword">for</span> a fun <span class="hljs-built_in">time</span>, but it <span class="hljs-keyword">is</span> fixable (see Oh Shit, Git?! above)
- **Never, ever commit RobustToolbox <span class="hljs-keyword">or</span> any submodules like Lidgren.Network** unless you know what you<span class="hljs-symbol">'re</span> doing. <span class="hljs-keyword">In</span> the top-level local repository, these submodules are considered <span class="hljs-symbol">'files</span>', so it<span class="hljs-symbol">'s</span> easy <span class="hljs-keyword">to</span> accidentally stage <span class="hljs-keyword">and</span> commit them. Do <span class="hljs-keyword">not</span> do this. See below <span class="hljs-keyword">for</span> how <span class="hljs-keyword">to</span> fix your fuckups <span class="hljs-keyword">if</span> it happens.
- <span class="hljs-keyword">If</span> you need further help <span class="hljs-keyword">with</span> Git, feel free <span class="hljs-keyword">to</span> ask <span class="hljs-keyword">in</span> the SS14 Discord <span class="hljs-keyword">in</span> #howdoicode.
 
## <span class="hljs-number">2</span>. A quick example workflow
 
<span class="hljs-keyword">To</span> get everything <span class="hljs-keyword">in</span> your head <span class="hljs-keyword">and</span> <span class="hljs-keyword">to</span> summarize it <span class="hljs-keyword">all</span>, here<span class="hljs-symbol">'s</span> an example workflow <span class="hljs-keyword">for</span> making several pull requests using Git Bash commands.
 
```python
git checkout master # Before we create a <span class="hljs-keyword">new</span> branch, we should be <span class="hljs-keyword">on</span> master.
git fetch upstream # We<span class="hljs-symbol">'ll</span> fetch any <span class="hljs-keyword">new</span> changes from the SS14 repo..
git merge upstream/master # ..<span class="hljs-keyword">and</span> merge them into our master branch.
 
git checkout -b my-<span class="hljs-keyword">new</span>-feature # Make a <span class="hljs-keyword">new</span> branch <span class="hljs-keyword">for</span> the feature
...local changes later...
git add -A # Add <span class="hljs-keyword">all</span> <span class="hljs-keyword">of</span> our local changes <span class="hljs-keyword">to</span> the staging area
git commit -m <span class="hljs-string">"Fix spaghetti explosions"</span> # Commit them
git push origin my-<span class="hljs-keyword">new</span>-feature # <span class="hljs-keyword">and</span> push them <span class="hljs-keyword">to</span> our remote
 
# Now, I want <span class="hljs-keyword">to</span> work <span class="hljs-keyword">on</span> a different pull request.
 
git checkout master
 
# It hasn<span class="hljs-symbol">'t</span> been too long, <span class="hljs-keyword">and</span> nothing important was merged,
# so I won<span class="hljs-symbol">'t</span> fetch <span class="hljs-keyword">and</span> merge changes again<span class="hljs-comment">--just a new branch.</span>
 
git checkout -b another-feature
...local changes later...
git add -A
git commit -m <span class="hljs-string">"Deletes nuclear operatives"</span>
 
# I committed, but <span class="hljs-keyword">then</span> I realized my commit was entirely wrong
# <span class="hljs-keyword">and</span> i<span class="hljs-symbol">'ll</span> take it up later.
 
git revert HEAD
git checkout master
 
...a week later...
 
# A lot <span class="hljs-keyword">of</span> <span class="hljs-keyword">new</span> stuff was merged, so let<span class="hljs-symbol">'s</span> update our branch.
 
git fetch upstream
git merge upstream/master master
git checkout another-feature
git merge master
 
# Now we<span class="hljs-symbol">'ll</span> make changes <span class="hljs-keyword">and</span> push again, this <span class="hljs-built_in">time</span> correctly.
 
...local changes later...
git add -A
git commit -m <span class="hljs-string">"Adds Highlander gamemode"</span>
git push origin another-feature
 
# Made both PRs, both were merged, so we<span class="hljs-symbol">'re</span> done here
 
git checkout master
git branch -d my-<span class="hljs-keyword">new</span>-feature # Delete both old branches
git branch -d another-feature
</code></pre><h1 id="glossary-the-inner-machinations-of-git">Glossary: The Inner Machinations of Git</h1>
<p>Just for reference, here&#39;s a little glossary of Git concepts and terms explained in a little more detail, all in one place.</p>
<ul>
<li><strong>&#39;Branches&#39;</strong> are self-contained versions of the codebase that you can add commits to. The default branch is <strong>master</strong>, but you can make as many as you like.</li>
<li><strong>&#39;Repositories&#39;</strong> are essentially just folders where you can use Git to make changes and keep track of changes made. Local repositories are repositories you have on your computer, and remote repositories are repositories that live on websites like <a href="https://github.com/space-wizards/space-station-14">GitHub</a>. Repositories are made up of a lot of branches.</li>
<li><strong>&#39;Remotes&#39;</strong> are names for and links to remote repositories that your local repository can use.</li>
<li><strong>&#39;Submodules&#39;</strong> are repositories that are located inside another repository.</li>
<li><strong>&#39;Forks&#39;</strong> are repositories that are based on another repository. If you&#39;re going to make a pull request to the SS14 repo, you need to fork it first.</li>
<li><strong>&#39;The working tree&#39;</strong> is just every file and folder and what not that&#39;s in the repository.</li>
<li><strong>&#39;Staging&#39;</strong> means adding (with <code>git add</code>) changes from your working tree into the &#39;staging area&#39;, where  some actions can be performed on it</li>
<li><strong>&#39;Commits&#39;</strong> are snapshots of the repository&#39;s working tree at a given time. Basically a save point. A &#39;commit&#39; is just a list of files that have been changed from the last commit, and the changes that are &#39;committed&#39; are the changes that you&#39;ve &#39;staged&#39;.</li>
<li><strong>&#39;Checking out&#39;</strong> is the act of switching to another branch so you can mess with it or look at its changes locally.</li>
<li><strong>&#39;Merging&#39;</strong> is the act of integrating the changes from one branch into another branch.</li>
<li><strong>&#39;Merge conflicts&#39;</strong> occur when integrating the changes from one branch into another can&#39;t be done automatically because they both change the same area in a file, or their changes are mutually exclusive in some other way.</li>
<li><strong>&#39;Fetching&#39;</strong> means getting the branches and commits of a remote repository, but not actually.. doing anything with them yet. You&#39;ll just have them updated for if you want to checkout or merge them later.</li>
<li><strong>&#39;Pulling&#39;</strong> is the act of integrating changes from a remote repository&#39;s branch into your local branch.</li>
<li><strong>&#39;Pull requests&#39;</strong> are a GitHub-specific action that allow you to request that your local branch and all of its changes is merged into another repository&#39;s branch.</li>
<li><strong>&#39;Pushing&#39;</strong> is the act of integrating your local changes into a remote repository.</li>
</ul>
<p>There are way more commands and concepts than this, but this is all you <em>really</em> need to know for basic development work.</p>
<h1 id="appendix-a-helpful-tips-and-tricks">Appendix A: Helpful tips and tricks</h1>
<p>There&#39;s some stuff I didn&#39;t cover, but you&#39;ll almost inevitably have to do at some point. I&#39;ll cover these all <strong>exclusively as git commands in Git Bash</strong> quickly, but they&#39;re not too hard to figure out in the other programs (same keywords, just look for those). I recommend using their specific guides because I don&#39;t know TortoiseGit / SmartGit / GitKraken / Github Desktop well enough to help you with more advanced stuff.</p>
<p>One note since it comes up a lot here: <strong><code>HEAD</code> is a fancy name for the commit that you&#39;re currently on</strong>. Nothing more than that. Branches are also technically fancy names for commits, but you don&#39;t need to know that yet.</p>
<p>A lot of these can be found probably more eloquently in Oh Shit, Git?! (see resources above)</p>
<h2 id="resolving-merge-conflicts">Resolving merge conflicts</h2>
<p><em>WIP i&#39;ll write a better guide for this later because it&#39;s important</em></p>
<p>A nasty little maintainer has told you to &#39;resolve conflicts&#39; or your PR &#39;wont be merged&#39;. What an asshole! Thankfully, it&#39;s not too hard.</p>
<p>First, you&#39;re going to want to update your local <code>master branch</code>. See above for how to do that.</p>
<p>When you run <code>git merge master [local branch]</code>, it&#39;ll either do it cleanly (woohoo) or tell you you have to resolve conflicts (wahhhh). </p>
<p>All you need to do to resolve conflicts manually is go into the files that are conflicting, remove all the <code>&gt;&gt;&gt;&gt;HEAD</code> and <code>===== &lt;&lt;&lt;&lt;master</code> nonsense (just notates where the changes originated) and then edit the file so that it properly integrates both sets of changes. Sometimes this is easy, sometimes it&#39;s hard. If it&#39;s hard, you probably know what you&#39;re doing. After that, just <code>git commit</code>.</p>
<p>Atlassian has a really good guide for this <a href="https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts">here</a></p>
<h2 id="checking-history">Checking history</h2>
<p><code>git log --oneline</code> is your friend. It shows short commit hashes (unique IDs for commits), their messages, and their branches and tags.</p>
<h2 id="getting-rid-of-local-changes">Getting rid of local changes</h2>
<p>You might have accidentally made changes you didn&#39;t want to, and you don&#39;t want to bother with making an entirely new branch or something--but you haven&#39;t committed those changes yet.</p>
<pre><code>git <span class="hljs-keyword">reset</span> <span class="hljs-comment">--hard HEAD</span>
</code></pre><p>This just means &#39;change the working tree to the current commit, before any local changes. Or else.&#39; <strong>You can&#39;t retrieve those local changes if you do this, so be wary.</strong></p>
<h2 id="unstaging-changes">Unstaging changes</h2>
<p>Ah shit, I just staged RobustToolbox by accident. No fear!</p>
<pre><code>git <span class="hljs-keyword">reset</span> <span class="hljs-keyword">HEAD</span> [<span class="hljs-keyword">file</span>]
</code></pre><p>Alternatively, to unstage everything:</p>
<pre><code>git <span class="hljs-keyword">reset</span> <span class="hljs-keyword">HEAD</span>
</code></pre><h2 id="reverting-a-commit-you-made">Reverting a commit you made</h2>
<p>Oh shit, your xenomorph erotica made its way into a commit/you accidentally committed a submodule! What now? Well, there&#39;s two solutions:</p>
<pre><code><span class="hljs-symbol">git</span> <span class="hljs-keyword">revert </span>HEAD
</code></pre><p>This makes a new commit undoing the current commit, and then commits it. Hehe commit. </p>
<p>If you want to undo a different commit, you can check its hash in <code>git log --oneline</code> and then call <code>git revert [commit hash]</code>. Git has a more robust system for doing this; you can do <code>git revert HEAD~1</code> to undo the commit before your current one or <code>git revert HEAD~2</code> to revert the one before that. The <code>~1</code> just means &#39;1 commit before HEAD&#39;.</p>
<p>Alternatively,</p>
<pre><code>git <span class="hljs-keyword">reset</span> <span class="hljs-comment">--hard HEAD~1</span>
</code></pre><p><strong>I don&#39;t recommend doing this unless you&#39;re fully aware of what you&#39;re doing.</strong></p>
<p>For when you REALLY don&#39;t want anyone to know about that xenomorph erotica you just made. This method rewrites history, so it isn&#39;t the best for a collaborative environment. If you do this, you&#39;ll need to force push (<code>git push origin [branch] --force</code>) or else it won&#39;t work. Force pushing can be dangerous, so again, be sure you know what you&#39;re doing.</p>
<h2 id="checking-out-a-pr-s-changes-locally">Checking out a PR&#39;s changes locally</h2>
<p>Ok, this one is a little difficult. There&#39;s a couple ways to do this:</p>
<h3 id="github-cli">Github CLI</h3>
<p>Install github&#39;s fancy CLI and do this:</p>
<pre><code>gh <span class="hljs-keyword">pr</span> checkout [<span class="hljs-keyword">pr</span> number]
</code></pre><p>Neat.</p>
<h3 id="changing-git-config">Changing .git/config</h3>
<p>Go into your .git folder (hidden by default--may need to enable showing hidden folders in Windows), and open up the &#39;config&#39; file. There should be a bit that looks something like:</p>
<pre><code>[remote <span class="hljs-string">"upstream"</span>]
    url = <span class="hljs-symbol">https:</span>/<span class="hljs-regexp">/github.com/space</span>-wizards/space-station-<span class="hljs-number">14</span>
    fetch = +refs/heads/*<span class="hljs-symbol">:refs/remotes/upstream/*</span>
</code></pre><p>Add a line to this that reads <code>fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*</code>, so that section should now look like:</p>
<pre><code>[remote <span class="hljs-string">"upstream"</span>]
        url = <span class="hljs-symbol">https:</span>/<span class="hljs-regexp">/github.com/space</span>-wizards/space-station-<span class="hljs-number">14</span>
        fetch = +refs/heads/*<span class="hljs-symbol">:refs/remotes/upstream/*</span>
        fetch = +refs/pull/*<span class="hljs-regexp">/head:refs/remotes</span><span class="hljs-regexp">/upstream/pr</span><span class="hljs-regexp">/*</span>
</code></pre><p>Now, <code>git fetch upstream</code>. This method is great if you&#39;re a maintainer, but it also.. fetches every branch that&#39;s still up from every PR that&#39;s been opened, so not fantastic if you just wanted one thing. From here, you can <code>git checkout upstream/pr/[pr number]</code> to check out their branch. This is basically what GitHub CLI does but less sophisticated.</p>
<h3 id="adding-a-new-remote">Adding a new remote</h3>
<p>This method kinda sucks because it takes a while but if you want to check out someone else&#39;s fork of the game and their branches it&#39;s pretty nice.</p>
<p>Not actually that hard but its confusing if you don&#39;t know Git very well. Set up a remote to the user&#39;s remote repository, fetch their branches, and then checkout their branch:</p>
<pre><code>git remote add [username] <span class="hljs-link">https://github.com/</span>[<span class="hljs-string">username</span>]/space-station-14
git fetch [username]
git checkout [username]/[branch name]
</code></pre><p>This also lets you make PRs to their remote branch, if you so desired.</p>

Текущая версия от 16:47, 30 сентября 2024

Git для разработчика Космической Станции 14

Если вы когда-либо следовали халтурно написанному руководству по Git или открывали один из многих невероятно раздутых современных графических интерфейсов git, таких как GitKraken, вы, вероятно, понимаете, что Git может быть действительно запутанным. Цель этого руководства - предоставить вам только информацию, необходимую для правильной разработки для SS14, и предоставить ресурсы для изучения большего, если необходимо.

Вот еще несколько ресурсов для изучения Git:

Онлайн-книга Git-SCM

Руководство Atlassian по Git. Довольно простое и понятное.

О черт, Git?! список решений распространенных проблем с git. Этот вам тоже понадобится.

Изучите так-же ветвление Git. На данном сайте вы сможете познакомиться со всеми необходимыми функциями гита путём практики.

Настройка вашего Git

Ради всего святого, не используйте GitHub Desktop. Мы знаем, что GitHub Desktop красив и прост, но, пожалуйста, не используйте его, если вы не знаете, что делаете. Если вы следовали нашему руководству "Настройка среды разработки", у вас, вероятно, уже установлен Git. Если нет, перейдите на их сайт и установите его сейчас. Это позволит установить серверную часть Git, а также Git Bash (если вы выберете эту опцию) - один из многих способов, которыми вы действительно можете использовать Git.

Если вы используете Linux, вы, вероятно, просто будете использовать Git через свой терминал или любую другую IDE, которую вы выбрали, и, скорее всего, она у вас уже установлена.

Я настоятельно рекомендую хотя бы раз попробовать Git Bash (как и многие наши разработчики), но есть более удобные альтернативы, которые многие используют, и здесь я также покажу шаги для них:

TortoiseGit - старый, но до сих пор актуальный графический интерфейс Git, который отображает информацию в меню проводника файлов и упрощает базовые вещи. SmartGit - полнофункциональный графический интерфейс Git, в котором можно настроить многое под себя, а так-же простой в использовании.

Есть другие, возможно более привычные вам альтернативы:

Fork - понятный, эргономичный интерфейс, отличный вариант. "Платный", но на деле платный на уровне WinRAR, так что по сути он бесплатный. Имеет поддержку частичной промежуточной обработки.

Sublime Merge - очень похож на Fork. Также имеет поддержку частичной промежуточной обработки.

Большинство IDE также имеют ту или иную форму интеграции с Git. Интеграция с Git в JetBrains Rider.

Не рекомендуется использовать Git-интерфейс в Visual Studio, поскольку в большинстве своём он ужасен. Лучший и рекомендуемый вариант это JetBrains Rider.

И пока вы здесь, установите также Python 3.7+, если у вас его еще нет. Вы можете сделать это здесь для Windows и Mac, а если вы используете Linux, у вас почти наверняка уже установлен Python.

При настройке вашего логина и почты помните, что они публично отображаются во всех создаваемых вами коммит-файлах. Если вы хотите скрыть от остальных свою другую деятельность, вы можете это сделать через настройки приватности.
Теперь, когда у вас установлен Git, я рекомендую вам сначала немного ознакомиться с его основами и ознакомиться с любым клиентом git, с которым вы работаете, будь то просто командная строка (Git Bash) или что-либо еще.

Мы собираемся запустить процесс настройки среды Git для Space Station 14, чтобы вы могли вносить код с помощью запросов на извлечение, создавать свою собственную кодовую базу или просто просматривать историю проекта.

Зачем мы вообще используем Git?

Git - это самая удобная платформа где можно контролировать каждую версию - по сути, это простой способ отслеживать изменения в коде и управлять этими изменениями без головной боли. Это бесценный инструмент для разработки программного обеспечения, потому что он позволяет легко вносить новые изменения, просматривать различные изменения, видеть, кто внес изменения, и т.д. без необходимости координировать и сводить все в таблицу самостоятельно.

GitHub - это онлайн-сервис, в котором размещены репозитории Git для удобства совместной работы. Он идеально подходит для такой базы кода, как SS14, с большим количеством участников и богатой историей. Это также означает, что у нас открытый исходный код - любой может зайти на наш GitHub и скачать код!

Настройка вашего репозитория

Как я уже говорилось ранее, репозиторий - это просто база кода. Репозитории содержат некоторые ветви, и эти ветви содержат разные коммиты. Возможно, вы слышали об обоих из них и знаете как работать, если прошли курс выше.

Удаленный (главный) репозиторий - это просто репозиторий, который находится на GitHub. Локальный репозиторий - это тот, который фактически находится на вашем компьютере и с которым работаете вы!

Создание локального репозитория

Сначала давайте создадим нашу собственную ветку удаленного репозитория Space Station 14. Для этого, конечно, вам понадобится учетная запись на GitHub. Такое "разветвление" просто означает, что вы копируете всю историю репозитория и изменения в свой собственный репозиторий, чтобы вы могли свободно вносить изменения в код и проверять их.

Ваш локальный репозиторий не обновляется автоматически изменениями из исходного репозитория SS14 - вам придется сделать это самостоятельно, о чём мы поговорим позже.

Перейдите в репозиторий Lost-Paradise и создайте ветвь здесь:

После этого он спросит вас, где разместить его и как назвать - не переживайте, никто не узнает как вы его назвали. Назовите его так, как вам заблагорассудится!

Теперь нам нужно загрузить наш удаленный репозиторий на ваш компьютер (клонировать), чтобы мы могли добавить 20 пар клоунской обуви в каждый шкафчик. Технически вы можете изменить свой удаленный репозиторий (на GitHub есть несколько полезных инструментов), но наличие его на вашем компьютере означает, что вы используете IDE, такие как Visual Studio или Rider, для сборки игры и запуска тестов, а также для простой обработки материалов Git.

Теперь, на вашем компьютере, куда вы хотите поместить локальный репозиторий, и затем мы введем команду для клонирования нашего удаленного репозитория - не репозитория Einstein engine / RobustToolbox.

После всех этих махинаций, у вас будет локальный репозиторий, который теперь вы можете изменять! Однако предстоит выполнить еще некоторые настройки.

Проблемы с субмодулями

Обратите на это внимание! Если вы этого не сделаете, вы получите множество странных ошибок о том, что материал недоступен, когда вы будете пытаться запустить билд.

У Space Station 14 есть много субмодулей, в первую очередь наш движок, RobustToolbox. Субмодули - это просто репозитории внутри репозитория. Не переживайте, их обновление можно автоматизировать.

У нас есть программа автоматического обновления субмодулей, поэтому вам не нужно беспокоиться о постоянном запуске git submodule update --init --recursive (команда для ручного обновления субмодулей).

Запустите RUN_THIS.py внутри репозитория, который вы загрузили с помощью Python. Предпочтительно также с терминала (python RUN_THIS.py или python3 RUN_THIS.py). Это должно занять несколько секунд, поэтому, если это мгновенно остановится, вы, вероятно, не используете Python 3.7+ или что-то в этом роде.

Если вы используете Windows и вас перенаправляют в Microsoft Store или при попытке запустить приведенную выше команду в вашем терминале появляется сообщение о том, что Python не установлен, вам необходимо отключить ярлык Microsoft, который может вызывать эту проблему. Вы можете сделать это, выполнив поиск "Управление псевдонимами выполнения приложений" в поиске Windows, а затем отключив две ссылки на Python.

Однако, если вы хотите изменить движок напрямую или хотите обновить субмодуль вручную (автоматическое обновление иногда может быть затруднительным), создайте файл с именем DISABLE_SUBMODULE_AUTOUPDATE внутри BuildChecker / directory.

Если вам когда-нибудь понадобится вручную обновить RobustToolbox по какой-либо причине, вы можете использовать cd RobustToolbox; git checkout версии 0.4.87 (замените версию 0.4.87 последней версией RobustToolbox), затем вы можете использовать cd ..\, чтобы вернуться в свое репозиторий SS14. Это также пример использования cd для навигации по файлам, не выходя из командной строки.

Настройка локального репозитория

Когда вы клонировали свой локальный репозиторий, мы можем приступить к следующему этапу. Учтите, теперь у вас появился свой локальный сервер.

Локальные серверы - это просто именованные URL-адреса удаленных репозиториев, которые отслеживает Git, чтобы вы могли выполнять такие действия, как загрузка новых изменений в код или загрузка (pull) кода в ваш разветвленный репозиторий.

В этом случае автоматически добавляемый удаленный репозиторий называется origin и указывает на https://github.com /[имя пользователя-здесь]/space-station-14 (или как там вы назвали удаленный репозиторий).

Одна проблема: у нас нигде нет ссылки на исходный удаленный репозиторий space-wizards / einstein-engines. Как мы собираемся обновлять наш локальный репозиторий без него? Легко, просто время от времени будут производиться апстримы, то есть общее обновление сборки, с которым мы можем работать.

Ветвления и коммиты

Ветви и коммиты - это две наиболее важные концепции в Git, и большая часть работы, которую вы выполняете, будет вращаться вокруг них.

Что такое коммит?

Как я упоминал ранее, коммиты - это просто упакованные изменения в коде, готовые к загрузке в репозиторий. Как разработчик, вы выбираете, какие изменения будут внесены в коммит и когда эти изменения будут зафиксированы. Фиксация относится к созданию коммита, и это, по сути, создает точку сохранения, к которой вы можете вернуться в любое время.

К коммит-кодам прикреплены автор, временная метка, сообщение и некоторые изменения кода. У них также есть действительно длинный "хэш коммита", уникальный идентификатор, используемый для обозначения различных коммитов.

Коммиты - это то, как создается история: на самом деле вы можете просмотреть историю каждого отдельного коммита, сделанного в репозитории SS14, с самого начала, что довольно круто:

Что такое ветка?

Ветви очень, очень важны. По сути, это просто список изменений в коде (коммитов). Ветвь по умолчанию - "master", и все наши серверы используют эту ветвь для компиляции кода.

Вы практически всегда находитесь "на ветке", когда работаете со своим кодом, и вы можете легко переключиться, над какой веткой вы работаете.

Как правило, ветви называются в честь того, над чем вы собираетесь в них работать, но на самом деле не имеет значения, как они называются.

Вы можете создавать столько ветвей, сколько захотите. Когда вы создаете ветку, она "разветвляется" (ни хрена себе, правда?) из текущей ветки, в которой вы находитесь, и становится отдельной независимой ветвью, к которой вы можете добавлять коммиты.

Слияние ветвей

Ветви можно объединить в единую. Именно так функции интегрируются в основную основную ветку. Слияние просто означает "взять специальные коммиты из этой ветки и применить их к другой ветке". Вы можете объединить любые две ветви вместе.

Иногда это не удается, потому что обе ветви изменяют одну и ту же часть файла противоречивыми способами, и в этом случае вы получите конфликт слияния - подробнее об этом позже.

Запросы на извлечение с GitHub на самом деле являются "запросом на слияние" - вы говорите, что хотите объединить коммиты из вашей ветки в другую ветку, обычно их основную. Подробнее об этом позже.

Запросы на извлечение очень хорошо показывают всю эту информацию.

В этом запросе на извлечение Sweeped начал с создания новой ветки. Поскольку теперь у него была свежая ветка, свободная от помех, с которой он мог работать, он начал работать над этой функцией и создавал коммиты, чтобы "сохранять свой прогресс" всякий раз, когда он чувствовал, что это необходимо. Эти коммиты добавлялись в ветку последовательно, и вы можете видеть эволюцию ветки по мере написания большего количества кода. Подробнее о запросах на извлечение мы поговорим позже.

Но почемууу?

Хорошо, технически, конечно, вы можете просто выполнить всю свою работу в главной ветке и извлечь запрос оттуда. Но создание разных ветвей позволяет легко понять, где вы находитесь, сколько изменений вы внесли, и дает возможность работать над несколькими функциями одновременно.

Мы также закроем ваш локальный репозиторий (далее именуемый ЛР), если он находится в вашей основной ветке (это может очень легко вызвать проблемы), поэтому не делайте этого.

Создание и работа с ветвями

Создавать ветки довольно просто. Давайте создадим новую ветку под названием funny-feature:

Теперь вы можете свободно работать с этой веткой, как вам заблагорассудится, не опасаясь испортить свою важнейшую главную ветку.

Переключаться между ветками довольно просто: это называется проверкой ветки. Когда вы это сделаете, ваши файлы и папки локально будут изменены в соответствии с веткой, поэтому Git будет кричать на вас, если у вас есть локальные изменения, и вы попытаетесь их проверить.

Проверка ветки:

Затем внесите любые локальные изменения, какие захотите! На самом деле это не имеет значения. Создайте новый файл, удалите все, измените одну строку в файле и т.д. Это не повлияет на вашу главную ветку, потому что теперь это земля с забавными функциями!

Подготовка и фиксация изменений в вашей ветке

Еще одна важная вещь: прежде чем вы сможете зафиксировать свои изменения, вы должны добавить их в промежуточную область. Все это означает, что вы указываете, какие файлы вы хотите зафиксировать. Это полезно, потому что вы почти никогда не хотите фиксировать изменения субмодуля, поэтому вы избегаете этого, не добавляя их в промежуточную область.

Как упоминалось ранее, коммиты всегда сопровождаются сообщением, которое представляет собой всего лишь краткое, обязательное описание того, что делается в этом коммите. Или вы можете быть новичком и называть каждый коммит "changes stuff", решать вам.

Если вы хотите посмотреть, что вы изменили в данный момент и что находится в промежуточной области, это довольно просто. Вы вполне можете зайти и просмотреть историю изменений прежде чем загружать ваши наработки. Если же вас всё устраивает, то переходим к следующему этапу.


Теперь, когда вы убедились, что все эти изменения выглядят хорошо, мы добавим их в промежуточную область и зафиксируем (некоторые графические интерфейсы Git делают это за один шаг)

Вау, мы зафиксировали наши изменения в ветке! Теперь, когда они зафиксированы, они остаются в истории ветки навсегда (вроде как). Теперь мы можем многое сделать: объединить нашу забавную функцию с нашей локальной главной веткой (если мы по какой-то причине захотим), загрузить (протолкнуть) нашу забавную функцию в наш удаленный репозиторий или полностью уничтожить ветку (среди прочего). Мы выберем нажатие на ветку и отправим запрос на извлечение прямо сейчас.

Извлечение и загрузка вашего ПР

Запрос на извлечение зависит от GitHub. Это просто означает, что вы хотите, чтобы кодовая база объединила ваши изменения в одной из ваших ветвей в одну из своих ветвей - обычно в их главную ветвь. Прежде чем мы сможем это сделать, наш удаленный репозиторий GitHub (origin) должен знать о прекрасных ветвях и коммит-кодах, которые мы создали локально, поэтому мы загружаем или отправляем эти изменения на удаленный сервер.

Загрузка коммитов

Теперь, когда мы зафиксировали ваши изменения, их довольно легко загрузить. Имейте в виду, что при использовании этих команд Git, вероятно, запросит ваши учетные данные на GitHub, чтобы он мог убедиться, что вам разрешено отправлять запросы на этот удаленный сервер.

При отправке изменений мы указываем удаленный репозиторий, в который мы отправляем коммит, и локальную ветку. Достаточно просто.

Отправляем нашу ветку в наш удаленный репозиторий (origin).

Теперь самое интересное:Добавьте описание, красивое название, прежде чем подтвердить загрузку вашего обновления в репозиторий, и вот, вполне вероятно что рано или поздно ваша идея станет частью нашей сборки Lost Paradise!

Обновление нашего репозитория

Возможно, прошло некоторое время, неделя или две, с момента вашего последнего запроса на извлечение, и вы хотели бы сделать еще один. Прежде чем вы что-либо предпримете, вам нужно загрузить изменения кода из основного репозитория SS14 в ваш локальный репозиторий. Если вы этого не сделаете, у вас будет устаревший код, и ваши локальные изменения могут не соответствовать тому, как на самом деле будет работать игра - вы даже можете столкнуться с конфликтами слияния при попытке.

Есть два способа обновить ваш репозиторий. Оба метода предполагают, что у вас правильно настроен вышестоящий удаленный сервер - если нет, вернитесь к предыдущему разделу руководства. И, конечно, если вы разрабатываете для нисходящего репозитория, то вам захочется заменить нисходящий репозиторий тем, что вы назвали нисходящим репозиторием на шаге 4, чтобы убедиться, что вы работаете с файлами этого нисходящего репозитория, а не с файлами восходящего репозитория. Убедитесь, что вы всегда проходите процесс обновления при переключении между внесением вклада в форк и внесением вклада в восходящий поток, в противном случае вы неизбежно закончите тем, что либо передадите всю историю нисходящего потока в восходящий поток, либо передадите ссылки на нисходящий поток, которые немедленно вступят в конфликт.

Первый метод, fetch + merge , дает вам больше контроля, но может сбить с толку. Второй метод, pulling, прост и непринужден, но не дает вам особого контроля. Однако обычно все, что вам нужно - это pulling .

Fetch + merge метод

Выборка относится к загрузке новых ветвей и коммитов из удаленного репозитория, но пока ничего с ними не делает (локально ничего изменено не будет). После того, как мы получим изменения из нашего вышестоящего удаленного хранилища (основного репозитория SS14), мы объединим их в нашу локальную главную ветвь.

Когда вы извлекаете удаленный сервер, он загружает эти ветки в ваш локальный репозиторий и добавляет к ним имя удаленного сервера с косой чертой. Итак, когда вы извлекаете upstream , он создает ветку с именем upstream / master . В качестве бонуса вы можете оформить заказ на эту удаленную ветку напрямую, если хотите, и даже создать локальную ветку на ее основе, что особенно полезно, если вы работаете не только с восходящим потоком.

Сначала давайте сделаем выборку с нашего вышестоящего пульта дистанционного управления. Это займет немного времени.

Теперь мы объединим те изменения, которые мы только что загрузили, в нашу основную ветку. Здесь вам не обязательно выполнять слияние с master; вы также можете выполнить слияние с другой веткой. Если вы просто хотели "ускорить" обновление одной из ваших веток, чтобы убедиться, что ваш PR актуален, вы можете вместо этого объединиться с этой веткой.

Проверьте ветку, с которой вы хотите объединить контент!

Способ pull

Pull, по сути своей это загрузка новых ветвей и коммитов из удаленного репозитория, а затем объединению их в ветку на вашем локальном репозитории. Это часто проще, потому что в Git есть хорошая система для автоматического определения, с какого пульта вы хотите выполнить выборку (но это не всегда работает чисто).

Это гораздо проще предыдущего метода.

Мы подключимся к нашему удаленному серверу (основному репозиторию SS14) и скажем ему, чтобы он объединился с нашей локальной главной веткой.

Сначала оформите свою главную ветку. Мы рассмотрели это ранее. Затем,

TortoiseGit

SmartGit

Git Bash

Если любой из методов прошел успешно, вы успешно обновили свою основную ветку (или любую другую ветку, которую вы выбрали для обновления)! Делайте это регулярно и всегда перед началом работы над новой веткой.

Дополнения

Что нужно иметь в виду?

Вы более или менее изучили рабочий процесс разработки функций для SS14 с точки зрения Git, но вот некоторые вещи, которые мы действительно хотели бы донести до вашего сознания:

При создании новой функции всегда создавайте новую ветвь от master, прежде чем что-либо менять. Если вы случайно внесете изменения в чужую ветку, вам будет не до веселья, но это поправимо, ведь всегда есть предыдущие версии.

Никогда, никогда не делайте коммиты в RobustToolbox или в любые субмодули, подобные Lidgren. Лучше спросить совета у разработчиков. В локальном репозитории верхнего уровня эти субмодули считаются "файлами", поэтому их легко случайно создать и изменить.Не делайте этого. Смотрите ниже, как исправить ваши ошибки, если это произойдет. Если вам нужна дополнительная помощь с Git, не стесняйтесь спрашивать в Lost Paradise #дать имя разделу.

Краткий пример рабочего процесса

Чтобы собрать все в голове и обобщить все это, вот пример рабочего процесса для выполнения нескольких запросов на извлечение с использованием команд Git Bash.

git checkout master # Прежде чем мы создадим новую ветку, мы должны перейти на master .

git fetch upstream # Мы извлекаем любые новые изменения из репозитория SS14

git merge upstream / master # и объединяем их в нашу главную ветку.

git checkout -b my-new-feature # Создайте новую ветку для функции↵...локальные изменения позже...

git add -A # Добавьте все наши локальные изменения в промежуточную область

git commit -m "Исправьте взрывы спагетти" # Зафиксируйте их

git push origin my-new-feature # и отправьте их на наш удаленный сервер


Теперь вы захотите поработать над чем-то другим.

git checkout master

Прошло не слишком много времени, и ничего важного не было объединено,

поэтому я не буду снова извлекать и объединять изменения - просто создам новую ветку.

git checkout -b еще одна функция↵...локальные изменения позже...

git add -A

git commit -m "Удаляет ядерные оперативники"


Я внёс изменение, но потом понял, что мой коммит был совершенно неправильным.

и я вернусь к этому позже.

git revert HEAD

git checkout master


... неделю спустя...

Было объединено много нового материала, так что давайте обновим нашу ветку.

git fetch upstream

git merge upstream / master master

git checkout другая функция

git merge master


Теперь мы внесем изменения и снова запустим, на этот раз правильно.

...локальные изменения позже..

git add -A

git commit -m "Добавляет игровой режим Highlander"

git push origin another-feature


Созданы оба ПР, оба были объединены, на этом мы закончили

мастер оформления заказа git

ветка git -d my-new-feature # Удалить обе старые ветки

ветка git -d another-feature

Глоссарий: Внутренние махинации Git

Просто для справки, вот небольшой глоссарий концепций и терминов Git, объясненный чуть более подробно, и все это в одном месте.

'Ветви' это автономные версии кодовой базы, в которые вы можете добавлять коммиты. Ветка по умолчанию - master, но вы можете создавать столько, сколько захотите.

"Репозитории" - это, по сути, просто папки, в которые вы можете использовать Git для внесения изменений и отслеживания внесенных изменений. Локальные репозитории - это репозитории, которые есть у вас на компьютере, а удаленные репозитории - это репозитории, размещенные на веб-сайтах, таких как GitHub. Репозитории состоят из множества ветвей.

'Remotes' - это названия удаленных репозиториев и ссылки на них, которые может использовать ваш локальный репозиторий.

'Субмодули' - это репозитории, расположенные внутри другого репозитория.

"Форки" - это репозитории, основанные на другом репозитории. Если вы собираетесь отправить запрос на извлечение в репозиторий SS14, вам нужно сначала разветвить его.

"Рабочее дерево" - это просто каждый файл и папка, а также то, чего нет в репозитории.↵ "Промежуточный" означает добавление (с помощью git add) изменений из вашего рабочего дерева в "промежуточную область", где с ним можно выполнять некоторые действия

"Коммиты" - это моментальные снимки рабочего дерева репозитория в данный момент времени. По сути, точка сохранения. "Фиксация" - это просто список файлов, которые были изменены с момента последней фиксации, а "зафиксированные" изменения - это изменения, которые вы "подготовили".

"Проверка" - это процесс переключения на другую ветку, чтобы вы могли поработать с ней или просмотреть ее изменения локально.

"Слияние" - это процесс интеграции изменений из одной ветки в другую ветку.

"Конфликты слияния" возникают, когда интеграция изменений из одной ветви в другую не может быть выполнена автоматически, потому что они оба изменяют одну и ту же область в файле, или их изменения каким-либо другим образом взаимоисключают друг друга.

"Выборка" означает получение веток и коммитов удаленного репозитория, но не на самом деле.. пока что с ними ничего не делается. Вы просто обновите их, если захотите оформить заказ или объединить их позже.

"Pull" - это процесс интеграции изменений из ветки удаленного репозитория в вашу локальную ветку.

"Pull request" - это специфичное для GitHub действие, которое позволяет вам запросить, чтобы ваша локальная ветка и все ее изменения были объединены в ветку другого репозитория.

"Проталкивание" - это процесс интеграции ваших локальных изменений в удаленный репозиторий.

Существует гораздо больше команд и концепций, чем эта, но это все, что вам действительно нужно знать для базовой работы по разработке.

Полезные советы и подсказки

Есть некоторые вещи, которые я не описал, но в какой-то момент вам почти неизбежно придется это сделать. Я быстро опишу все это исключительно как команды git в Git Bash, но их не так уж сложно вычислить в других программах (те же ключевые слова, просто поищите их). Я рекомендую использовать их конкретные руководства, потому что я недостаточно хорошо знаю TortoiseGit / SmartGit / GitKraken / Github Desktop, чтобы помочь вам с более продвинутыми материалами.

Одно замечание, поскольку оно часто встречается здесь: HEAD - это причудливое название коммита, над которым вы сейчас работаете. Не более того. Технически ветви также являются причудливыми названиями для коммитов, но вам пока не обязательно это знать.

Многие из них, мы надеемся вы запомнили читая строки выше.

Решение конфликтов слияния

В работе. Когда-нибудь появится гайд получше.

Противный маленький разработчик сказал вам "исправить конфликты самому", иначе ваш ПР "не будет объединен". Что за мудак! К счастью, это не слишком сложно.

Во-первых, вы захотите обновить свою локальную главную ветку. Смотрите выше, как это сделать.

Когда вы запускаете git merge master [локальная ветка], он либо сделает это чисто (йюхуу!), либо скажет вам, что вы должны разрешить конфликты (уээээ).

Все, что вам нужно сделать для разрешения конфликтов вручную, это зайти в конфликтующие файлы, удалить всю ерунду типа >>>>HEAD и ===== <<<<master (просто указывает, откуда произошли изменения), а затем отредактировать файл так, чтобы он должным образом интегрировал оба набора изменений. Иногда это легко, иногда сложно. Если это сложно, вы, вероятно, знаете, что делаете. После этого просто git commit.

У Atlassian есть хороший гайд на эту тему.

Проверка истории

журнал git -oneline - ваш друг. Он показывает короткие хэши коммитов (уникальные идентификаторы для коммитов), их сообщения, а также их ветви и теги.

Избавление от локальных изменений

Возможно, вы случайно внесли изменения, которых не хотели, и вам не хочется утруждать себя созданием совершенно новой ветки или чего-то в этом роде, но вы еще не зафиксировали эти изменения.

git reset --hard HEAD #Это просто означает "измените рабочее дерево на текущий коммит перед любыми локальными изменениями. Или иначе." Вы не сможете восстановить эти локальные изменения, если сделаете это, так что будьте осторожны.

Unstaging changes [перевести кому-то адекватному]

Ah shit, I just staged RobustToolbox by accident. No fear!

git reset HEAD [file] Alternatively, to unstage everything:

git reset HEAD

Возврат сделанного вами коммита

О черт, твой эротический ксеноморф попала в коммит раньше времени или ты случайно зафиксировал субмодуль! Что теперь? Что ж, есть два решения:

git revert HEAD #Это создает новый коммит, отменяющий текущий коммит, а затем фиксирует его.

Если вы хотите отменить другой коммит, вы можете проверить его хэш в git log --oneline, а затем вызвать git revert [commit hash]. У Git есть более надежная система для этого; вы можете выполнить git revert HEAD ~ 1, чтобы отменить коммит перед вашим текущим, или git revert HEAD ~ 2, чтобы отменить коммит перед этим. Символ ~ 1 просто означает "1 фиксация перед HEAD".

В качестве альтернативы,

git reset --hard HEAD ~ 1

Я не рекомендую делать это, если вы полностью не осознаете, что делаете.

Когда вы ДЕЙСТВИТЕЛЬНО не хотите, чтобы кто-нибудь узнал о том эротическом ксеноморфе, которого вы только что создали. Этот метод переписывает историю, поэтому он не самый лучший для среды совместной работы. Если вы сделаете это, вам нужно будет принудительно нажать (git push origin [branch] --force), иначе это не сработает. Принудительное нажатие может быть опасным, поэтому, опять же, убедитесь, что вы знаете, что делаете.

Проверка изменений PR на локальном уровне

Ладно, это немного сложно. Есть пара способов сделать это:

Github CLI

Установите модную CLI от github и сделайте это:

gh pr checkout [номер pr]

Измена .git/config

Go into your .git folder (hidden by default--may need to enable showing hidden folders in Windows), and open up the 'config' file. There should be a bit that looks something like:

[remote "upstream"] url = https://github.com/space-wizards/space-station-14 fetch = +refs/heads/*:refs/remotes/upstream/*

Добавьте к этому строку, которая читает fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*, таким образом, эта секция теперь должна выглядеть следующим образом:

[remote "upstream"] 

       url = https://github.com/space-wizards/space-station-14
       fetch = +refs/heads/*:refs/remotes/upstream/*
       fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*

Теперь git извлекает данные вверх по течению. Этот метод хорош, если вы полноценный разработчик, а не волонтёр, но он также .. извлекает каждую ветку, которая все еще работает, из каждого открытого PR, так что это не вариант, если вам нужно только что-то конкретное.

Отсюда вы можете выполнить git checkout upstream / pr /[номер pr], чтобы проверить их ветку. По сути, это то, что делает GitHub CLI, но менее сложный.

Добавление нового PR (персональный репозиторий)

Этот метод немного сосёт, потому что он занимает некоторое время, но если вы хотите проверить чужой форк игры и их ответвления, это наиболее подходящий вариант.

На самом деле не так сложно, но это сбивает с толку, если вы не очень хорошо знаете Git.

Настройте удаленный доступ к удаленному репозиторию пользователя, извлеките их ветки, а затем извлеките их ветку:

удаленное добавление git [имя пользователя] https://github.com /[имя пользователя] / space-station-14

git fetch [имя пользователя]↵git checkout [имя пользователя] / [название филиала]

Это также позволяет вам отправлять ссылки на их удаленный филиал, если вы того пожелаете.

Источник — https://wiki.lost-paradise.space/index.php?title=Github_гайд&oldid=5464