Websites for you and your projects

Английские слова. Методы и способы запоминания

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

Step 2. Create a Branch

Branching is the way to work on different versions of a repository at one time.

By default your repository has one branch named which is considered to be the definitive branch. We use branches to experiment and make edits before committing them to .

When you create a branch off the branch, you’re making a copy, or snapshot, of as it was at that point in time. If someone else made changes to the branch while you were working on your branch, you could pull in those updates.

This diagram shows:

• The branch
• A new branch called (because we’re doing ‘feature work’ on this branch)
• The journey that takes before it’s merged into

Have you ever saved different versions of a file? Something like:

Branches accomplish similar goals in GitHub repositories.

Here at GitHub, our developers, writers, and designers use branches for keeping bug fixes and feature work separate from our (production) branch. When a change is ready, they merge their branch into .

To create a new branch

1. Go to your new repository .
2. Click the drop down at the top of the file list that says branch: main.
3. Type a branch name, , into the new branch text box.
4. Select the blue Create branch box or hit “Enter” on your keyboard.

Now you have two branches, and . They look exactly the same, but not for long! Next we’ll add our changes to the new branch.

git fetch и git pull — забираем изменения из центрального репозитория

Для синхронизации текущей ветки с репозиторием используются команды git fetch
и git pull.

git fetch — забирает изменения удаленной ветки из репозитория по умолчания,
основной ветки; той, которая была использована при клонировании репозитория.
Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет
провести слияние с локальной ветку командой git merge.

Получает изменений из определенного репозитория:

Возможно также использовать синонимы для адресов, создаваемые командой git remote:

Естественно, что после оценки изменений, например, командой git diff, надо
создать коммит слияния с основной:

Команда git pull сразу забирает изменения и проводит слияние с активной веткой.
Забирает из репозитория, для которого были созданы удаленные ветки по умолчанию:

Забирает изменения и метки из определенного репозитория:

Как правило, используется сразу команда git pull.

Step 3. Make and commit changes

Bravo! Now, you’re on the code view for your branch, which is a copy of . Let’s make some edits.

On GitHub, saved changes are called commits. Each commit has an associated commit message, which is a description explaining why a particular change was made. Commit messages capture the history of your changes, so other contributors can understand what you’ve done and why.

Make and commit changes

1. Click the file.
2. Click the pencil icon in the upper right corner of the file view to edit.
3. In the editor, write a bit about yourself.
4. Write a commit message that describes your changes.
5. Click Commit changes button.

These changes will be made to just the README file on your branch, so now this branch contains content that’s different from .

Устанавливаем SSH-ключи

Git установлен, профиль на GitHub создан. Осталось добавить SSH-ключ и можно приступать к работе с проектом.

Что такое SSH-ключ и зачем он нужен?

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

Каждый SSH-ключ содержит пару: открытый (публичный) и закрытый (приватный) ключ. Открытый ключ отправляется на сервер, его можно не прятать от всех и не переживать, что кто-то его увидит и украдёт. Он бесполезен без своей пары — закрытого ключа. А вот закрытый ключ — секретная часть. Доступ к нему должен быть только у вас.

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

Чтобы пройти авторизацию по SSH-ключу, его надо сгенерировать или найти уже ранее созданный ключ на своём компьютере.

Сначала проверим, есть ли уже на компьютере ключ. По умолчанию SSH-ключи хранятся в каталоге , поэтому нужно проверить содержимое этого каталога.

1. Открываем консоль.

2. Вводим , чтобы перейти в нужный каталог.

   Переходим в нужную директорию.

3. Используем , чтобы увидеть список всех файлов в каталоге.

   Открываем список файлов в директории.

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

   • Открываем консоль и вводим команду:

     ssh-keygen -t rsa -b 4096 -C "your_mail@example.com"

     Указываем тот адрес электронной почты, который вводили при регистрации на GitHub.

     Генерируем ключ.

   • Далее нужно указать расположение файла для сохранения ключа. Если вы не введёте путь до файла и просто нажмёте Enter, ключ сохранится в файле, указанном в скобках.

   • Теперь нужно установить пароль к вашему ключу и дважды ввести его. Если вы не хотите вводить пароль каждый раз, когда используете ключ, пропустите этот шаг, нажав «Enter», и ничего не вводите.

     Указываем расположение ключа и вводим пароль.

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

   Добавляем ключ в shh-agent. Несколько важных примечаний:

   • Если вы захотите переименовать ключ, могут возникнуть проблемы. Их можно решить, добавив в связь ключа с доменом.
   • Если у вас Windows и вы пользуетесь программой Cmder, возможны проблемы с командой . Может появиться такое сообщение об ошибке:
     «eval не является внутренней или внешней командой, исполняемой программой или пакетным файлом».

     В Сmder для запуска можно использовать команду .

     Если проблема осталась, рекомендуем работать в Git Bash.

   • Если у вас macOS Sierra версии 10.12.2 и выше, нужно изменить ваш файл, чтобы автоматически загрузить ключи в и хранить пароли.

     Host *
      AddKeysToAgent yes
      UseKeychain yes
      IdentityFile ~/.ssh/id_rsa

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

   • Если у вас Linux, может понадобится переназначить для ~/.ssh права доступа командой
5. После того как создан ключ, его нужно добавить на GitHub. Для этого копируем его содержимое с помощью одной из следующих команд:
   • Если вы на Windows
   • Для пользователей macOS
   • На Linux используйте , чтобы установить необходимый для копирования пакет , а затем введите

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

6. Переходим на страницу для работы с ключами в вашем профиле на GitHub.

   Страница с настройками ключей в вашем профиле.

   Нажимаем кнопку New SSH key (новый SSH-ключ). Вводим имя ключа (можно придумать абсолютно любое) в поле Title (название), а в Key (ключ) вставляем сам ключ из буфера обмена. Теперь нажимаем Add SSH key (добавить SSH-ключ).

   Добавляем в свой профиль SSH-ключ.

   Если всё сделано верно, в списке появится новый ключ.

   Успешно добавленный ключ.

Теперь, наконец-то, мы можем начать работу с самим проектом.

Installation

Fork the repo

You’ll be making your own copy of the «personal website starter» repository so you have your own project to customize. A «fork» is a copy of a repository. So select «Fork» atop the repository.

Once you’ve found a home for your forked repository, it’s yours. You’re the owner, so you’re ready to publish, if you wish.

Install in your local development environment

Once you’ve found a home for your forked repository, clone it.

Install Jekyll

1. Change into your new directory

1. Install missing gems

1. Build the site and make it available on a local server

You should see something like:

Don’t worry about the «No GitHub API authentication could be found» message. API authentication is only necessary if you intend to display more detailed metadata, like a branch name.

Publish

When you host your personal website’s code on GitHub, you get the support of free hosting through GitHub Pages.

The fastest approach is to rename your repository , where is your GitHub username (or organization name). Then, the next time you push any changes to your repository’s branch, they’ll be accessible on the web at your address.

If you want to use a custom domain, you’ll want to add it to your repository’s «Custom domain» settings on github.com. And then register and/or configure your domain with a DNS provider.

Как участвовать в проекте с открытым исходным кодом и получать деньги?

Tutorial

Здравствуй Хабрахабр!
Многие команды разработчиков участвую в конкурсах и акселераторах. Выигрывают призы или получают финансирование.
Что делать, если вы не успели сесть в проходящий поезд?
Есть несколько вариантов. Один из них это начать свой проект и ждать когда он взлетит, при этом тратить время на создание кода и рекламу проекта в конкурсах, акселераторах, переговорах с инвесторами. В случае успеха надо находить специалистов поднимать инфраструктуру. Ряд виртуальных или реальных серверов для сайта, программистов, базы данных, клиентов. В итоге, многие проекты так и не взлетев попадают на GitHub и другие подобные ресурсы.

Step 4. Open a Pull Request

Nice edits! Now that you have changes in a branch off of , you can open a pull request.

Pull Requests are the heart of collaboration on GitHub. When you open a pull request, you’re proposing your changes and requesting that someone review and pull in your contribution and merge them into their branch. Pull requests show diffs, or differences, of the content from both branches. The changes, additions, and subtractions are shown in green and red.

As soon as you make a commit, you can open a pull request and start a discussion, even before the code is finished.

By using GitHub’s in your pull request message, you can ask for feedback from specific people or teams, whether they’re down the hall or 10 time zones away.

You can even open pull requests in your own repository and merge them yourself. It’s a great way to learn the GitHub flow before working on larger projects.

Open a Pull Request for changes to the README

Click on the image for a larger version

Step	Screenshot
Click the Pull Request tab, then from the Pull Request page, click the green New pull request button.
In the Example Comparisons box, select the branch you made, , to compare with (the original).
Look over your changes in the diffs on the Compare page, make sure they’re what you want to submit.
When you’re satisfied that these are the changes you want to submit, click the big green Create Pull Request button.
Give your pull request a title and write a brief description of your changes.

When you’re done with your message, click Create pull request!

Прочие команды и необходимые возможности

Хэш — уникальная идентификация объектов

В git для идентификации любых объектов используется уникальный (то есть с
огромной вероятностью уникальный) хэш из 40 символов, который определяется
хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты,
файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла,
то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки
в сорок символов.

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

Ищет разницу текущего состояния проекта и коммита за номером… сами видите,
каким:

То же самое, но оставляем только шесть первых символов. Git поймет, о каком
коммите идет речь, если не существует другого коммита с таким началом хэша:

Иногда хватает и четырех символов:

Читает лог с коммита по коммит:

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

git tag — тэги как способ пометить уникальный коммит

Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит,
имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик
может оставлять на таких тегах собственную цифровую подпись.

Кроме этого в git представленные так называемые «легковесные тэги» (lightweight
tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило,
используются для упрощения навигации по дереву истории; создать их очень легко.

Создаёт «легковесный» тэг, связанный с последним коммитом; если тэг уже есть,
то еще один создан не будет:

Помечает определенный коммит:

Удаляет тег:

Перечисляет тэги:

Создаёт тэг для последнего коммита, заменяет существующий, если таковой уже был:

После создания тэга его имя можно использовать вместо хэша в любых командах
вроде git diff, git log и так далее:

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

Создаёт обычный тэг для последнего коммита; будет вызван текстовый редактор для
составления комментария:

Создаёт обычный тэг, сразу указав в качестве аргумента комментарий:

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

Относительная адресация

Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один
механизм — относительную адресацию. Например, можно обратиться прямо к предку
последнего коммита ветки master:

Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам
коммитов слияния:

Ищет изменения по сравнению со вторым предком последнего коммита в master; HEAD
здесь — указатель на последний коммит активной ветки.

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

Что привнес «дедушка» нынешнего коммита:

То же самое:

Обозначения можно объединять, чтобы добраться до нужного коммита:

Файл .gitignore — объясняем git, какие файлы следует игнорировать

Иногда по директориям проекта встречаются файлы, которые не хочется постоянно
видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов,
временные файлы и прочий мусор.

Заставить git status игнорировать определенные файлы можно, создав в корне или
глубже по дереву (если ограничения должны быть только в определенных директория)
файл .gitignore. В этих файлах можно описывать шаблоны игнорируемых файлов
определенного формата.

Пример содержимого такого файла:

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

Серверные команды репозитория

Команда создания вспомогательных файлов для dumb-сервера в $GIT_DIR/info и
$GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки
и пакеты есть на сервере:

Проверяет сколько объектов будет потеряно и объём освобождаемого места при
перепаковке репозитория:

Переупаковывает локальный репозиторий:

Статьи — это тоже исходный код {

Открываю VS Code и начинаю набирать статью с самого начала. Но вот незадача — формат маркдауна не совсем совместим с имеющимся форматом Хабра. Получается выхода нет и придётся возвращаться к встроенному редактору Хабра;

В голову пришла идея написать утилиту, которая конвертирует разные форматы маркдаунов друг в друга, например, из формата GitHub в формат Habr;

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

Это дало бы немало новых возможностей, которыми пользуются программисты: версионирование, бекапы на локальные носители или веб-сервисы, правки от редакторов и пользователей. А еще можно внедрить CD/CI;

Добавляем и изменяем файлы

Теперь давайте создадим в нашей папке новый текстовый документ с сообщением “Hello world!”.

Если мы откроем GitHub Desktop, мы увидим что наш файл увидела система и пометила как добавление новгго файла, отметив зеленым плюсом. Справа отобразив что именно сделали с файлом: зеленым выделены добавленные фрагменты.

Теперь мы готовы сделать свой первый коммит (commit). По факту это фраза означает внесения изменения в текущую ветку в локальном репозитории. Чтобы это сделать, нужно написать краткое сообщение, отражающее суть изменений, чтобы потом было проще в них ориентироваться. В данном случае мы добавили новый текстовый файл (сообщение может быть на любом языке, необязательно на английском). Github сам нам подсказал название коммита. Так же мы можем добавить описание изменений, чтобы другим пользователям было проще.

Когда мы готовы сделать коммит, нажимаем кнопку Commit to master. Это означает сделать коммит в локальную ветку master, про сами ветки расскажем чуть позже. Но мы сделали только коммит, теперь нужно чтобы изменились файлы в удаленном репозитории, то есть синхронизировать локальную и удалённую ветки master. Для этого нажимаем кнопку сверху Push origin.

Если все прошло успешно, и изменения запушились в удаленный репозиторий, то, обновив его страницу на GitHub, мы увидим новый файл hello world.txt.

Поверьте, адекватные описания коммитов — это очень важно!

Теперь давайте создадим файл на GitHub и скопируем его в локальный репозиторий. Нажимаем кнопку Create new file и называем его newfile.

Осталось “прописать” коммит и сделать его, нажав Commit new file:

Откроем GitHub Desktop и обнаружим, что система сама определила, что произошел внешний коммит и наши файлы нужно обновить. Если изменений не видно, нажмите F5 или перезапустите приложение. Нажмём на Pull origin и скачаем файлы в свой локальный репозиторий:

Несколько советов о том, как ускорить сборку Docker-образов. Например, до 30 секунд

Прежде чем фича попадет на прод, в наше время сложных оркестраторов и CI/CD предстоит пройти долгий путь от коммита до тестов и доставки. Раньше можно было кинуть новые файлы по FTP (так больше никто не делает, верно?), и процесс «деплоя» занимал секунды. Теперь же надо создать merge request и ждать немалое время, пока фича доберётся до пользователей.

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

Делаем нейронную сеть, которая сможет отличить борщ от пельмешек

Как то раз смотря видос про достижения Поднебесной, я увидел прикольную штуку. Столовую будущего, точнее для Китая настоящего, а для нас будущего. Суть заключалась в полном самообслуживание клиента. Он брал блюда на поднос и подносил поднос к видео камере где нейросетка детектировала и распознавала еду, выставляла ему счет и он через еще одну нейронную сеть, которая распознавала его лицо, оплачивал свою покупку. Мне тоже захотелось сделать что то подобное. Размечать датасет под YOLO, что бы можно было детектировать блюда мне было совсем не охото. Готово размеченного с борщами и пельмешками я не нашел, поэтому решил сделать только классификацию.

Используйте Github-шаблоны для pull request’ов и задач

ПодробнееОсновные советы по отчётам о багах

• Удостоверьтесь, что пользуетесь последней версией.
• Поищите упоминание об этом баге, возможно, отчёт о нём уже был раньше.

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

Общие рекомендации по pull request’ам

• Проверьте, что по вашей проблеме ещё нет других pull request’ов.
• Проверьте в баг-трекере, не было ли проблем, связанных с вашим багом.
• Нетривиальные изменения лучше предварительно обсудить.
• Сообщите нам, над какой задачей работаете.
• Разрабатывайте в конкретной тематической ветке, а не в мастере.
• Напишите описание полезного pull request’а.
• Соблюдайте рекомендации по коммитам в проекте.
• Напишите хорошее описание своего pull request’а.
• Укажите в описании ссылку на Github-задачу.

Fork репозитория

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

В чем же отличие от клонирования репозитория? При клонировании мы только используем файлы оригинального репозитория и при создании коммита с какими-то изменениями, GitHub Desktop скажет нам, что у нас нет доступа на запись и сам предложит сделать форк. (Если доступ к этому репозиторию у нас есть, то сделать коммит мы сможем.) А если мы сделали форк, то изменения уйдут в нашу копию в нашем аккаунте.

Fork может быть полезен при разработки открытого ПО, например, мы сделали форк алгоритма сжатия, в нем мы изменили функцию сжатия и теперь алгоримт сжимает в 10 раз лучше. Мы можем сделать Pull request, т.е. запросить у хозяина оригинального репозитория с алгоритмом сжатия, интегрировать наши изменения в его репозиторий.

Еще мои статьи

• Debug в Intellij IDEA: гайд для новичков
• Гайд по созданию клиента для Skyscanner API и его публикации в jCenter и Maven Central
• Гайд по созданию клиента для Skyscanner API и его публикации в jCenter и Maven Central
• Создание системы мониторинга цен на авиабилеты: пошаговое руководство
• Создание системы мониторинга цен на авиабилеты: пошаговое руководство
• Создание системы мониторинга цен на авиабилеты: пошаговое руководство
• Логирование: что, как, где и чем?
• Как тестовое задание на собеседование превратилось в open-source библиотеку
• История Успеха. 20 часов программирования в неделю, магистратура и личная жизнь
• Как найти работу? Советы по рассылке резюме

Подключите локальную папку проекта к вашему пустому хранилищу на Github

Сейчас на сайте github вы видите страницу у которой в заголовке написано: «Quick setup — if you’ve done this kind of thing before».

Скопируйте ссылку в поле формы (input) прямо под заголовком, она должна выглядеть примерно так:

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

1. Вернитесь к своему проекту в терминале / командной строке.

2. В вашем терминале / командной строке введите:

Наш пример:

3. Отправьте (сделайте пуш, push) вашей ветки в Github:

4. Вернитесь к экрану репозитория на Github, который вы только что оставили, и обновите его. Название «Quick setup — if you’ve done this kind of thing before». Название должно исчезнуть, и вы должны увидеть свои файлы в репозитории.

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

Step 1. Create a Repository

A repository is usually used to organize a single project. Repositories can contain folders and files, images, videos, spreadsheets, and data sets – anything your project needs. We recommend including a README, or a file with information about your project. GitHub makes it easy to add one at the same time you create your new repository. It also offers other common options such as a license file.

Your repository can be a place where you store ideas, resources, or even share and discuss things with others.

To create a new repository

1. In the upper right corner, next to your avatar or identicon, click and then select New repository.
2. Name your repository .
3. Write a short description.
4. Select Initialize this repository with a README.

Click Create repository.

Microsoft понадобилось 10 дней, чтобы удалить исходники Windows XP с принадлежащего им GitHub

В исходниках Windows XP нашли секретную тему в стиле Mac
В сентябре вся индустрия всполошилась после новости об утечке исходных кодов Windows XP и Windows Server 2003. Новость оказалась не фейком. Исходные коды настоящие, и из них скомпилировали рабочие версии обеих ОС.
Напомним, что всё началось 24 сентября: на портале 4chan неизвестные выложили торрент на 42,9 ГБ с полными исходниками Windows XP и Windows Server 2003. Хотя сегодня под XP работает меньше 1% компьютеров в мире, а разработчик не обеспечивает никакой поддержки, утечка исходников всё равно вызвала лёгкую эйфорию среди программистов. Ведь мы много лет гадали, как реализованы те или иные функции или API, а теперь можно посмотреть на код своими глазами.
Так или иначе, Microsoft мгновенно начала войну. Уже на следующий день исходники стали удалять везде, где только можно.

Регистрация на GitHub

Что такое GitHub?

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

Чтобы начать работу с GitHub, нужно зарегистрироваться на сайте, если вы ещё этого не сделали. За дело.

1. Переходим на сайт GitHub.

   Cтартовая страница GitHub.

2. Для начала регистрации:

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

     Первый шаг регистрации профиля на стартовой странице GitHub.

   • После заполнения данных и успешного прохождения верификации нажимаем на кнопку Select a plan.

     Второй шаг регистрации профиля на стартовой странице GitHub.

3. Третий шаг — небольшой опрос от GitHub, который вы можете пройти, заполнив все поля и нажать Submit или пропустить, нажав skip this step.

   Опрос на третьем шаге регистрации.

4. После прохождения всех этапов на сайте, на указанный при регистрации ящик вам придёт письмо от GitHub. Откройте его и подтвердите свой почтовый адрес, нажав Verify email address (подтвердить электронный адрес) или скопируйте вспомогательную ссылку из письма и вставьте её в адресную строку браузера.

   Подтверждение электронного адреса.

5. После верификации GitHub предложит создать новый репозиторий, организацию или узнать больше о GitHub. Этот пункт пока можно пропустить и перейти в профиль.

   Переход в ваш профиль.
   Так выглядит ваш профиль после регистрации.

Теперь у вас есть профиль на GitHub.