Шпаргалка по основам Git/GitHub
Если Вы всё еще не знакомы с системой контроля версий и её использование не входит в Ваш рабочий процесс, то сейчас — самое время начать! Это основополагающее руководство поможет Вам начать работу с Git и даст Вам прочный фундамент для дальнейшего развития. Git почти наверняка используется на любом серьёзном проекте и чем раньше Вы научитесь им пользоваться, тем более ценным сотрудником Вы станете для работодателей. Так же, это улучшит Ваш личный опыт, так как Вы без проблем сможете переключаться между несколькими компьютерами, не волнуясь при этом о переносе проекта через флэш накопители… Работа в команде станет гораздо легче. Бывали ли у Вас случаи, когда код становился настолько запутанным, что казалось, будто было бы легче начать проект с нуля? С системой контроля версий Вы сможете просто вернуться к стабильной версии, без всего того что Вы успели воплотить в 4 часа утра.
Git и GitHub
Git — это одна из систем контроля версий. По существу это значит, что она хранит всю историю изменений проекта. История Вашего проекта и история изменений этого же проекта у Ваших коллег — у всего будет копия. Это полная противоположность SVN, где вся история изменений храниться в одном месте.
GitHub, часто путают с Git. На самом деле — это хостинг репозиториев. Возможно Вам пока непонятно что такое репозиторий, но не спешите закрывать статью, к концу всё прояснится. Вкратце, GitHub — это то место, куда Вы будете загружать историю изменений проекта используя Git.
Введение
Git достаточно мудрёный и выучить каждую из его команд не так-то просто, но для начала работы Вам нужно знать всего несколько ключевых понятий. Чем больше Вы будете использовать Git, тем чаще Вы будете сталкиваться с ситуацией, когда начальных знаний окажется недостаточно, но существует большое количество ресурсов, которые придут к Вам на помощь. Так что используйте это руководство как трамплин, не забывая о дальнейшем развитии.
Первым делом мы загрузим Git. Для пользователей Windows я советую установить и Git Bash, который доступен после установки Git. Для пользователей Mac, использование Terminal будет достаточным. После завершения установки приступайте к регистрации аккаунта GitHub. Итак, у Вас есть Git, инструмент командной строки, и GitHub аккаунт, куда Вы будете загружать свои репозитории.
Шпаргалка
Используя Git Bash или Terminal перейдите в корневую директорию проекта. Если Вы используете Git Bash, то с помощью правого клика можно выбрать “Git Bash Here” и он запустится в рабочей директории.
git init
Эта команда создаст .git репозиторий в Вашем проекте. Репозиторий или “repo” это коллекция всех изменений, которые были совершены на протяжении всего времени после инициализации репозитория. Это первое что нужно сделать для нового проекта.
git config —global user.name "Ваше Имя"
git config —global user.email "ВашаПочта@mail.com"
Эти команды определят информацию, которая будет использоваться при каждом commit(фиксирование изменений). Их стоит выполнить всего один раз при первичной установке Git.
git add имяФайла.расширение
Замените “ имяФайла.расширение” на любой файл, изменения которого Вы пытаетесь зафиксировать, например “index.html”. Эта команда добавит файл в “staging area”(участок подготовки). Воспринимайте staging area, как секцию в которой файлы проходят подготовку к перемещению в Ваш репозиторий.
git add .
Если Вы хотите добавить всё из директории проекта в staging area, то эта команда сделает всё сама.
git add *.html
Если Вы хотите добавить все файлы с расширением .html в staging area то эта команда отлично подойдет. Расширение можно менять в зависимости от предпочтений.
git status
Покажет что уже было добавлено в staging area и какие файлы были изменены и ждут перемещения в staging area.
git reset имяФайла.расширение
Убирает выбранный файл из staging area.
git rm —cached имяФайла.расширение
Убирает файл из staging area и определяет его как игнорируемый.
git commit -m "Описание коммита"
Берёт файлы из staging area и “фиксирует” их в Ваш локальный репозиторий. В кавычки следует вставить краткое описание изменений для конкретного коммита. Постарайтесь описать коммит краткими деталями, например: “устранил проблему при изменении имени пользователя” вместо подобных сообщений “какие-то изменения”
touch .gitignore
Эта команда создаст файл с названием .gitignore. Вы можете открыть этот файл в текстовом редакторе и прописать названия файлов или директорий, изменения в которых Вы не хотели бы отслеживать (они будут игнорироваться Git). Изменения в игнорируемых файлах не будут отображаться при выполнении git status .
git branch названиеВетки
Создает сущность, называемую branch(ветвь). Ветвь — это точная копия Ваших файлов.
git checkout “названиеВетки”
Позволит Вам переключить контроль над созданной Вами веткой и работать в её пределах. Здесь Вы можете совершать любые изменения кода. Когда Вы будете готовы можно совершить commit изменений и отправить изменения в GitHub (об этом ниже) или же можно удалить ветвь, если что-то пошло не так или Вам больше не нужны изменения сделанные в этой ветке.
git merge названиеВетки
Находясь в Master(главной) ветви, Вы можете использовать эту команду, чтобы взять коммиты из любой из ветвей и соединить их вместе.
git remote add origin https://github.com/имяПользователя/проект.git
Эта команда определит “местоположение” Вашего удалённого репозитория. Всё что было до этого происходило исключительно в локальном репозитории на Вашем компьютере. Вам нужно будет перейти в GitHub аккаунт и создать новый удалённый репозиторий, куда Вы сможете отправлять изменения из локального репозитория. After you created your remote repository you will be provided with a link and that link is the location you will want to use in the above command.
git remote
Выведет список из всех удалённых репозиториев, которые были добавлены к Вашему проекту.
git push -u origin master
Эта команда отправит локальные изменения в удалённый репозиторий. Таким образом эту команду стоит прописывать только первый раз.
git push
This is what you will use to push your code to GitHub after your initial push.
git clone https://github.com/имяПользователя/проект.git
Если у Вас отсутствует проект на личном или рабочем компьютере, то эта команда поможет клонировать/загрузить весь проект в текущую директорию.
git pull
Если Вы работаете над одним и тем же проектом с несколькими людьми, то эта команда позволит загрузить последнюю версию из удалённого репозитория и обновить вашу локальную версию.
Вывод
Надеюсь это руководство поможет Вам начать и понимать что вообще происходит. Буду рад помочь с уточнениями и ответами на вопросы в комментариях.
Git для начинающих. Урок 2.
Создание и клонирование репозитория
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Что такое репозиторий
Это каталог в файловой системе, где хранится информация о проекте:
- файлы и папки проекта
- история проекта
- настройки проекта
- служебная информация
Информация о репозитории хранится в скрытой папке .git в корне проекта.
Можно ли работать с git локально
Да, можно. Но при этом проект находится только на нашей машине и в случае поломки железа или случайной потери данных мы не сможем восстановить проект.
Локальный репозиторий
Это репозиторий, который хранится на нашей машине, в рабочей папке проекта. Это та самая скрытая папка .git
Удаленный репозиторий, зачем он нужен
Это репозиторий, который хранится в облаке, на сторонних сервисах, специально созданных под работу с проектами git.
Плюсы удаленного репозитория
- выполняет роль резервной копии
- возможность работать в команде
- некоторые дополнительные возможности, которые предоставляет хостинг. Например, визуализация истории или возможность работать над проектом прямо в веб-интерфейсе
Что такое клонирование
Это копирование удаленного репозитория на локальную машину. Обычно это первое действие при работе с проектом. При клонировании на нашу машину копируются файлы и папки проекта и вся его история. То есть мы получаем доступ к истории не с момента начала нашей работы над проектом, а с самого начала проекта.
Как клонировать готовый проект
В первую очередь, нужно получить ссылку на проект. Мы можем найти ее сами или получим готовую, например, на новой работе. Возьмем для примера репозиторий vuejs — https://github.com/vuejs/vue.git
Наберем в командной строке
При этом в текущем каталоге создастся папка vue, в ней окажутся все файлы проекта vue и специальная скрытая папка .git, то есть сам репозиторий, или информация о нем.
Как клонировать проект в другую папку
При клонировании по умолчанию создается папка с таким же названием, как и у репозитория. Но можно склонировать репозиторий и в другую папку вот так
Где vue-new — нужное название папки.
Свой удаленный репозиторий
Для своих проектов нам понадобится собственный репозиторий. Можно работать и локально, но плюсы удаленного мы уже рассматривали выше. Теперь нужно выбрать хостинг для наших git-проектов.
Где держать репозиторий
Есть множество вариантов, самые известные — это github и bitbucket. Нужно выбирать.
На самом деле не парьтесь. У них схожий функционал, и в начале работы с git мы не заметим разницы. bitbucket мне нравится больше из-за интерфейса, но в уроках выберем github из-за его большей популярности.
Чтобы продолжить уроки, нужно зарегистрироваться на github. Если у вас нет там аккаунта, то форму регистрации увидите сразу на главной странице — https://github.com/
Как создать репозиторий в github
После регистрации создание репозитория доступно с главной страницы github. При создании нужно указать название проекта и тип (публичный или приватный). На остальное пока не обращаем внимания.
Права на репозиторий, публичные и приватные
Есть 2 типа репозиториев:
- публичный (public), открыт всем
- приватный (private), доступен только определенному кругу лиц — в первую очередь, нам самим
Публичные репозитории хороши для opensource-проектов и чтобы показать в резюме. Пока нам это не нужно.
Для себя будем создавать приватные репозитории. Для этого нам понадобятся ssh-ключи.
Что такое ssh-ключи
ssh-ключи используются для идентификации клиента на сервере при подключении по безопасному ssh-протоколу. Другими словами, ssh-ключ нужен для того, чтобы пускать на сервер только определенных клиентов. Только тех, кому разрешен доступ к проекту.
ssh-ключ не имеет прямого отношения к git, но так репозитории находятся на удаленных серверах, то ssh-ключи используются для разграничения доступа к приватным репозиториям.
ssh-ключ состоит из пары ключей: публичного и приватного ключа. Это просто 2 текстовых файла:
- /домашний-каталог/.ssh/id_rsa.pub — публичный
- /домашний-каталог/.ssh/id_rsa — приватный
Публичный ключ передается сторонним серверам, например, github, для открытия доступа на эти сервера. Приватный ключ хранится только на нашей машине и никому не передается. То есть когда у нас просят ssh-ключ, чтобы дать доступ на какой-нибудь сервер, мы отдаем именно публичный ключ, id_rsa.pub
Как сгенерировать ssh-ключ
ssh-ключи сами собой не появляются, но стоит проверить, возможно, они были установлены раньше. Запустим в терминале команды
Если видим файлы id_rsa и id_rsa.pub — отлично, ключи уже есть.
Если этих файлов нет, то нужно сгенерировать ключи утилитой ssh-keygen. В Windows она устанавливается вместе с git, в Linux и MacOS при необходимости установите. В Linux, например, вот так
После этого нужно сгенерировать пару ключей, запустив команду в терминале
Появились файлы id_rsa и id_rsa.pub — значит, ключи успешно сгенерированы.
known_hosts — это файл, в котором ssh прописывает сервера, на которые мы заходим. При первом подключении к github нужно будет разрешить доступ к github.com (напечатать yes в терминале)
Как добавить ssh-ключ в настройках github
Открываем публичный ключ id_rsa.pub и копируем его содержимое. В настройках github ищем раздел «SSH и GPG keys» — https://github.com/settings/keys. Жмем «New SSH key», задаем название ключа, например, имя, и вставляем форму публичный ключ, прямо текстом. Все, теперь у нас есть доступ к нашим приватным репозиториям.
Два способа создания проекта
Первый, когда мы начинаем новый проект. Удобнее будет создать репозиторий на github и склонировать пустой проект на локальную машину.
Второй, когда у нас уже есть проект. Нужно зайти в папку проекта и связать его с уже существующим репозиторием на github. Это называется инициализация.
Рассмотрим оба способа.
Пустой проект
Создаем приватный репозиторий на github, назовем его first-site. Я зарегистрировался под именем Webdevkin, моя ссылка для клонирования будет такая — git@github.com:Webdevkin/first-site.git. Ваша зависит от имени пользователя.
Идем в командную строку и запускаем
В текущей папке получим новую папку с названием first-site — это и есть наш проект.
P.S. У вас склонировать этот репозиторий не получится — он закрытый. Создайте свой 🙂
Непустой проект
Допустим, у нас на локальной машине уже есть проект second-site. Создаем в github репозиторий second-site. Заходим в папку проекта и выполняем команды
Все, можно приступать к работе над проектом. Команды add, commit и push мы разберем в следующих уроках.
Это единственный урок, в котором мы разбирались с тонкостями репозиториев. В дальнейшем будем считать, что репозиторий = проект.
Что могу посоветовать
- github или bitbucket? Для личных проектов неважно, оба сервиса разрешают бесплатно создавать приватные репозитории. Для open source или резюме — github
- не увлекайтесь клонированием в папку со своим названием. Есть шанс запутаться, самому или коллегам
- не путайте публичный и приватный ключи. Отдаем вовне только публичный ключ id_rsa.pub
- при смене рабочей машины можно не генерировать ssh-ключи заново, а скопировать их со старой машины. Тогда не придется заново прописывать новые ключи на серверах
Немного подробнее о копировании ssh-ключей
Как скопировать ssh-ключи с одной машины на другую
Хочу немного затронуть эту тему отдельно. Генерировать ключ на новой машине не обязательно. Но нужно выполнить такие действия
- Скопировать id_rsa и id_rsa.pub со старой машины на новую
- Посмотреть права на файлы, возможно, ключи окажутся слишком «открытыми» для записи и потребуется сменить им права доступа — sudo chmod 700
Ссылки, которые могут пригодиться
- github — https://github.com/
- bitbucket — https://bitbucket.org/
- подробнее об ssh-ключах (en) — connecting-to-github-with-ssh
На этом все. В следующем уроке мы сделаем первые изменения в проекте и начнем понимать, в чем заключается прелесть git.
2.5 Основы Git — Работа с удалёнными репозиториями
Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями. Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети. У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи. Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение данных из них. Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее. В данном разделе мы рассмотрим некоторые из этих навыков.
Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. Слово «удалённый» не означает, что репозиторий обязательно должен быть где-то в сети или Интернет, а значит только — где-то ещё. Работа с таким удалённым репозиторием подразумевает выполнение стандартных операций отправки и получения, как и с любым другим удалённым репозиторием.
Просмотр удалённых репозиториев
Для того, чтобы просмотреть список настроенных удалённых репозиториев, вы можете запустить команду git remote . Она выведет названия доступных удалённых репозиториев. Если вы клонировали репозиторий, то увидите как минимум origin — имя по умолчанию, которое Git даёт серверу, с которого производилось клонирование:
Вы можете также указать ключ -v , чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:
Если у вас больше одного удалённого репозитория, команда выведет их все. Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:
Это означает, что мы можем легко получить изменения от любого из этих пользователей. Возможно, что некоторые из репозиториев доступны для записи и в них можно отправлять свои изменения, хотя вывод команды не даёт никакой информации о правах доступа.
Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.
Добавление удалённых репозиториев
В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add <shortname> <url> :
Теперь вместо указания полного пути вы можете использовать pb . Например, если вы хотите получить изменения, которые есть у Пола, но нету у вас, вы можете выполнить команду git fetch pb :
Ветка master из репозитория Пола сейчас доступна вам под именем pb/master . Вы можете слить её с одной из ваших веток или переключить на неё локальную ветку, чтобы просмотреть содержимое ветки Пола. Более подробно работа с ветками рассмотрена в главе Ветвление в Git.
Получение изменений из удалённого репозитория — Fetch и Pull
Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch). Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Если ветка настроена на отслеживание удалённой ветки (см. следующий раздел и главу Ветвление в Git чтобы получить больше информации), то вы можете использовать команду git pull чтобы автоматически получить изменения из удалённой ветки и слить их со своей текущей. Этот способ может для вас оказаться более простым или более удобным. К тому же, по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали репозиторий. Название веток может быть другим и зависит от ветки по умолчанию на сервере. Выполнение git pull , как правило, извлекает (fetch) данные с сервера, с которого вы изначально клонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
Начиная с версии 2.27, команда git pull выдаёт предупреждение, если настройка pull.rebase не установлена. Git будет выводить это предупреждение каждый раз пока настройка не будет установлена.
Если хотите использовать поведение Git по умолчанию (простое смещение вперёд если возможно — иначе создание коммита слияния): git config —global pull.rebase «false»
Если хотите использовать перебазирование при получении изменений: git config —global pull.rebase «true»
Отправка изменений в удаленный репозиторий (Push)
Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удалённый репозиторий. Команда для этого действия простая: git push <remote-name> <branch-name> . Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:
Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push . Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push , а после него выполнить команду push попытаетесь вы, то ваш push точно будет отклонён. Вам придётся сначала получить изменения и объединить их с вашими и только после этого вам будет позволено выполнить push . Обратитесь к главе Ветвление в Git для более подробного описания, как отправлять изменения на удалённый сервер.
Просмотр удаленного репозитория
Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show <remote> . Выполнив эту команду с некоторым именем, например, origin , вы получите следующий результат:
Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что если вы, находясь на ветке master, выполните git pull , ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок.
Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show :
Данная команда показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push . Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере, и для нескольких веток показано, какие удалённые ветки будут в них влиты при выполнении git pull .
Удаление и переименование удалённых репозиториев
Для переименования удалённого репозитория можно выполнить git remote rename . Например, если вы хотите переименовать pb в paul , вы можете это сделать при помощи git remote rename :
Стоит упомянуть, что это также изменит имена удалённых веток в вашем репозитории. То, к чему вы обращались как pb/master , теперь стало paul/master .
Если по какой-то причине вы хотите удалить удаленный репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm :
При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.
GitHub клонирование, редактирование, отправка. SSH, Branch, Master.
В этой статье разберем как клонировать с GitHub, вносить правки в проект и отправлять на согласование обратно. По сути полный рабочий цикл в рамках простых изменений. Данная статья является продолжением первой статьи «Знакомство с GitHub и локальным репозиторием». Все примера приведены в Linux Debia 10.
В статье ранее обсудили создание аккаунта и первого репозитория. Продолжим. У нас создан «newproject»:
1. Клонируем наш проект на локальную машину. Для этого заходим в «newproject» в окно, на картинке выше. Есть два варианта «Clone or download» (зеленая кнопка в правой части):
- Clone with SSH: Use a password protected SSH key.
- Clone with HTTPS: Use Git or checkout with SVN using the web URL.
Мы будем использовать вариант по SSH, так как он более безопасный и надежный. Перед тем как использовать этот вариант, необходимо создать ключи для SSH. Начнем:
Дальше идем в личный кабинет GitHub, правый верхний угол «основное меню — пиктограмма», раздел «Settings», подраздел «SSH and GPG keys» и нажимаем «New SSH key»:
В поле «Title» пишем название, у нас «GitHubLocal», в поле «Key» вводим наш ключ «ssh-rsa AAAA. odJ debuser@debsv» и сохраняем, попросит пароль для подтверждения действия. Все, наш ключ будет использован при подключении с локального компьютера к GitHub при клонировании из под нашего пользователя.
Возвращаемся к нашему локальному Linux и для удобства создаем папку под проекты GitHub:
Приступим к клонированию ветки с GitHub. Для этого заходим опять в личный кабинет GitHub, нажимаем на «Clone or download» и выбираем SSH, копируем ссылку. Дальше вводим следующую команду на нашем Linux (git clone):
Проверяем что произошло:
Все получилось! Мы загрузили данные с GitHub, на свой локальный компьютер. И как видим, там только один файл README которой создал сам GitHub при создании нашего репозитория. В случае боевого клонирования, у вас будет куча файлов для разработки и редактирования.
Теперь внесем данные со своим файлом и отправим обратно на сервер GitHub. Если кто не знает или не читал, все комманды которые мы сейчас будем использовать, описанны в предыдущей статье, тут: Знакомство с GitHub
Создаем свой файл с кодом, и отправляем на GitHub:
Проверяем что получилось, для этого заходим в личный кабинет GitHub в нашу созданную ветку:
Как мы видим, наш файл благополучно загрузился. Вы может его редактировать и вносить правки на локальном Linux, а потом отправлять на сервер. Можете делиться ссылками для совместых разработок. Все примеры выше, в рамках ветки «Branch: master». Использовать эту ветку в реальных боевых условиях «работодателя или крупного своего проекта» не рекомендуем. Желательно создать отдельную ветку для разработки, а в случае удачного исполнения, сливать в основную мастер. Поэтому, сейчас рассмотрим вариант работы с веткой для разработки, не используя мастер.
Рассмотрим ситуацию: нам дали ссылку для клонирования нового проекта(на примере ниже, будем использовать наш же проект) и нам ненадо вносить изминения в мастер, необходимо создать свой branch. Для этого, делаем следующе:
В коде выше, мы скачали мастер бренч, перешли в свой бренч и отредактировали данные для сервера. По сути мы взяли проект, сделали его копию в рамках своей ветки, и провели редактирование. Дальше нам надо отправить проект на сервер и согласовать объединение нашей ветки с веткой мастера. При условии, что мы внесли верные изминения в проект и их можно выдавать в так называемый продакшинс.
Приступим к отправке наших правок на сервер GitHub и посмотрим куда они попадут:
Напоминаю, на сервере есть только одна ветка мастер, проверяем, что произошло. Заходим на GitHub в личный кабинет:
Переключаемся в нашу ветку, и смотрим что там. Заметим, ветка основного мастера содержит те файлы которые были изначально, мы их никак не попортили:
В правом в верхнем углу выбираем «Compare & pull request». Дальше пишите пояснения, какие изменения были, что протестировали и т.д. Указываете какую ветку соединить с мастером и отправляете:
В итоге будет такое окно. У вас либо будет право на соединение (как у меня, так как я сам себе админ), либо нет. Тогда ждете подтверждения вышестоящего: