Как создать репозиторий на github на windows

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

Introduction

GitHub Desktop is a free, open source application that helps you to work with code hosted on GitHub or other Git hosting services. With GitHub Desktop, you can perform Git commands, such as committing and pushing changes, in a graphical user interface, rather than using the command line. For more information, see «About GitHub Desktop.»

By the end of this guide, you’ll have used GitHub Desktop to create a repository, make changes to the repository, and publish the changes to GitHub.

After installing GitHub Desktop and signing into GitHub or GitHub Enterprise you can create and clone a tutorial repository. The tutorial will introduce the basics of working with Git and GitHub, including installing a text editor, creating a branch, making a commit, pushing to GitHub.com, and opening a pull request. The tutorial is available if you do not have any repositories on GitHub Desktop yet.

We recommend completing the tutorial, but if you want to explore GitHub Desktop by creating a new repository, this guide will walk you through using GitHub Desktop to work on a Git repository.

Part 1: Installing GitHub Desktop and authenticating your account

You can install GitHub Desktop on any supported operating system. After you install the app, you will need to sign in and authenticate your account on GitHub or GitHub Enterprise before you can create and clone a tutorial repository.

For more information on installing and authenticating, see «Setting up GitHub Desktop.»

Part 2: Creating a new repository

If you do not have any repositories associated with GitHub Desktop, you will see a «Let’s get started!» view, where you can choose to create and clone a tutorial repository, clone an existing repository from the Internet, create a new repository, or add an existing repository from your hard drive.

Screenshot of the "Let's get started!" view in GitHub Desktop.

Creating and cloning a tutorial repository

We recommend that you create and clone a tutorial repository as your first project to practice using GitHub Desktop.

  1. Click Create a Tutorial Repository….
  2. Follow the prompts in the tutorial to install a text editor, create a branch, edit a file, make a commit, publish to GitHub, and open a pull request.

Creating a new repository

If you do not wish to create and clone a tutorial repository, you can create a new repository.

  1. Click Create a New Repository on your Hard Drive….
  2. In the «Create a New Repository» window, fill in the fields and select your preferred options.
    • «Name» defines the name of your repository both locally and on GitHub.
    • «Description» is an optional field that you can use to provide more information about the purpose of your repository.
    • «Local path» sets the location of your repository on your computer. By default, GitHub Desktop creates a GitHub folder inside your Documents folder to store your repositories, but you can choose any location on your computer. Your new repository will be a folder inside the chosen location. For example, if you name your repository Tutorial, a folder named Tutorial is created inside the folder you selected for your local path. GitHub Desktop remembers your chosen location the next time you create or clone a new repository.
    • Initialize this repository with a README creates an initial commit with a README.md file. READMEs helps people understand the purpose of your project, so we recommend selecting this and filling it out with helpful information. When someone visits your repository on GitHub, the README is the first thing they’ll see as they learn about your project. For more information, see «About READMEs.»
    • The Git ignore drop-down menu lets you add a custom file to ignore specific files in your local repository that you don’t want to store in version control. If there’s a specific language or framework that you’ll be using, you can select an option from the available list. If you’re just getting started, feel free to skip this selection. For more information, see «Ignoring files.»
    • The License drop-down menu lets you add an open-source license to a LICENSE file in your repository. You don’t need to worry about adding a license right away. For more information about available open-source licenses and how to add them to your repository, see «Licensing a repository.»
  3. Click Create repository.

Part 3: Exploring GitHub Desktop

In the file menu at the top of the screen, you can access settings and actions that you can perform in GitHub Desktop. Most actions also have keyboard shortcuts to help you work more efficiently. For a full list of keyboard shortcuts, see «GitHub Desktop keyboard shortcuts.»

The GitHub Desktop repository bar

At the top of the GitHub Desktop app, you will see a bar that shows the current state of your repository.

Screenshot of the GitHub Desktop app. A bar displaying details for the "hello-world" repository spans the top of the window, and is outlined in orange.

  • Current repository shows the name of the repository you’re working on. You can click Current repository to switch to a different repository in GitHub Desktop.
  • Current branch shows the name of the branch you’re working on. You can click Current branch to view all the branches in your repository, switch to a different branch, or create a new branch. Once you create pull requests in your repository, you can also view these by clicking on Current branch.
  • Publish repository appears because you haven’t published your repository to GitHub yet, which you’ll do later in the next step. This section of the bar will change based on the status of your current branch and repository. Different context dependent actions will be available that let you exchange data between your local and remote repositories.

Changes and History

In the left sidebar, you’ll find the Changes and History views.

Screenshot of the GitHub Desktop app. A sidebar on the left-hand side, with tabs labeled "Changes" and "History", is highlighted with an orange outline.

  • The Changes view shows changes you’ve made to files in your current branch but haven’t committed to your local repository. At the bottom, there is a box with «Summary» and «Description» text boxes and a Commit to BRANCH button. This is where you’ll commit new changes. The Commit to BRANCH button is dynamic and will display which branch you’re committing your changes to.
  • The History view shows the previous commits on the current branch of your repository. You should see an «Initial commit» that was created by GitHub Desktop when you created your repository. To the right of the commit, depending on the options you selected while creating your repository, you may see .gitattributes, .gitignore, LICENSE, or README files. You can click each file to see a diff for that file, which is the changes made to the file in that commit. The diff only shows the parts of the file that have changed, not the entire contents of the file

Part 4: Publishing your repository to GitHub

When you create a new repository, it only exists on your computer and you are the only one who can access the repository. You can publish your repository to GitHub to keep it synchronized across multiple computers and allow other people to access it. To publish your repository, push your local changes to GitHub.

  1. In the repository bar, click Publish repository.
    Screenshot of the repository bar. A button, labeled "Publish repository", is highlighted with an orange outline.
  2. In the «Publish Repository» window, enter details for your new repository.
    • GitHub Desktop automatically fills the «Name» and «Description» fields with the information you entered when you created the repository.
    • Keep this code private lets you control who can view your project. If you leave this option unselected, other users on GitHub will be able to view your code. If you select this option, your code will not be publicly available.
    • The Organization drop-down menu, if present, lets you publish your repository to a specific organization that you belong to on GitHub.
    1. Click Publish Repository.
    2. You can access the repository on GitHub.com from within GitHub Desktop. In the file menu, click Repository, then click View on GitHub. This will take you directly to the repository in your default browser.

Part 5: Making, committing, and pushing changes

Now that you’ve created and published your repository, you’re ready to make changes to your project and start crafting your first commit to your repository.

  1. To launch your external editor from within GitHub Desktop, in the «GitHub Desktop» menu bar, select Repository, then click Open in EDITOR. For more information, see «Configuring a default editor in GitHub Desktop.»
    Screenshot of a menu bar on a Mac. Under the open "Repository" dropdown menu, a cursor hovers over "Open in Visual Studio Code", highlighted in blue.

  2. Make some changes to the README.md file that you previously created. You can add information that describes your project, like what it does and why it is useful. When you are satisfied with your changes, save them in your text editor.

  3. In GitHub Desktop, navigate to the Changes view. In the file list, you should see your README.md. The checkbox to the left of the README.md file indicates that the changes you’ve made to the file will be part of the commit you make. In the future, you might make changes to multiple files but only want to commit the changes you’ve made to some of the files. If you click the checkbox next to a file, that file will not be included in the commit.
    Screenshot of the "Changes" tab in the sidebar. To the left of the "README.md" file, a selected checkbox is highlighted with an orange outline.

  4. At the bottom of the Changes list, enter a commit message. To the right of your profile picture, type a short description of the commit. Since we’re changing the README.md file, «Add information about purpose of project» would be a good commit summary. Below the summary, you’ll see a «Description» text field where you can type a longer description of the changes in the commit, which is helpful when looking back at the history of a project and understanding why changes were made. Since you’re making a basic update of a README.md file, you can skip the description.
    Screenshot of the "Changes" tab in the sidebar. To the right of a profile picture, a text field containing a commit message is outlined in orange.

  5. Below your commit message, click Commit to BRANCH NAME. The commit button shows your current branch so you can be sure to commit to the branch you want.

  6. To push your changes to the remote repository on GitHub, click Push origin.
    Screenshot of the "Repository" menu bar. A button, labeled "Push origin", is highlighted with an orange outline.

    • The Push origin button is the same one that you clicked to publish your repository to GitHub. This button changes contextually based on where you are at in the Git workflow. It should now say Push origin with a 1 next to it, indicating that there is one commit that has not been pushed up to GitHub.
    • The «origin» in Push origin means that you are pushing changes to the remote called origin, which in this case is your project’s repository on GitHub.com. Until you push any new commits to GitHub, there will be differences between your project’s repository on your computer and your project’s repository on GitHub.com. This allows you to work locally and only push your changes to GitHub.com when you’re ready.
  7. In the window to the right of the Changes view, you’ll see suggestions for actions you can do next. To open the repository on GitHub in your browser, click View on GitHub.
    Screenshot of the "No local changes" screen. In a list of suggestions, a button, labeled "View on GitHub", is highlighted with an orange outline.

  8. In your browser, click 2 commits. You’ll see a list of the commits in this repository on GitHub. The first commit should be the commit you just made in GitHub Desktop.
    Screenshot of the repository page on GitHub. Above the list of files and next to a clock icon, a link, labeled "2 commits", is outlined in orange.

Conclusion

You’ve now created a repository, published the repository to GitHub, made a commit, and pushed your changes to GitHub. You can follow this same workflow when contributing to other projects that you create or collaborate on.

Further reading

  • «Getting started with Git»
  • «Learning about GitHub»
  • «Get started with GitHub documentation»

Время на прочтение
5 мин

Количество просмотров 482K

Часть 2

Что такое Git и зачем он нужен?

Git — это консольная утилита, для отслеживания и ведения истории изменения файлов, в вашем проекте. Чаще всего его используют для кода, но можно и для других файлов. Например, для картинок — полезно для дизайнеров.

С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.

Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске.

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

  • GitHub

  • Bitbucket

  • GitLab

Каждая точка сохранения вашего проекта носит название коммит (commit). У каждого commit-a есть hash (уникальный id) и комментарий. Из таких commit-ов собирается ветка. Ветка — это история изменений. У каждой ветки есть свое название. Репозиторий может содержать в себе несколько веток, которые создаются из других веток или вливаются в них.

Как работает

Если посмотреть на картинку, то становиться чуть проще с пониманием. Каждый кружок, это commit. Стрелочки показывают направление, из какого commit сделан следующий. Например C3 сделан из С2 и т. д. Все эти commit находятся в ветке под названием main. Это основная ветка, чаще всего ее называют master . Прямоугольник main* показывает в каком commit мы сейчас находимся, проще говоря указатель.

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

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

Установка

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

Но для начала, все же установим сам Git.

  • Windows. Проходим по этой ссылке, выбираем под вашу ОС (32 или 64 битную), скачиваем и устанавливаем.

  • Для Mac OS. Открываем терминал и пишем:

#Если установлен Homebrew
brew install git

#Если нет, то вводим эту команду. 
git --version
#После этого появится окно, где предложит установить Command Line Tools (CLT).
#Соглашаемся и ждем установки. Вместе с CLT установиться и git
  • Linux. Открываем терминал и вводим следующую команду.

# Debian или Ubuntu
sudo apt install git

# CentOS
sudo yum install git

Настройка

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

Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.

#Установим имя для вашего пользователя
#Вместо <ваше_имя> можно ввести, например, Grisha_Popov
#Кавычки оставляем
git config --global user.name "<ваше_имя>"

#Теперь установим email. Принцип тот же.
git config --global user.email "<адрес_почты@email.com>"

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

Теперь вы готовы к работе с Git локально на компьютере.

Создадим наш первый репозиторий. Для этого пройдите в папку вашего проекта.

#Для Linux и MacOS путь может выглядеть так /Users/UserName/Desktop/MyProject
#Для Windows например С://MyProject
cd <путь_к_вашему_проекту>

#Инициализация/создание репозитория
git init

Теперь Git отслеживает изменения файлов вашего проекта. Но, так как вы только создали репозиторий в нем нет вашего кода. Для этого необходимо создать commit.

#Добавим все файлы проекта в нам будующий commit
git add .
#Или так
git add --all

#Если хотим добавить конкретный файл то можно так
git add <имя_файла> 

#Теперь создаем commit. Обязательно указываем комментарий.
#И не забываем про кавычки
git commit -m "<комментарий>"

Отлично. Вы создали свой первый репозиторий и заполнили его первым commit.

Процесс работы с Git

Не стоит после каждого изменения файла делать commit. Чаще всего их создают, когда:

  • Создан новый функционал

  • Добавлен новый блок на верстке

  • Исправлены ошибки по коду

  • Вы завершили рабочий день и хотите сохранить код

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

Визуальный интерфейс

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

Но существуют и отдельные программы по работе с Git. Могу посоветовать эти:

  • GitHub Desktop

  • Sourcetree

  • GitKraken

Я не буду рассказывать как они работают. Предлагаю разобраться с этим самостоятельно.

Создаем свой первый проект и выкладываем на GitHub

Давайте разберемся как это сделать, с помощью среды разработки Visual Studio Code (VS Code).

Перед началом предлагаю зарегистрироваться на GitHub.

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

После открываем VS Code .

  1. Установите себе дополнительно анализаторы кода для JavaScript и PHP

  2. Откройте вашу папку, которую создали ранее

После этого у вас появится вот такой интерфейс

  1. Здесь будут располагаться все файлы вашего проекта

  2. Здесь можно работать с Git-ом

  3. Кнопка для создания нового файла

  4. Кнопка для создания новой папки

Если ваш проект пустой, как у меня, то создайте новый файл и назовите его index.html . После этого откроется окно редактирование этого файла. Напишите в нем ! и нажмите кнопку Tab . Автоматически должен сгенерироваться скелет пустой HTML страницы. Не забудьте нажать ctrl+s чтобы файл сохранился.

Давайте теперь перейдем во вкладу для работы с Git-ом.

Откроется вот такое окно:

  1. Кнопка для публикации нашего проекта на GitHub

  2. После нажатия на кнопку 1 , появится всплывающее окно. Нужно выбрать второй вариант или там где присутствует фраза ...public repository

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

После того, как выбрали «Опубликовать на GitHub публичный репозиторий» (пункт 2), программа предложит вам выбрать файлы, которые будут входить в первый commit. Проставляем галочки у всех файлов, если не проставлены и жмем ОК . Вас перекинет на сайт GitHub, где нужно будет подтвердить вход в аккаунт.

Вы создали и опубликовали репозиторий на GitHub.

Теперь сделаем изменения в коде и попробуем их снова опубликовать. Перейдите во вкладку с файлами, отредактируйте какой-нибудь файл, не забудьте нажать crtl+s (Windows) или cmd+s (MacOS), чтобы сохранить файл. Вернитесь обратно во вкладу управления Git.

Если посмотреть на значок вкладки Git, то можно увидеть цифру 1 в синем кружке. Она означает, сколько файлов у нас изменено и незакоммичено. Давайте его закоммитим и опубликуем:

  1. Кнопка для просмотра изменений в файле. Необязательно нажимать, указал для справки

  2. Добавляем наш файл для будущего commit

  3. Пишем комментарий

  4. Создаем commit

  5. Отправляем наш commit в GitHub

Поздравляю, вы научились создавать commit и отправлять его в GitHub!

Итог

Это первая вводная статья по утилите Git. Здесь мы рассмотрели:

  • Как его устанавливать

  • Как его настраивать

  • Как инициализировать репозиторий и создать commit через консоль

  • Как на примере VS Code, опубликовать свой код на GitHub

Забегая вперед, советую вам погуглить, как работают следующие команды:

git help # справка по всем командам
git clone
git status
git branch
git checkout
git merge
git remote
git fetch
git push
git pull

P.S. Для облегчения обучения, оставлю вам ссылку на бесплатный тренажер по Git.

https://learngitbranching.js.org/

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

Если вы хотите начать работать с Git, прочитав всего одну главу, то эта глава — то, что вам нужно.
Здесь рассмотрены все базовые команды, необходимые вам для решения подавляющего большинства задач, возникающих при работе с Git.
После прочтения этой главы вы научитесь настраивать и инициализировать репозиторий, начинать и прекращать контроль версий файлов, а также подготавливать и фиксировать изменения.
Мы также продемонстрируем вам, как настроить в Git игнорирование отдельных файлов или их групп, как быстро и просто отменить ошибочные изменения, как просмотреть историю вашего проекта и изменения между отдельными коммитами (commit), а также как отправлять (push) и получать (pull) изменения в/из удалённого (remote) репозитория.

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

Обычно вы получаете репозиторий Git одним из двух способов:

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

  2. Вы можете клонировать существующий репозиторий Git из любого места.

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

Создание репозитория в существующем каталоге

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

для Linux:

$ cd /home/user/my_project

для macOS:

$ cd /Users/user/my_project

для Windows:

$ cd C:/Users/user/my_project

а затем выполните команду:

Эта команда создаёт в текущем каталоге новый подкаталог с именем .git, содержащий все необходимые файлы репозитория — структуру Git репозитория.
На этом этапе ваш проект ещё не находится под версионным контролем.
Подробное описание файлов, содержащихся в только что созданном вами каталоге .git, приведено в главе Git изнутри

Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит добавить их в индекс и осуществить первый коммит изменений.
Добиться этого вы сможете запустив команду git add несколько раз, указав индексируемые файлы, а затем выполнив git commit:

$ git add *.c
$ git add LICENSE
$ git commit -m 'Initial project version'

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

Клонирование существующего репозитория

Для получения копии существующего Git-репозитория, например, проекта, в который вы хотите внести свой вклад, необходимо использовать команду git clone.
Если вы знакомы с другими системами контроля версий, такими как Subversion, то заметите, что команда называется «clone», а не «checkout».
Это важное различие — вместо того, чтобы просто получить рабочую копию, Git получает копию практически всех данных, которые есть на сервере.
При выполнении git clone с сервера забирается (pulled) каждая версия каждого файла из истории проекта.
Фактически, если серверный диск выйдет из строя, вы можете использовать любой из клонов на любом из клиентов, для того, чтобы вернуть сервер в то состояние, в котором он находился в момент клонирования (вы можете потерять часть серверных хуков (server-side hooks) и т. п., но все данные, помещённые под версионный контроль, будут сохранены, подробнее об этом смотрите в разделе Установка Git на сервер главы 4).

Клонирование репозитория осуществляется командой git clone <url>.
Например, если вы хотите клонировать библиотеку libgit2, вы можете сделать это следующим образом:

$ git clone https://github.com/libgit2/libgit2

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

$ git clone https://github.com/libgit2/libgit2 mylibgit

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

В Git реализовано несколько транспортных протоколов, которые вы можете использовать.
В предыдущем примере использовался протокол https://, вы также можете встретить git:// или user@server:path/to/repo.git, использующий протокол передачи SSH.
В разделе Установка Git на сервер главы 4 мы познакомимся со всеми доступными вариантами конфигурации сервера для обеспечения доступа к вашему Git репозиторию, а также рассмотрим их достоинства и недостатки.

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

Одна из таких систем — GitHub — платформа для хостинга репозиториев. Расскажем о ней подробнее: как зарегистрироваться, создать проект, вносить в него изменения и не столкнуться с конфликтами версий. 

Регистрация на GitHub: создание аккаунта

Для работы с платформой нужно создать аккаунт. Для этого переходим по ссылке и тапаем по кнопке Sign up.

создание аккаунта

На странице регистрации вводим данные:

  1. Адрес электронной почты. Если на почту уже был зарегистрирован аккаунт, на странице появится сообщение об ошибке: «Email is invalid or already taken».
  1. Пароль. Система рекомендует использовать для пароля последовательность из 15 символов или 8, но с использованием хотя бы одной цифры и строчной буквы.
  1. Имя пользователя. «Юзернейм» должен быть уникальным. При этом он не может начинаться или заканчиваться дефисом. 
логин и пароль

Теперь нужно нажать кнопку Continue, принять или отклонить предложение о подписке на рассылку и пройти экстравагантную валидацию:

проходим валидацию

Затем подтвердите адрес электронной почты. 

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

Установка Git

Для работы с репозиторием необходимо скачать Git-терминал или GitHub Desktop. Что из этого выбрать — решать вам. Но предпочтительней уметь работать с командной строкой Git. Такое требование часто можно встретить в вакансиях. Вдобавок, знание командной строки позволяет работать с другими платформами, подобными GitHub.

Терминал

Если у вас установлен Linux, смело пропускайте раздел. С Mac и Windows другая история.

Mac OS

Если вы пользовались XCode, вероятно, Git уже установлен. В противном случае зайдите в терминал, выполните команду git и нажмите кнопку Установить.

установка с помощью терминала

После установки можно узнать версию Git.

git --version
версия git

Windows

На винду Git можно скачать с официального сайта или через пакет Git Chocolatey. Дополнительная информация о Git Windows доступна по ссылке.

GitHub Desktop. Краткий обзор

Непривычна работа в командной строке — установите «десктопную» версию (доступна на всех ОС). Она хорошо подходит для базовых операций.Установщик есть на официальной странице GitHub Desktop. Там же и наиболее подробное описание программы.

При первом запуске пользователя встречает окно с авторизацией.

вход в github desktop

А после — интерфейс с привычным функционалом: можно создавать и клонировать репозитории.

интерфейс репозиториев

Важно отметить, что установка GitHub Desktop на Linux может отличаться в зависимости от дистрибутива. Рекомендуем ознакомиться с официальной инструкцией.

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

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

Первый способ — синхронизация с локальным репозиторием

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

синхронизация с локальным репозиторием

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

Для этого необходимо зайти в терминал, перейти в директорию проекта и ввести команду:

git init 
команда git init

Загрузка файлов в репозиторий. Создание коммитов

Далее следует добавить все файлы проекта в своеобразный пакет изменений и сделать commit («закоммитить») — загрузить изменения.

git add main.py
git add GAN_core.py
git add dino_ds_api.py
git commit -m “первый коммит”

создание коммита

Последняя команда делает сам «коммит», а флаг -m указывает на сообщение «первый коммит».

В примере были «закоммичены» несколько python-файлов: main, GAN_core и dino_ds_api. Если вам нужно добавить в «коммит» все, что есть в директории, — используйте команду:

git add .

Теперь создадим репозиторий на GitHub. Для этого нужно нажать на кнопку Create repository.

создаем репозиторий

В открывшемся окне обязательно к заполнению только поле с названием проекта. Оно должно быть кратким, но понятным. В нашем примере это gan-dino (gan от generative adversarial networks и dino от dinosaur).

Все остальное опционально:

  • Описание. Поле с кратким описанием проекта. 
  • Режим доступа. Для коммерческих или корпоративных продуктов обычно устанавливается режим private (репозиторий доступен ограниченному кругу лиц). В остальных случаях — public (доступно по ссылке).
  • Файл README. Если в репозитории нужно подробное описание проекта — поставьте галочку рядом с Add a README file. Но есть нюанс: для первого способа создания репозитория галочки быть не должно.
  • Конфигурация .gitignore. Бывает, что в проекте нужно разместить невидимые для Git файлы. Чтобы как-то их обозначить, придумали конфигурацию .gitignore, в которой их можно перечислить.
  • Лицензия. Чтобы никто не использовал ваш код в коммерческих целях без спроса, необходимо добавить файл с лицензией. В нем правообладатели прописывают правила использования своей интеллектуальной собственности.

Создадим public-проект gan-dino, без файла README и конфигурации .gitignore.

конфигурация репозитория

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

набор команд git
git remote add origin https://github.com/t-rex-general/gan-dino.git
git branch -M main
git push -u origin main

Первая строка загружает origin —  прообраз нашего проекта в глобальном репозитории. Со второй командой мы познакомимся позже. Третья команда загружает (пушит) изменения в GitHub-репозиторий.

После ввода команд система попросит авторизоваться с помощью пароля и названия профиля.

авторизация

После 13 августа 2021 года вместо пароля нужно вводить токен. 

Откройте настройки вашего аккаунта, выберите пункт меню Developer settings, кликните по Personal access tokens и generate new token. А затем повторите попытку.

авторизация с токеном

Получилось! В репозиторий загрузились нужные файлы. Можно смело делиться ссылкой на него.

делимся ссылкой на репозиторий

Второй способ — от глобального к локальному

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

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

новый репозиторий без локальной подзагрузки

Чтобы клонировать этот репозиторий себе на компьютер, нужно нажать на зеленую кнопку Code, скопировать HTTPS-адрес, перейти в терминал, в нужную директорию и ввести команду:

git clone https://github.com/t-rex-general/gan-dino2.git

В результате файл README.md появится в выбранной директории — локальном репозитории.

С помощью этой же команды можно клонировать и чужие проекты. Например, чтобы не писать все модули для определителя динозавров самостоятельно, можно клонировать чужой репозиторий себе на компьютер. Или сделать fork («форк»), то есть скопировать чей-то проект в свой GitHub-профиль для его доработки. 

Третий способ — внутри GitHub

Если нет возможности использовать Git-терминал или GitHub Desktop, можно работать напрямую с GitHub. Перед этим создаем репозиторий с файлом README.

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

Например, для создания нового файла достаточно нажать на кнопку Create new file. Откроется встроенный редактор кода. 

создание внутри github
файл в репозитории

Потом необходимо сделать коммит.

делаем коммит

Работа с ветками

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

Представьте ситуацию: 

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

работа с ветками

Создание веток через Git

Чтобы создать ветку (например, dev) в проекте, нужно ввести команду:

git branch dev

После ветка появится в общем списке.

git branch
git branch

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

git checkout dev
git checkout dev

Попробуем изменить файл проекта и загрузить коммит.

загружаем коммит
Добавили в программу конструкцию if
git add main.py
git commit -m “добавили if”

Теперь можно посмотреть логи — историю добавления коммитов.

смотрим логи

Действительно, второй коммит «улетел» в ветку dev. Если нас не устроили изменения, можно откатиться до предыдущего (любого) коммита по его номеру.

git checkout 61a8f08226eb8067d4e356387f1dcce5c79812dd

Чтобы запушить ветку в онлайн-репозиторий введем команду:

git push --set-upstream origin dev

Открываем репозиторий в GitHub и видим, что добавилась ветка dev:

новая ветка в github

Но если мы зайдем в main.py, то никаких изменений там не обнаружим, пока не выберем ветку dev.

выбираем ветку dev

Чтобы изменения затронули и main-ветку, нужно сделать merge — слияние веток.

Создание веток через GitHub

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

создаем ветку в github

задаем имя ветки

В рамках веток можно также вносить изменения — механизм работы не меняется. 

Слияние веток проекта

Мы почти разработали свой проект. Самое время объединить ветки dev и main.

Первым шагом необходимо переместиться в ветку main:  

git checkout main

Вторым шагом — сделать merge с веткой dev и запушить изменения:

git merge dev
git push

Теперь в GitHub-репозитории отображается актуальная информация.

актуальная информация

Работа в команде: конфликты версий и git pull

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

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

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

конфликты версий

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

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

отчет о конфликте
Отчет об ошибке

Перед тем как пушить файл на сервер, Гриша должен был получить последние изменения:

git pull

Если это сделать, в файле main.py появится структура, в которой будут видны изменения, которые внесли Вася и Гриша.

просмотр изменений

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

git add main.py
git commit -m “dino_weight”
git push

Репозиторий успешно обновлен.

успешное добавление репозитория

На практике конфликтов гораздо больше и разрешаться они могут по-разному. Важно научиться серфить по руководству git и гуглить. Впрочем, это относится ко всему процессу изучения Git и GitHub. 

Fork и Pull Request

Бывает, что ваш репозиторий кто-то форкает и вносит свои коррективы. Вы можете даже не знать, кто инициатор. Если он захочет поделиться корректировками с вами, то создаст запрос слияния (Pull Request). 

Зайдем с другого аккаунта, найдем репозиторий gan-dino через поисковую систему в GitHub и сделаем форк.

делаем форк
всё ещё делаем форк
новый fork

В нашем списке репозиториев появился новый gan-dino-FORK — это форк-образ gan-dino. Теперь можно внести изменения, например, в main.py, и сделать pull request.

делаем pull request
создаем pull request

Затем владельцу репозитория нужно подтвердить или отклонить запрос. Чтобы это сделать, нужно перейти во вкладку «Pull requests», выбрать интересующий pull-запрос и нажать одну из предложенных кнопок.

принять или отклонить запрос
мержим pull request

Домашнее задание

Любой конкурентоспособный разработчик должен разбираться в Git. Нелишним будет и знание GitHub, в котором есть много возможностей, значительно упрощающих работу над проектами в команде (project management). Например, дашборды во вкладке Projects, повторяющие функционал Trello и Jira.

дашборд

GitHub — это целая социальная сеть для разработчиков из разных частей света. 

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

Присоединяйтесь к нашей команде и погрузитесь в наши git-проекты.


Если у вас остались вопросы по работе с Git или GitHub, напишите нам.

Введение

В предыдущей статье мы рассмотрели наиболее часто используемые команды при работе в консоли. В данной публикации продолжим осваивать этот инструмент, используя его для взаимодействия с системой контроля версий (Version Control System, СКВ) Git, а также с его неизменным спутником, хранилищем кода, GitHub.

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

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

Чтобы было понятнее, что такое СКВ, приведем ряд примеров и задач, которые она призвана решать:

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

Программист написал работающий код, но, увлекшись его оптимизацией, испортил свою часть работы, да еще и затронул код коллег, от чего программа стала работать не корректно. Как решить такую проблему и вернуться к рабочей версии кода: жать до посинения Ctrl + Z, чтобы откатиться к ней? А если среда разработки не запомнила все изменения и отменить уже ничего нельзя?

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

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

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

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

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

2. Виды СКВ

СКВ бывают локальными (ЛСКВ), централизованными (ЦСКВ) и распределенными (РСКВ).

2.1. Первое поколение СКВ

В первом поколении СКВ были локальными: они хранили все изменения файлов на одном устройстве в локальной базе данных. При этом разрешалось только одному пользователю одновременно вносить изменения в файл. Такие системы не предназначены для удобного взаимодействия с удалённой командой. Примером ЛСКВ является SCCS и RCS.

2.2. Второе поколение СКВ

Для решения проблем ЛСКВ были созданы ЦСКВ, которые используют центральный сервер для хранения всех версий файлов. А уже к нему по сети подключаются разработчики для получения, хранение файлов и т. д. Эти системы впервые позволили нескольким разработчикам одновременно работать с одними и теми же файлами. Использование ЦСКВ являлось стандартом на протяжении многих лет. К ним относятся CVS, Subversion и т. д.

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

2.3. Третье поколение СКВ

С целью устранения недостатков ЦСКВ были разработаны системы третьего поколения или РСКВ такие, как Git, Mercurial, Bazaar. В данных системах клиенты скачивают к себе на локальный компьютер полностью весь проект со всеми файлами и их изменениями за все время его существования. И если один из серверов выйдет из строя, то потерянный код можно будет восстановить, взяв его у любого программиста из команды, и загрузить на общий сервер для продолжения работы.

РСКВ прекрасно зарекомендовали себя в командной работе вне зависимости от того, в какой части света находятся сотрудники.

3. СКВ Git

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

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

Некоторые путают Git и GitHub, но это не одно и тоже. Git — это программа (консольная утилита), которую устанавливает у себя программист для отслеживания и внесения изменений в файлах. GitHub — это сайт (хостинг) для хранения этих изменений и обмена файлами проекта. Его еще называют социальной сетью для программистов. Существуют и другие подобные сайты, например, BitBucket, SourceForge, GitLab и т. д.

Если кратко, то первоначальное взаимодействие Git и GitHub выглядит так: вы устанавливаете Git и подключаете его к своему проекту; регистрируетесь на GitHub; создаете в нем пустой репозиторий; переносите файлы с помощью Git со своего компьютера на GitHub (в облако) для доступа к ним другим участникам команды (или только для себя).

4. Скачивание и установка Git

Скачаем Git с официального сайта и установим к себе на компьютер. Мне нужна версия под Windows.

Запустим скачанный файл и начнем установку.

5. Создание аккаунта и репозитория на GitHub

5.1. Создание аккаунта

Перейдите на сайт github.com и в правом верхнем углу страницы, для регистрации, нажмите Sign up.

Введите свои данные: электронную почту; пароль (рекомендации по созданию надежного пароля); имя, которое будет использоваться на GitHub и подтверждение на рассылку.

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

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

Следующим шагом является создание на GitHub нового репозитория.

Репозиторий — это просто хранилище для чего угодно. В нашем случае, мы будем хранить в нем код. Репозиториев можно создать неограниченное количество под любой проект. Например, сейчас мы создадим хранилище под названием startjava2 (вам цифру 2 писать не нужно). А в будущем еще несколько под разными названиями: basejava, topjava — в них будет храниться код, связанный с этими проектами.

Чтобы создать новый репозиторий, нажмите на сайте GitHub в правом верхнем углу + и выберите New repository.

Откроется новая страница с первоначальными настройками, где нужно ввести имя репозитория и краткое описание (необязательно). Также необходимо пометить, чтобы он был Public (при Private доступ к репозиторию будет только по приглашению). Все остальное мы настроим позже.

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

6. Способы авторизации

Доступ к репозиториям на GitHub из командной строки можно получить двумя способами: по протоколу HTTPS или SSH.

С 13 августа 2021 г. GitHub отменил использование паролей для аутентификации из командной строки с помощью Git в пользу токенов персонального доступа (Personal access tokens, PAT). Эти шаги были сделаны с целью повышения безопасности пользователей.

6.1. Токен персонального доступа и HTTPS

Для доступа (авторизации) к GitHub по протоколу HTTPS необходимо создать PAT.

Преимущества PAT перед паролями:

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

Возможность настройки ограничений для каждого токена при работе с GitHub

возможность аннулирования токена для конкретного устройства

возможность ограничить срок действия токена

6.1.1. Создание токена

Для создания токена необходимо выполнить следующие шаги:

Авторизуйтесь на github.com, а затем нажмите на круглое изображение своего профиля в правом верхнем углу страницы и выберите Settings.

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

Относитесь к своим токенам как к паролям, держа их в секрете.

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

При запросе аутентификации, вам нужно будет ввести:


Username: ваш email
Password: ваш скопированный токен (вместо пароля)

6.2. Доступ через SSH

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

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

SSH (Secure SHell, «безопасная оболочка») — это сетевой протокол, обеспечивающий шифрование передаваемых данных, а также защищенный доступ к удаленному серверу.

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

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

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

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

Для создания ключей необходимо использовать утилиту ssh-keygen, поставляемую в Windows с Git. В Linux/macOS она входит в состав пакета SSH.

Затем все время жмите Enter, ничего не вводя.

В итоге в Windows по адресу C:\Users\Имя_пользователя\.ssh будет создано два файла: id_rsa (приватный ключ — никому его не показывайте) и id_rsa.pub (открытый ключ — можете показывать кому угодно).

Для Linux/macOS ключи будут созданы по адресу
/home/Имя_пользователя/.ssh

Откройте файл с открытым ключом обычным текстовым редактором и скопируйте его содержимое. Скопированный ключ необходимо добавить в GitHub, выполнив следующие шаги:

Нажмите на круглое изображение своего профиля в правом верхнем углу страницы и выберите Settings.

Для проверки работоспособности ключей (SSH) или токенов (HTTPS), необходимо выполнить какие-то действия с Git, связанные с обращением к GitHub.

Воспользуйтесь, например, командой clone, которая копирует любой репозиторий с GitHub на компьютер. Зайдите на страницу созданного ранее репозитория, и скопируйте его HTTPS или SSH-адрес.

Выполните в консоли команду git clone. После успешного клонирования удалите полученные файлы.

6.3. Диспетчер учетных данных

В Windows Git для хранения данных пользователей поставляется с диспетчером учетных данных (Git Credential Manager for Windows, GCM). Мы с ним встречались во время установки Git. Он по умолчанию сохраняет учетные данные, что позволяет не вводить их все время.

Для просмотра его конфигурации введите в консоли следующую команду:


git config credential.helper

Если вы используете Git 2.29 или более позднюю версию, то в консоли отобразится надпись manager-core. Для более ранних версий credential.helper имеет значение manager.

Если команда выдаст что-то отличное от manager-core, то введите:


git config --global credential.helper manager-core

7. Установка Octotree

Для удобной навигации по файлам на GitHub установим расширение для браузера — Octotree: перейдите на сайт и выберите версию под используемый вами браузер.

Откроется магазин с расширениями для установки Octotree.

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

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

8. Настройка Git

8.1. Создание локального репозитория

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

Внешний репозиторий мы уже создали на GitHub, но он пока пуст.

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

Для этого существует команда init, отвечающая за создание репозитория, т. е. места на компьютере, где хранятся файлы и папки проекта.

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

Откройте cmder в папке StartJava и введите git init:


D:\Java\StartJava
> git init
Initialized empty Git repository in D:/Java/StartJava/.git/

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

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


D:\Java\StartJava (master)
> ls -a
./  ../  .git/  about.txt  src/

8.2. Настройка Git

В Git существуют аж целых три файла для хранения настроек. Чтобы понять зачем столько и что это за настройки, давайте отобразим их содержимое. Сильно вдаваться в подробности мы не будем, но для общего понимания этот вопрос стоит разобрать. Введем команду git config -l —show-origin:

Подробную справку к любой команде Git можно получить, написав git <команда> —help. Она отобразится отдельной страницей в окне браузера. Для получения краткой справки в терминале используется ключ -h.


git config --help
git config -h

Подробности смотрите по ссылке.

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

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

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

Зеленой рамкой выделены настройки, созданного на компьютере репозитория.

Запомнить, какой файл с настройками когда использовать, несложно:

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

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

8.3. Установка личной информации

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


git config --global user.email ВАШ_ЕМЭЙЛ
git config --global user.name ВАШЕ_ИМЯ

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

Отобразим внесенные изменения:


> git config --get user.name & git config --get user.email
ВАШЕ_ИМЯ
ВАШ_ЕМЭЙЛ

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

8.4. Установка текстового редактора

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

Для смены редактора (хоть мы его и указали во время установки, но знать, как его изменить — лишним не будет) и отображения результата выполните команды:


> git config --global core.editor "'C:\Program Files\Sublime Text\sublime_text.exe\' --wait"

> git config --get core.editor
'C:\Program Files\Sublime Text\sublime_text.exe' --wait

Обратите внимание, что я добавил дополнительные одинарные кавычки (апострофы) в путь до текстового редактора (помимо двойных кавычек). Это сделано из-за наличия в пути пробелов (если у вас их нет, то и кавычки не нужны). Без дополнительных кавычек редактор не запустится.

Также я добавил параметр —wait, который не позволит закрыться редактору, пока вы его сами не завершите. Без него в будущем возникла бы ошибка «aborting commit due to empty commit message» при использовании команды commit (ее мы пройдем позже).

8.5. Смена имени ветки по умолчанию

Если по какой-то причине вам захочется поменять слово master (название ветки по умолчанию) на что-то другое, например, сейчас идет тренд в пользу main, то выполните команду:


git config --global init.defaultBranch main

8.6. Корректное отображение русских букв

Для тех, кто использует Windows с именами для папок и файлов на русском языке, необходимо выполнить команду:


git config --global core.quotepath off

Если этого не сделать, то все сообщения, в которых фигурируют русские символы, будут нечитаемы.

Я переименовал src в срс и выполнил git status (ее мы пройдем позже). Вместо срс отобразилось «\321\201\321\200\321\201/».

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

Дополнительную информацию про настройку Git можно посмотреть по ссылке.

Заключение

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

Оцените статью, если она вам понравилась!

  • Как создать слайд шоу на компьютере windows 7
  • Как создать резервную точку восстановления системы windows 10
  • Как создать сертификат openvpn windows
  • Как создать свой установщик windows 10
  • Как создать скрытый файл на windows 10