Как выложить свою программу на гитхаб

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

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

Насколько это целесообразно

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

КАК ЗАГРУЗИТЬ СВОЙ ПРОЕКТ И СОЗДАТЬ ПОРТФОЛИО НА GitHub 2023

Начинающему разработчику размещение портфолио на Гитхаб даст такие плюшки:

• Бесплатный сервер. Если ваши проекты в портфолио еще нигде не опубликованы или вы вообще делали их “чтоб было что показать”, то бесплатный сервер это неплохое предложение. Причем по качеству он не уступает многим платным аналогам. Так вам не нужно покупать сервер для размещения портфолио или под каждый отдельный проект – GitHub может быть неплохой “песочницей” перед публикацией.
• Вы можете получать обратную связь по своим проектам от других разработчиков и рекрутеров. Это полезно, так как вам быстро укажут на ошибки и подскажут как можно было бы решить ту или иную задачу. Также доступна возможность комментирования проектов других разработчиков.
• Доступна демонстрация кода и файловой структуры. Рекрутер видит не только готовую картинку, но и то как вы решаете поставленные задачи, насколько у вас хороший код и логичная структура проектов.

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

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

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

Как выложить свой проект на github

Оформление профиля на GitHub Pages

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

Оцениваются две вещи: навык владения технологиями и коммуникации в среде разработчиков. С первым все более-менее понятно – код либо написан корректно и работает, либо вся конструкция держится на “костылях”. Со вторым не очень. Под коммуникациями подразумевается умение писать понятный для других разработчиков код, сопровождать его комментариями, умение правильно выстраивать иерархию внутри репозитория, да и создавать сами репозитории. Про то, как писать хороший код у нас есть отдельная статья.

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

Отлично, если вы участвовали в каких-то открытых проектах, например, хакатонах. Так вы приобретаете и реальный опыт, и получаете в копилку законченную работу, над которой, возможно, трудилась команда разработчиков. Указание хакатонов в резюме покажет не только то, что у вас есть реальный опыт, но и то, что вы заинтересованы в своей профессии.

Добавление и оформление репозитория

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

Создание репозитория

На репозитории содержится весь код, документация и полезные ссылки для вашего проекта. Вот как он создается на стороне GitHub:

• Войдите в свой аккаунт. Если его нет, то зарегистрируйте. В регистрации аккаунта нет ничего сложного – просто укажите почту.
• Теперь перейдите непосредственно к созданию репозитория. Это можно сделать, нажав на кнопку “New repository” или “Start a project”.

Кнопка создания репозитория

• Вас перебросит на страницу создания репозитория. В верхней части находятся поля “Owner” и “Repository name”. “Owner”, то есть владелец, по умолчанию ваш логин в GitHub. Меняйте его только в том случае, если добавляете какой-нибудь командный проект. В “Repository name” указывайте название проекта латиницей и без пробелов.
• Далее выберите тип репозитория. Есть публичный и приватный. В последнем случае вы сами выбираете, кто может смотреть его содержимое и оставлять комментарии. По умолчанию рекомендуется оставить “Public”, так как его требуется меньше настраивать.
• Перед созданием репозитория, рекомендуется поставить галочку у “Initialize this repository with a README”. С помощью README-файла проще составлять документацию и проводить инициализацию репозитория.
• Также в настройках есть пункты добавления файла .gitignore и лицензии на проект. По умолчанию ничего не добавляйте.
• Теперь жмите кнопку “Create repository”. Репозиторий создан и вы можете его редактировать, добавляя файлы проекта, описание, документацию.

Рекомендуемые настройки создаваемого репозитория

Составление описания

Блок с описанием находится в верхней части вашего репозитория. Это первое, что видит человек, перешедший по ссылке. В этом блоке опишите, о чем ваш проект, какие технологии использовали, что было необычного во время выполнения и так далее. Не нужно слишком много текста – хватит одного абзаца на 3-5 предложений. В конце расположите ссылку на работающий проект (веб-страницу, например).

Чтобы начать писать описание, просто нажмите кнопку Edit, что расположена справа.

Кнопка редактирования описания репозитория

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

Заполнение документации

Она указывается в файле README.md, который создается вместе с репозиторием, если в условиях не было отключено его создание. По умолчанию в нем только написано название репозитория.

Вот рекомендации по минимальному заполнению данного файла:

Пример полностью заполнено файла README

Оформление текста происходит с помощью синтаксиса markdown. Используйте его, чтобы документация не выглядела как полотно текста. Он чем-то похож на оформление текста в HTML и XML. Вот более подробный гайд на английском языке на Github.

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

Что можно добавить в документацию дополнительно:

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

Пример скрина в файле README

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

Как загрузить файлы и папки проекта

Вы создали репозиторий и написали документацию, но без файлов проекта вы не сможете ничего толком продемонстрировать рекрутеру. Удобнее всего управлять файлами с помощью приложения Github Desktop. Скачайте его для своей операционной системы. Он есть для Mac, Windows и Linux. В нем потребуется войти в свой аккаунт на Github и клонировать созданный репозиторий на компьютер.

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

Инструмент по работе с репозиториями в GitHub Desktop

Далее перейдите в папку созданного репозитория и просто перетащите файлы проекта в нее. Изменения сразу же отобразятся в интерфейсе GitHub Desktop во вкладке “Changes”. В ней показываются добавленные файлы и изменения в самих файлах. Чтобы изменения появились и в удаленном репозитории (тот что на серверах Гитхаба), нажимайте Push Origin.

Отображение изменений в репозитории

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

Чтобы окончательно завершить публикацию, нужно проделать следующие действия на стороне веб-версии Гитхаба:

1. Откройте репозиторий, с которым работаете. Перейдите во вкладку “Settings”.

2. В левом меню откройте раздел “Options”.

Переход в Options

3. Найдите раздел “GitHub Pages”. Установите в качестве источника файлов вашей страницы ветку master созданного репозитория. После этого по ссылке на ваш репозиторий можно будет попасть непосредственно на сайт, который был размещен в портфолио.

Установка источника файлов репозитория

Оформление профиля на GitHub

Также нужно уделить время оформлению профилю на GitHub, особенно, если в резюме вы даете ссылку именно на него, а не какой-то конкретный репозиторий. Рекомендации здесь минимальны:

• Установите аватар профиля. Желательно, чтобы он совпадал с той фотографией, которая приложена к вашему резюме.
• Укажите имя и фамилию. По умолчанию там ставится просто логин.
• Напишите, чем занимаетесь. Например, “Front-end developer (React, Node.js)”.
• Добавьте какую-нибудь дополнительную информацию: город проживания, ссылку на резюме и так далее.
• Укажите несколько проектов, с которых вы бы хотели, чтобы посетитель начал изучение ваших работ. Для этого нажмите кнопку “Customize your pins” и выберите среди ваших репозиториев те, которые хотите показать на главной странице профиля.

Пример хорошо оформленного профиля на GitHub

Заключение

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

Источник: liquidhub.ru

Краткая инструкция, как заливать на Github коды собственных программ

Практически все профессиональные разработчики по крайней мере слышали про такой сервис , как GitHub. А многие молодые разработчики слышать слышали об этом сервисе, но как залить код на GitHub — не знают. В этой статье мы разберем, как выложить на ГитХаб свою разработку.

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

Как залить код на GitHub

Сегодня мы покажем способ , как залить код на ГитХаб при помощи специального приложения GitHub Desktop. Данное приложение позволяет залить код на GitHub без специальных команд в Консоли. Работа с Консолью почему-то вызывает трудности у молодых специалистов.

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

Как зарегистрироваться на GitHub

• Git — это локальное хранилище вашей разработки;
• GitHub — это облачное хранилище вашей разработки с большим количеством разных дополнительн ых «плюшек» в виде бесплатного хостинга, сообщества и др.

• публичный — ваш код будет виден всем участникам сервиса;
• приватный — ваш код будут видеть только те, кому вы откроете доступ.

• расширенным хранилищем ;
• повышенной защищенностью ;
• специальным набором инструментов для профессионального программирования.

• рассказать о себе;
• открыть свои соцсети;
• написать , каким стеком технологий владеете;
• открыт ь контакты для связи с вами.

Как добавить новый репозиторий, чтобы залить код на GitHub

• найти и нажать кнопку «New repository»;
• назвать свой будущий проект и кликнуть на «Create repository».

• readme — где подробно описывается проект, чтобы другим пользователям было проще понять , что вы разрабатываете;
• license — позволяет защитить ваши права разработчика;
• и др.

Как перенести облачный репозиторий на компьютер

• скачать и установить программу под вашу операционную систему;
• активировать приложение и пройти авторизацию: указать свой e-mail и информацию ГитХаб-аккаунта.

• создать новый репозиторий;
• загрузить папку из компьютера в программу;
• осуществить клонирование существующих репозиториев на компьютер.

• Current Repository — позволяет взаимодействовать с несколькими репозиториями, а также следить за изменениями, которые не были еще внесены в код;
• Current Branch — дает возможность взаимодействовать с разными ветками одного проекта;
• Fetch Origin — отвечает за синхронизацию файлов в локальном и облачном репозитории.

Как залить код на GitHub через локальный репозиторий

Открывайте любую программу для работы с кодом, например , Atom, Visual Studio Code и др. В этой программе открывайте проект, который находится в вашем компьютере. Можете работать с проектом в привычном режиме: корректировать созданные файлы или создавать новые.

Потом открываете программу GitHub Desktop. Все изменения, которые вы внесли в свой проект , появятся в разделе «Changes». Можно написать коммит, можно перейти в раздел «History», чтобы просмотреть все изменения. Если все «Ок», тогда нужно нажать на «Push Origin» , и все изменения отправятся в облачный репозиторий на GitHub.

Заключение

При помощи программы GitHub Desktop можно эффективно управлять своими проектами на ГитХабе, создавая новые репозит о рии, новые ветки в проекте, внося изменения в проект прямо в компьютере и при этом не посещая сам ресурс.

Теперь вы знаете, как залить код на GitHub при помощи программы, которую нужно установить на компьютер. Если не хотите использовать эту программу, можно залить код на ГитХаб прямо в самом аккаунте. Для этого также нужно будет создать новый репозиторий вашего проекта и перенести туда «руками» код вашей программы.

Правильный подход к разработке личного проекта и его публикации на GitHub

Перевод статьи «The Right Way to Develop your Side Project on GitHub».

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

Почему именно на GitHub? GitHub это фактический стандарт для open-source-проектов. Там вы можете поделиться своим кодом с другими пользователями и найти единомышленников, которые захотят принять участие в вашем проекте. Кроме того, GitHub обладает определенным функционалом, способным существенно помочь разработчикам: Pull Request, Actions, Packages.

Найдите подходящую идею

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

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

Выберите технологический стек

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

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

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

Создайте файлы с README и лицензией

Окей, вы нашли подходящую идею и выбрали любимый стек технологий. Давайте настроим на GitHub новый репозиторий для вашего приложения. Пора поговорить о двух главных файлах в этом репозитории: README и LICENSE.

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

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

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

Также будет удобно завести себе файл .gitignore, чтобы случайно не закоммитить в репозиторий ненужные файлы.

Создайте приложение Hello World и настройте GitHub Actions

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

Для существующего приложения Hello World будет проще создать GitHub Actions.

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

Как настроить GitHub Actions? Я уверен, что вы сможете справиться с этим самостоятельно. Поищите инструкцию в гугле и изучите ее, потому что подобные вещи это часть вашей работы;)

Проверка правильности вашего приложения

Что нужно сделать, чтобы верифицировать корректность приложения? Как минимум, две вещи:

1. Проверить ваш исходный код на синтаксические ошибки.
2. Запустить юнит-тесты и проверить, делают ли функции приложения то, что должны делать по плану (и нет ли багов при этом).

И еще кое-что. Если чувствуете себя в достаточной мере профессионалом, можете устроить еще пару проверок:

1. Статический анализ. Проверьте, соблюден ли установленный стиль написания кода, нет ли уязвимостей в безопасности.
2. Покрытие кода тестами. Проверьте, какая часть кода запускается юнит-тестами. Эта проверка будет провалена, если покрытие не дотягивает до установленного процента. Лучше всего, чтобы тестами было покрыто как минимум 80% кода. То есть, на 100 строк кода юнит-тесты должны запускать как минимум 80.

Автоматизируйте сборку пакета приложения

Написав минимально рабочее приложение, можно перейти к сборке пакета. Какой пакет это должен быть? Для сервисов это будет образ Docker, который вы можете запушить в GitHub Packages. Для CLI и прочих инструментов это будет запускаемый бинарный файл, который вы сможете приложить к GitHub Release assets.

После завершения каждой существенной функции публикуйте новый релиз на GitHub. Настройте еще один GitHub Action, который будет запускаться по тегу release и собирать пакеты приложения.

Постепенно дело дойдет до деплоймента приложения. Если вы используете Docker, напишите скрипт, который будет забирать последний образ Docker на ваш сервер.

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

Управление задачами в вашем проекте

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

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

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

Запишите где-нибудь все эти задачи и оцените их важность, а затем рассортируйте в порядке приоритетности. Поместите задачи в файл README или в ваш любимый to-do-список. Можно для каждой задачи создать issue на GitHub.

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

Пора браться за дело!

Наконец, можно приступить к разработке приложения. Я совету пользоваться следующим подходом:

1. Возьмите задачу с наивысшим приоритетом.
2. Создайте для этой задачи ветку в git.
3. Реализуйте решение задачи.
4. Напишите несколько юнит-тестов (если не практикуете разработку через тестирование).
5. Сделайте пуш этой ветки на GitHub.
6. Откройте пул-реквест на GitHub.
7. Подождите, пока GitHub Action соберет ваш коммит. Если сборка не удастся, вам придется исправить свой код и затем собрать его снова.
8. Если сборка прошла нормально и все «позеленело», можно сделать merge этого пул-реквеста.
9. Опубликуйте релиз, подождите, пока GitHub Action соберет пакеты приложения.
10. Выполните деплоймент приложения.

После каждой реализованной задачи у вас должно оставаться развернутое где-нибудь корректно работающее приложение.

Давайте еще раз пробежимся по самым полезным советам:

1. Найдите интересную для вас идею приложения.
2. Напишите подробный файл README, в котором будет описание проекта, гайд по установке и руководство пользователя.
3. Выберите лицензию для своего открытого кода и создайте соответствующий файл.
4. Напишите минимально рабочее приложение и настройте для него среду разработки.
5. Используйте GitHub Actions для автоматизации сборки.
6. Спроектируйте архитектуру приложения и нарисуйте ее схему.
7. Составьте план задач, расставьте их в порядке приоритетности.
8. Делайте деплоймент приложения после каждой реализованной задачи.
9. Пользуйтесь своим приложением сами.

Вот и все! Не останавливайтесь и непрерывно улучшайте свое приложение!

Источник: techrocks.ru