Как пользоваться github

Step 11: Bask in your git glory

You’ve successfully made a PR and merged your code to the primary branch. Congratulations! If you’d like to dive deeper, check out these more advanced tutorials and resources:

• https://training.github.com/Github’s official git cheat sheets! Handy for remembering the everyday commands you’ll use. 
• https://learngitbranching.js.org/Confused or intrigued by git’s branch system? That just means you’re human! It’s one of the deepest parts of git, but also arguably the most powerful. Understanding the branch model gives you git superpowers, and this tutorial gives you a way to learn git branches in a visual, intuitive way.
• Another tool for exploring git visually. This one is more of an open-ended sandbox than learngitbranching.js.org
• A desktop application that helps you learn git through challenges you have to solve. It has a series of levels, each requiring you to use git commands to arrive at a correct answer.
• https://github.com/Gazler/githugIf you liked git-it, Githug is another puzzle-based tutorial designed to give you a practical way of learning git.

I also recommend finding some time to work with your team on simulating a smaller group project like we did here. Have your team make a new folder with your team name, and add some files with text to it. Then, try pushing those changes to this remote repo. That way, your team can start making changes to files they didn’t originally create and practice using the PR feature. And, use the git blame and git history tools on GitHub to get familiar with tracking which changes have been made in a file and who made those changes. 

The more you use git, the more comfortable you’ll… git with it. (I couldn’t resist.)

*This post was originally published in October 2015 by Meghan Nelson, then a senior software engineer at HubSpot. It has since been updated by the HubSpot Product Team.

Получаем доступ к репозиторию

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

1. Регистрация на GitHub’e.

Профиль на GitHub.com

2. Генерируем ключ для доступа по SSH.
Вот тут хочешь-не хочешь, а надо запускать консоль. После установки msysgit у Вас на рабочем столе появился новый ярлык – Git Bush – вот с помощью него и запускаем консоль.

1. Набираем в консоли следующую команду
2. На экране появится запрос “Enter file in which to save the key”. Пока оставим значение по умолчанию. Жмем Enter.
3. Нас попросят ввести пароль. Эту часть тоже пропускаем – впоследствии пароль можно будет установить, а пока – учимся. Жмем опять Enter.
4. Сгенерируются два файла один из которых – публичный ключ для доступа.

Если Вы все делали с настройками по умолчанию то файлы будут располагаться в директории:

Заходим в директорию, открываем с помощью “Блокнота” файл ida_rsa.pub и копируем все его содержимое в буфер обмена.

3. Заносим публичный ключ доступа в профиль.

Для записи публичного ключа в профиль:

1. Заходим в свой профиль github и жмем ссылку Account Settings (сверху)
2. Выбираем пункт “SSH Public Keys”
3. Жмем ссылку “Add another public key”

Перед вами появится форма добавления нового публичного ключа. Вставляем из буфере весь скопированный ранее текст (из файла ida_rsa.pub) только в поле key – поле Title оставляем пустым.

На этом работа с публичными ключами закончена.

4. Просимся в проект.

DevOps with GitHub

Continuous integration with CircleCI

Learn how to automatically test changes made to your project, freeing you up to write more amazing code.

Continuous Integration

Continuous integration with Travis CI

Learn about the principles of continuous integration with GitHub and Travis CI.

continuous integration (CI)

test-driven development (TDD)

YAML

protected branches

commit status

Getting started with GitHub Apps

Add your own GitHub feature, automate workflows, and more with GitHub Apps.

webhooks

API

GitHub Apps

Probot

Installing

CodeQL U-Boot Challenge (C/C++)

Learn to use CodeQL, a query language that helps find bugs in source code. Find 9 remote code execution vulnerabilities in the open-source project Das U-Boot, and join the growing community of security researchers using CodeQL.

Я не знаю, что вы только что сказали (Вариант 2)

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

Давайте сделаем это!

Скажем, вы хотите создать новый репозиторий. (Вероятно, так и есть! Именно здесь будет жить ваш проект. Если вы не собираетесь создавать новый репозиторий, вы, вероятно, захотите клонировать существующий репозиторий. Мы поговорим об этом позже, но именно так вы получаете чужой проект и информация, которая вам нужна для вашей работы или курса, который вы выбираете.)

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

Это хорошая идея, чтобы включитьПРОЧТИ МЕНЯфайл с информацией о вашем проекте. Вы можете создать один в то же время, когда вы создаете свой репозиторий, щелкнув флажок.

• Перейдите на веб-сайт GitHub, посмотрите в верхнем правом углу, нажмите знак +, а затем нажмите «Новый репозиторий».
• Назовите репозиторий и добавьте краткое описание.
• Решите, хотите ли вы, чтобы это был публичный или частный репозиторий
• Нажмите «Инициализировать этот репозиторий с помощью README», если вы хотите включить файл README. (Я определенно рекомендую сделать это! Это первое, на что люди обратятся, когда проверят ваш репозиторий. Это также отличное место для размещения информации, которая вам необходима, чтобы понять или запустить проект.)

Новый репозиторий
Создание вашего нового хранилища

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

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

Допустим, вы хотите внести некоторые изменения в свой файл README прямо на GitHub.

• Сначала зайдите в свой репозиторий.
• Нажмите на имя файла, чтобы вызвать этот файл (например, нажмите «README.md», чтобы перейти к файлу readme).
• Нажмите значок карандаша в верхнем правом углу файла и внесите некоторые изменения.
• Напишите короткое сообщение в поле, которое описывает сделанные вами изменения (и расширенное описание, если хотите).
• Нажмите кнопку «Подтвердить изменения»

Редактирование вашего файла на GitHub
Передача ваших изменений

Теперь изменения были внесены в файл README в вашем новом хранилище! (Я хочу обратить ваше внимание на маленькую кнопку, которую вы можете отметить на изображении выше, которая позволит вам создать новую ветку для этого коммита и запустить запрос на извлечение. Мы поговорим об этом позже!). Довольно легко, правда?

Довольно легко, правда?

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

Git GUI

Входит в комплект git — Запустите из командной строки, а установщик Windows msysgit добавит его в меню «Пуск».

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

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

Это не самое приятное приложение, но оно работает практически на всех платформах (основано на Tcl/Tk)

Screenshots | скринкаст

Enterprise on GitHub

InnerSource fundamentals

Organizations of all sizes and in all industries are chatting about InnerSource concepts. This course walks you through some of the key concepts of InnerSource and helps you build up an internal toolkit for adopting InnerSource practices.

Create an open source program

Learn how to work alongside the open source communities that build software you’re already using, and put your business at the forefront of the world’s most innovative and secure code.

Open source

Enterprise

Licensing

Templates

Guidelines

Create a release based workflow

Learn and practice a release-based workflow and explore branching strategies.

Protected branches

Kanban

Semantic versioning

Projects

GitHub Apps

GitX

Предназначен для «клонирования gitk для OS X».

Он может визуализировать нелинейную историю ветвления, выполнять коммиты, просматривать и выполнять поиск, а также имеет некоторые другие приятные функции, такие как возможность «Quicklook» любого файла в любой редакции (нажмите пробел в представлении списка файлов) экспортировать любой файл (с помощью перетаскивания).

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

Оригинальный репозиторий git pieter не обновлялся недавно (более года на момент написания). Более активно поддерживаемая ветвь доступна в brotherbard/gitx — она ​​добавляет «боковую панель, выборку, вытягивание, толчок, добавление удаленного, слияния, выбирать, переустанавливать, клонировать, клонировать до»

Загрузить | Скриншоты | Git репозиторий | вилка для брата | laullon fork

Отслеживайте хаки локальные изменения в обход репозитория

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

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

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

Что только что сейчас произошло? Мистическим образом у нас оказалось два репозитория в одной папке, а значит и возможность вести параллельную историю файлов! Почему ? Да для единообразия. Давайте заведём себе алиас, чтобы упростить работу со вторым репозиторием:

Пробуем:

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

Игнорировать у гита заложено в генах, а вот всё остальное, как мы видим, отображается как есть. Наибольшая проблема — у них будет один на двоих, так что практически всё, что может потребоваться во втором репозитории, придётся добавлять через , а всё что не требуется — не забываем игнорировать через . По умолчанию можно добавить следующие строчки:

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

Вариант 2. Я вообще ничего не знаю

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

Ну что ж, приступим к делу!

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

Репозиторий — это место, в котором вы систематизируете свой проект. Здесь вы храните файлы, папки, видео, изображения, блокноты Jupyter Notebook, наборы данных и т.д. Перед началом работы с Git необходимо инициализировать репозиторий для проекта и правильно его подготовить. Это можно сделать на сайте GitHub.

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

Перейдите на сайт GitHub. Нажмите на значок + в верхнем правом углу, а затем выберите New repository.
Придумайте имя репозитория и добавьте короткое описание.
Решите, будет ли этот репозиторий размещаться в открытом доступе или останется закрытым для просмотра.
Нажмите Initialize this repository with a README для добавления README-файла

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

Новый репозиторий

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

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

Вносить изменения в проект можно двумя способами. Вы можете изменять файлы/блокноты на компьютере либо делать это на сайте GitHub.

Допустим, вам захотелось подкорректировать README-файл на сайте GitHub.

• Для начала перейдите в ваш репозиторий.
• Для выбора файла кликните по его названию (например, кликните по README.md для перехода к файлу-описанию).
• В верхнем правом углу вы увидите иконку с карандашом. Нажмите на нее для внесения изменений.
• Напишите короткое сообщение, передающее суть изменений (и подробное описание, если сочтете это нужным).
• Нажмите кнопку Commit changes.

Изменение файла на GitHub

Подготовка коммита с изменениями

Вы успешно внесли изменения в README-файл своего нового репозитория! Обратите внимание на небольшую кнопку на картинке выше. Она позволяет создавать новую ветку этого коммита и добавлять Pull request

Запомните ее, скоро к ней вернемся.

Как вы видите — ничего сложного!

Лично я предпочитаю работать с файлами на локальном компьютере, а не на сайте GitHub. Поэтому давайте научимся и этому.

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

Теперь давайте создадим в нашей папке новый текстовый документ с сообщением “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 и скачаем файлы в свой локальный репозиторий:

Commit message

Написать хороший заголовок лучше чем ничего (то есть плохой заголовок). Но если в проекте много участников, сформировалась значительная кодовая база и проект планируется поддерживать еще долгое время (больше полугода). То нужно писать и тело commit message.

Основное правило — не нужно писать, что делает коммит, нужно писать, для чего он это делает. То есть если это фикс бага — конкретно о том, что это фикс бага будет указано в заголовке. А в теле коммита нужно поподробнее описать, что это за баг, когда он проявляется и, самое главное, почему ваши правки в коде этот баг исправляют.

Ссылки не должны заменять текст коммита. Если баг описан в жире, то вместо того, чтобы просто вставлять ссылку на жиру, надо кратко пересказать, что там написано, прямо в теле commit message.

По оформлению: не следует писать все в одну строку, желательно переносить по границе 72 символов. Так же следует использовать повелительное наклонение в предложениях, где описано, что делает этот коммит.

Пример хорошего commit message (из проекта libvirt):

Качаем и устанавливаем софт

1. msysgit – качаем Git For Windows
2. TortoiseGit. На момент написания статьи последней была версия (19.6 MB). Новые версии Вы можете найти также по приведенной ссылке.

Получается, что скачать нам надо чуть больше 30 Mb.
Теперь устанавливаем скачанные программы.

Вначале ставим msysgit, а потом TortoiseGit.

При установке msysgit настройки по умолчанию можно не изменять.
При установке TortoiseGit выбираем в окне “Choose SSH Client” второе значение:
После успешной установки обоих продуктов работу над первым этапом можно считать завершенной. Приступим ко второму – получение доступа к репозиторию Git.

Step 1: Create a local git repository

When creating a new project on your local machine using git, you’ll first create a new repository (or often, ‘repo’, for short). 

To use git we’ll be using the terminal. If you don’t have much experience with the terminal and basic commands, (If you don’t want/ need a short history lesson, skip to step three.)

To begin, open up a terminal and move to where you want to place the project on your local machine using the cd (change directory) command. For example, if you have a ‘projects’ folder on your desktop, you’d do something like:

To initialize a git repository in the root of the folder, run the git init command: 

Step 2: Add a new file to the repo

Go ahead and add a new file to the project, using any text editor you like or running a touch command. `touch newfile.txt` just creates and saves a blank file named newfile.txt. 

Once you’ve added or modified files in a folder containing a git repo, git will notice that  the file exists inside the repo. But, git won’t track the file unless you explicitly tell it to. Git only saves/manages changes to files that it tracks, so we’ll need to send a command to confirm that yes, we want git to track our new file.

After creating the new file, you can use the git status command to see which files git knows exist.

What this basically says is, «Hey, we noticed you created a new file called mnelson.txt, but unless you use the ‘git add’ command we aren’t going to do anything with it.»

Step 9: Merge a PR

Go ahead and click the green ‘Merge pull request’ button. This will merge your changes into the primary branch.

When you’re done, I recommend deleting your branch (too many branches can become messy), so hit that grey ‘Delete branch’ button as well.

You can double check that your commits were merged by clicking on the ‘Commits’ link on the first page of your new repo.

This will show you a list of all the commits in that branch. You can see the one I just merged right up top (Merge pull request #1).

You can also see the hash code of the commit on the right hand side. A hash code is a unique identifier for that specific commit. It’s useful for referring to specific commits and when undoing changes (use the git revert <hash code number> command to backtrack).

Как работает git?

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

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

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

Install Git on Mac

Most versions of MacOS will already have installed, and you can activate it through the terminal with . However, if you don’t have Git installed for whatever reason, you can install the latest version of Git using one of several popular methods as listed below:

Install Git From an Installer

1. Navigate to the latest macOS Git Installer and download the latest version.
2. Once the installer has started, follow the instructions as provided until the installation is complete.
3. Open the command prompt «terminal» and type to verify Git was installed.

Note: is a popular and recommended resource for downloading Git on a Mac. The advantage of downloading Git from is that your download automatically starts with the latest version of Git. The download source is the same macOS Git Installer as referenced in the steps above.

Install Git from Homebrew

Homebrew is a popular package manager for macOS. If you already have Homwbrew installed, you can follow the below steps to install Git:

1. Open up a terminal window and install Git using the following command: .
2. Once the command output has completed, you can verify the installation by typing: .

Из источника (Mac OS X/Linux/BSD/etc.)

В Mac OS X, если у вас установлены инструменты разработчика, вы легко можете скомпилировать Git из исходного кода. Загрузите последнюю версию Git как или из http://git-scm.com/ и извлеките ее (дважды щелкните в Finder )

В Linux/BSD/etc. это должно быть почти то же самое. Например, в Debian (и Ubuntu) вам необходимо установить пакет через .

Затем в терминале туда, где вы извлекли файлы (Running должен работать), а затем запустите.

Это установит Git в место по умолчанию ( — так будет в )

Он предложит вам ввести свой пароль (для ), поэтому он может писать в каталог , доступ к которому может получить только пользователь root, поэтому требуется sudo!

Если вы хотите установить его где-то отдельно (поэтому Git файлы не смешиваются с другими инструментами), используйте с помощью команды configure:

Это установит двоичный файл в — поэтому вам не нужно вводить его каждый раз, когда вы добавляете в свой , добавив следующую строку в свой :

Если у вас нет доступа к sudo, вы можете использовать и установить его в свой домашний каталог. Не забудьте добавить в

script x- git -update-to-last-version автоматизирует много этого:

Ветвление

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

Это ведёт нас ключевой особенности Git — ветвлению, возможности работать над разными версиями проекта. Это значит, что вместо одного списка с упорядоченными коммитами история будет расходиться в определённых точках (что делает её похожей на дерево). Каждая ветвь в Git содержит легковесный указатель HEAD на последний коммит в этой ветке, что позволяет без лишних затрат создать много веток. Совет: называйте ветку в соответствии с разрабатываемой в ней функциональностью. Ветка по умолчанию называется master.

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

Стандартные команды:

•  — создаёт новую ветку с HEAD, указывающим на HEAD. Если не передать аргумент , то команда выведет список всех локальных веток;
•  — переключается на эту ветку. Можно передать опцию , чтобы создать новую ветку перед переключением;
•  — удаляет ветку.

Как наш локальный репозиторий, так и удалённый, могут иметь множество ветвей, поэтому когда вы отслеживаете удалённый репозиторий, на самом деле отслеживается удалённая ветка ( привязывает вашу ветку master к ветке origin/master удалённого репозитория).

Привязывание к удалённой ветке:

•  — привязывает текущую ветку к указанной удалённой ветке;
•  — аналог предыдущей команды;
•  — создаёт новую локальную ветку и начинает отслеживать удалённую;
•  — показывает локальные и отслеживаемые удалённые ветки;
•  — создаёт локальную ветку с таким же именем, как у удалённой, и начинает её отслеживать.

В общем,  связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как  перемещает общий HEAD.

Прятки и чистка

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

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

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

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

Система контроля версий Git

Для начала определим, что такое система контроля версий.

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

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

Одна из самых популярных систем называется Git. Её отличие от других программ — отсутствие графической версии. Поэтому работа с Git ведётся через командную строку. В разных операционных системах свои программы для взаимодействия с Git.

В Windows их две: PowerShell и cmd.exe. В Ubuntu это Terminal. Самая популярная программа на macOS тоже называется Terminal. Если вам не подходит встроенная в систему программа для работы с командной строкой, вы можете поставить свою. Например, написанную на JavaScript программу Hyper, которая работает на любой операционной системе. На Windows популярны программы Cmder и Git Bash, а на macOS — iTerm.

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

Устанавливаем Git

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

Установка в Linux

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

• Если у вас 21 или более ранняя версия Fedora, используйте .
• Для 22 и последующих версий Fedora вводите .
• Для дистрибутивов, основанных на Debian, например, Ubuntu, используйте .

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

Установка на macOS

1. Скачиваем Git со страницы проекта.
2. Запускаем загруженный файл.
3. Система может показать окно с ошибкой, где будет написано, что файл скачан с неавторизованного сайта и инсталлятор не может быть запущен. В таком случае нужно зайти в «Системные настройки» — «Безопасность» (Security and Privacy), в появившемся окне будет сообщение об ошибке и кнопка Open anyway (Всё равно открыть). Нажимаем.
4. Система покажет окно, уточняющее хотите ли вы запустить установку. Подтверждаем действие.
5. Установщик проведёт через все необходимые шаги.

Установка в Windows

Скачайте exe-файл инсталлятора с сайта Git и запустите его. Это Git для Windows, он называется msysGit. Установщик спросит добавлять ли в меню проводника возможность запуска файлов с помощью Git Bash (консольная версия) и GUI (графическая версия). Подтвердите действие, чтобы далее вести работу через консоль в Git Bash. Остальные пункты можно оставить по умолчанию.

Проверим, что Git установлен

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

Настройка Git

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

Откройте терминал и используйте следующую команду, чтобы добавить своё имя:

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

Если вы хотите менять эту информацию для разных проектов, то в директории проекта вводите эти же команды, только без опции .

Эмммм… это делается через сайт?

Да, все это делается с сайта GitHub.

Pull request создается по нажатию одноименной кнопки, о которой мы говорили ранее при редактировании README-файла. Элементарно!

А еще вы можете создать отдельную ветку на сайте через сам репозиторий. Перейдите в репозиторий и кликните по выпадающему меню в левой части экрана. Там еще написано Branch: master. Задайте имя новой ветки и выберите Create branch (либо нажмите на клавиатуре). Теперь у вас есть две одинаковые ветки. Это отличное место для внесения изменений и тестирования их до слияния с .

Создание ветки

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

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

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

• Кликните по вкладке Pull request вверху экрана.
• Нажмите зеленую кнопку New pull request.
• Перейдите в поле Example Comparisons. Выберите ветку, которую хотите сравнить с .
• Еще раз просмотрите все изменения, убедитесь, что они готовы для коммита.
• Нажмите большую зеленую кнопку New pull request. Напишите заголовок запроса, дайте краткое описание изменений. Нажмите Create pull request.

Новый Pull request

Создание pull request

Если это ваш репозиторий, то слить изменения с можно через зеленую кнопку Merge pull request. Нажмите Confirm merge. Сразу после объединения нужной ветки с нажмите Delete branch в фиолетовом боксе.

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

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