Github гайд

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 [имя пользователя] / [название филиала]

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