Как использовать Git и GitHub для совместного программирования?

Октябрь 2018 г.

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

Каталог:

• Организации
• Вилки
• Запросы на вытягивание
• Процесс проверки кода
• Развертывание
• Теги
• Релизы
• Расширенные возможности

Я дал вам основную идею Git и GitHub в моем предыдущем посте. В этом посте мы увидим, как мы можем улучшить знания о VCS (Система контроля версий) и сделать наш процесс разработки более структурированным, чтобы работать с сообществом или коллегами для лучшего совместного программирования.

Хорошо, я сказал «Сообщество» или «Сотрудники». Если они тоже хотят внести свой вклад, как они могут видеть и работать с вашим собственным облачным репозиторием? Нам нужен общий репозиторий для размещения нашего проекта, чтобы любой другой человек, желающий работать над проектом, мог получить к нему доступ.

Как мы это делаем? Вот так.

Организации

Организация похожа на создание группы в GitHub, точно так же, как группы в других социальных сетях или платформах обмена сообщениями, таких как Facebook, WhatsApp, Skype и т. Д.

Что круче, чем группа программистов в одном месте! 💙

Начнем с создания организации.

Перейдите на домашнюю страницу GitHub или щелкните здесь, чтобы увидеть следующий экран.

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

Справа вверху есть этот значок +, щелчок по нему откроет это раскрывающееся окно.

У вас уже есть идея, не так ли? Если вы еще этого не сделали, нажмите «Создать новую организацию», чтобы создать новую организацию. 😑

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

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

Ваше здоровье! Теперь у вас есть собственная организация. 😎

Организации могут содержать проекты (репозитории AKA) и существующих членов GitHub как его часть. Итак, мы должны создать проект в организации, чтобы другие люди работали над ним вместе с нами как одна команда.

Чего ждем? Давай создадим его.

На главной странице вашей организации вы можете увидеть кнопку «Создать». Щелчок по нему откроет окно, в котором вы можете заполнить некоторые детали и создать репозиторий так же, как создание репозитория с нашей собственной учетной записью. Единственная разница в том, что репозиторий принадлежит организации, а не вам, даже если он был создан вами. Что это значит? Это означает, что только те, кто имеет административный доступ к вашей организации, могут делать с этими репозиториями все, а другие участники - нет.

Не волнуйся. В настоящее время вы единственный администратор в своей организации.

Вы не можете отправить код в репозиторий, который вы только что создали в своей организации.

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

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

Хорошо, как они это делают? Вот где в игру вступает Разветвление.

Вилки

Форк - это не что иное, как копия репозитория.

Давай вилку!

На главной странице проекта вашей организации вы можете увидеть кнопку с названием «Вилка» в правом верхнем углу, как показано ниже.

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

Знаете что, вы владелец этого репозитория скопированных форков. (Несмотря на то, что он наследует некоторые свойства репозитория организации, такие как конфигурации безопасности и т. Д.)

В чем разница между форком и вашим собственным репозиторием?

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

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

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

Но как предложить эти изменения в репо организации? Пройдите дальше, чтобы найти ответ.

Запросы на вытягивание

Запрос на вытягивание (AKA PR) - это метод предложения изменений кода в родительском репо или даже одной ветви в другую в том же репо.

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

Таким образом, вы не единственный, кто берет на себя вину, когда что-то идет не так в базе кода. 😝

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

Давайте посмотрим на это в действии.

Клонируйте репозиторий вилки на локальный компьютер. Создайте новую ветку, назовите ее feature/first-proposal, внесите некоторые изменения в код ветки и отправьте фиксацию в вашу вилку в облаке.

Если не знаете, как это сделать, обратитесь к моей предыдущей статье.

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

Теперь перейдите в новую ветку, выбрав feature/first-proposal в раскрывающемся списке.

Давайте создадим запрос на извлечение, нажав кнопку «Новый запрос на извлечение» рядом с раскрывающимся списком выбора ветви. Теперь он будет просто предварительно просматривать запрос на перенос, который вы собираетесь создать. Вы можете изменить любые данные, изменить имя запроса на перенос и изменить родительскую ветку, для которой вы предлагаете изменение кода. Как только вы будете уверены во всех деталях, нажмите «Создать запрос на перенос», чтобы подтвердить предложение.

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

Процесс проверки кода

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

И наоборот, вам нужно будет просмотреть код своих товарищей по команде, чтобы знать, что происходит с проектом.

Так как же нам это сделать?

Щелкните вкладку с надписью «Файлы изменены», как показано ниже. Откроется страница, показывающая все изменения кода в некоторых цветовых кодах во всех файлах, которые вы или ваш товарищ по команде изменили.

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

Рецензент должен пройти через все изменения кода и посмотреть, есть ли в нем очевидная ошибка. Если есть какая-то ошибка, или что-то нужно сделать иначе или пропустить, рецензент может оставить комментарий к запросу. Вам не нужно никуда идти, чтобы оставить комментарий, замечательная функция, которую GitHub сделал для вас, заключается в том, что вы можете оставить комментарий в любой строке, и он будет указывать точную строку для всех, кто позже просматривает PR.

Когда вы наводите курсор на код, вы можете увидеть синюю кнопку со значком + (плюс) перед началом строки, щелчок по ней откроет поле для комментариев в той же строке. Вы можете вводить что угодно, отмечать кого угодно в организации и делать многое другое, как и в любом другом поле для комментариев. Поддерживаются даже смайлы. 😉

Затем запрашивающий получит уведомление по электронной почте и в уведомлениях GitHub о комментарии в их PR. И даже рецензент может проинформировать автора запроса в любом чате, чтобы сразу привлечь его внимание. Можно продолжить беседы в PR или внести соответствующие изменения и отправить их с дополнительными коммитами в ту же ветку.

После того, как запрашивающий обработает все комментарии, оставленные рецензентом, теперь будет обновлена ​​страница «Файлы изменены», и рецензент должен снова внести изменения, чтобы убедиться, что в файле не произошло ничего хуже. следующий коммит. 😝

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

Когда все будет в порядке, рецензент должен утвердить запрос на перенос, нажав кнопку «Проверить изменения» и отправить его, установив переключатель «Утвердить», как показано ниже.

И объедините запрос на перенос с главной ветвью репозитория организации, нажав кнопку «Объединить запрос на перенос» и подтвердив его, как показано ниже.

Для объединения с репозиторием организации не требуется утверждать запрос на извлечение, если он не настроен соответствующим образом. Таким образом, вы можете самостоятельно просмотреть изменения кода и без утверждения объединить их с основной веткой. Но в идеале это не рекомендуется.

Развертывание

В проектах организации мы будем развертывать код где-нибудь через FTP или какой-либо инструмент контейнеризации (Docker или Kubernetes) в облаке через любого поставщика услуг, например Amazon Web Services, Azure Cloud, Google Cloud Platform и многих других.

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

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

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

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

Теги

Теги - это не что иное, как именование выпущенной версии проекта и сохранение всех файлов проекта на любом этапе в некотором сжатом формате в качестве резервной копии.

Процесс аналогичен веткам.

Давайте создадим тег, выполнив следующую команду, открыв окно терминала в каталоге вашего проекта.
git tag v1.0
v1.0 - здесь имя тега. Это похоже на имя ветки, вместо него вы можете ввести что угодно.

Давайте разместим этот тег в репозитории вашего форка в облаке.
git push origin v1.0
Вышеупомянутая команда поместит тег в ваш форк, что означает, что вы сделали резервную копию файлов проекта в своем облаке. Его можно получить и восстановить в любое время. Когда что-то рушится на развернутом сервере, вы можете использовать эти теги для отката к предыдущей версии проекта. Обычно теги помещаются в репозиторий организации, а не в репозиторий любой вилки, чтобы теги оставались доступными для всей организации.

Итак, как нам восстановить тег, помещенный в облако?

Команда git fetch origin извлечет все ветки, как вы знаете. Он также загрузит все теги на ваш локальный компьютер.

Вы можете увидеть все теги, выполнив git tag. В нем будут перечислены имена всех тегов на вашем локальном компьютере.

Допустим, вы сделали много коммитов и перешли в другую ветку, и ваш владелец продукта / менеджер просит вас выполнить откат до версии v1.0 в среду разработки на облачном сервере.

Вы можете получить все теги из облака с помощью команд, перечисленных выше. Вы можете восстановить конкретный тег, используя git checkout origin/v1.0, точно так же, как оформление заказа в ветку. Он восстановит код из тега v1.0, поскольку вы его сделали резервную копию. Теперь вы можете приступить к развертыванию кода на сервере с вашего локального компьютера.

Релизы

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

Вы можете найти вкладку под названием «выпуски», как показано ниже.

Щелкните вкладку «Тег», как показано ниже, чтобы просмотреть список тегов, которые были переданы в ваш облачный репозиторий.

Выберите тег, который вы хотите назвать последней версией. Затем нажмите кнопку «Изменить тег» в правом верхнем углу, как показано ниже.

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

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

Идите и отправьте релиз.

Теперь вы можете видеть детали этого тега вверху, помеченные как «Последний выпуск» на странице «Выпуски», как показано ниже.

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

Потрясающие! Мы закончили с основными рабочими процессами, которым следуют в наши дни при совместном программировании в организациях.

Расширенные возможности

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

• Сохраняйте изменения кода в памяти, не фиксируя и не теряя их с помощью функции git stash
• Редактируйте сообщения фиксации, объединяйте несколько фиксаций в одну, удаляйте фиксацию в ветке и многое другое с помощью функции «Rebase» с помощью команды git rebase.
• Просматривайте все журналы коммитов и даже изменения кода с помощью команды git log.
• Используйте любую конкретную фиксацию, сделанную в прошлом в вашей текущей ветке, с помощью команды git cherry-pick
• Просматривайте изменения кода с помощью параметров интеллектуальной фильтрации, таких как автор фиксации или конкретное слово в коде, и многое другое, чтобы найти какие-либо фиксации в прошлом с помощью команды git blame

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

Если вам понравился этот пост, похлопайте по нему или два. Даже пятьдесят, если тебе это действительно пригодится. 😉

Давайте подключимся к социальным платформам,

GitHub, LinkedIn, Twitter

Удачного кодирования. 👩‍💻🙂

- Равирадж Субраманиан