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

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

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

Часть 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 .

Установите себе дополнительно анализаторы кода для JavaScript и PHP
Откройте вашу папку, которую создали ранее

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

Здесь будут располагаться все файлы вашего проекта
Здесь можно работать с Git-ом
Кнопка для создания нового файла
Кнопка для создания новой папки

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

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

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

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

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

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

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

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

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

Кнопка для просмотра изменений в файле. Необязательно нажимать, указал для справки
Добавляем наш файл для будущего commit
Пишем комментарий
Создаем commit
Отправляем наш 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 одним из двух способов:

Вы можете взять локальный каталог, который в настоящее время не находится под версионным контролем, и превратить его в репозиторий Git, либо
Вы можете клонировать существующий репозиторий 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 репозиторию, а также рассмотрим их достоинства и недостатки.

Источник

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

Что такое Github

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

Еще там есть:

Инструменты для управления проектами, например трекер задач и Kanban-доска;
Интеграция со сторонними сервисами, например CI/CD;
Markdown — язык разметки текстовых документов, с помощью которого можно создавать и хранить документацию.

На GitHub можно делиться своими проектами. Там активное сообщество разработчиков и больше 100 миллионов пользователей.

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

Рассмотрим, как загрузить проект на Github с помощью GitHub Desktop.

Шаг 1. Регистрация

Войдите в уже существующий аккаунт или зарегистрируйтесь. Можно выбрать:

публичный аккаунт — репозитории видят все пользователи;
приватный аккаунт — репозитории видят только одобренные участники.

Желательно также заполнить профиль. Расскажите про свой опыт, образование и навыки, чтобы привлечь потенциальных работодателей.

Регистрация на Github. Источник

Шаг 2. Создание репозитория на Github

Теперь необходимо создать файловое хранилище. В бесплатном аккаунте можно создавать любое число репозиториев, но объем данных не должен превышать 500 Мб. На платном тарифе можно получить больше места в хранилище.

Чтобы создать репозиторий:

Кликните «+» в правом верхнем углу экрана и нажмите New repository.
Придумайте имя хранилища и добавьте краткое описание.
Выберите приватный доступ (Private) или публичный (Public), если вы хотите поделиться своим проектом с другими.

Можно сразу создать README.md — это файл, который содержит:

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

Также можно добавить .gitignore — список файлов, которые не должны попасть в репозиторий на Github, например кэш и конфиденциальные данные. Отдельно можно указать лицензию, чтобы защитить права разработчика. После этого нажмите Create repository.

Создание репозитория на Github. Источник

Шаг 3. Подготовка локального проекта

Установите GitHub Desktop — это удобное приложение, которое упрощает работу с хранилищем. При первом запуске укажите ваш GitHub-аккаунт. После этого вам предложат:

Создать новый репозиторий на жестком диске;
Добавить существующий репозиторий с жесткого диске;
Клонировать репозиторий из интернета.

Github Desktop. Источник

Так у нас уже есть репозиторий на Github, скопируем его на ПК:

Выберите File → Clone repository.
Отметьте хранилище и укажите папку для сохранения.
Нажмите Clone.

Теперь репозиторий доступен локально. После этого у вас появятся вкладки:

Current Repository — показывает, какой репозиторий открыт в данный момент. Помогает быстро ориентироваться, с чем вы работаете, и легко переключаться между проектами.
Current Branch — отображает название ветки, с которой вы сейчас работаете. Ветки в Git позволяют работать над новыми функциями или исправлять ошибки, не меняя основной код.
Fetch origin — показывает список изменений из удаленного репозитория на GitHub. Полезно для тех, кто работает в команде и хочет знать о действиях других участников.

Шаг 4. Добавление новых файлов

Предположим, мы создали новый файл HTML. Чтобы сохранить изменения в репозитории, откройте GitHub Desktop.

Наш файл будет лежать в Changes. Напишите описание коммита и выберите Commit to main (или имя вашей текущей ветки). После этого можете перейти в History и просмотреть историю коммитов. Чтобы отправить изменения в репозиторий на Github, нажмите Push origin.

Теперь проекты в хранилище и на ПК полностью дублируют друг друга. При необходимости вы сможете их восстановить.

Репозиторий на Github. Источник

Шаг 5. Создание новой ветки

Если хотите поэкспериментировать, но не готовы вносить изменения в основной код, добавьте новую ветку: Current Branch → New Branch → Create New Branch.

Создание новой ветки. Источник

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

Как еще можно загрузить проект в репозиторий на Github

Также загрузить проект можно через консоль или редактор кода, например VS Code:

Авторизуйтесь в GitHub через Visual Studio Code.
Откройте Source Control (Контроль версий) в боковой панели.
Нажмите Initialize Repository, затем Publish to GitHub.
Назовите репозиторий и опубликуйте (Publish).

Этот метод подойдет для тех, у кого уже установлен Git.

Visual Studio Code. Источник

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

GitLens: упрощает работу с ветками и сохраняет историю изменений для отдельных файлов и строк.
Git History: предоставляет удобный интерфейс для просмотра истории коммитов проекта. Можно визуально просматривать ее в виде графа и фильтровать коммиты по автору, сообщению или дате.
Git Graph: предоставляет визуальную структуру репозитория. Можно увидеть все ветки репозитория и их связи, понять, как они взаимодействуют друг с другом.

Git Graph. Источник

Ошибки при загрузке проекта на GitHub

Чаще всего встречаются:

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

Отсутствие файла .gitignore: без него в репозиторий на Github могут попасть временные файлы, кэш и конфиденциальная информация.

Неинформативные коммиты: начинающие разработчики часто пишут неясные или чересчур короткие сообщения, например «изменения» или «обновление». Пишите информативные комментарии, которые объясняют, что было изменено и почему. Это поможет другим участникам.

Игнорирование лицензии: если не указать лицензию на проект, это может привести к юридическим проблемам и путанице, как можно использовать ваш код.

Загрузка большого количества данных: загрузка больших файлов увеличивает размер репозитория на Github и уменьшает его производительность. Для хранения изображения или видео используйте Git LFS (Large File Storage).

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

Отсутствие ветвления: работа в основной ветке может привести к конфликтам и потере данных. Создавайте отдельные ветки для новых функций или исправления ошибок.

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

Главное о том, как залить проект на гитхаб

GitHub — это большое сообщество разработчиков. На платформу можно загрузить свой проект и найти единомышленников;
Можно создать публичный или приватный аккаунт, если хотите, чтобы репозитории видели только одобренные участники;
Загрузка проекта на Github может привлечь потенциальных работодателей, заполните личный профиль, чтобы рассказать о себе больше;
Поделиться проектом на Github можно через GitHub Desktop, консоль или редактор кода, например VS Code;
Можно использовать плагины GitLens, Git History и Git Graph, которые упрощают взаимодействие с репозиторием.

Источник

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

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

Основы

Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). Изначально Git был создан Линусом Торвальдсом при разработке ядра Linux. Однако инструмент так понравился разработчикам, что в последствии, он получил широкое распространение и его стали использовать в других проектах. С его помощью вы можете сравнивать, анализировать, редактировать, сливать изменения и возвращаться назад к последнему сохранению. Этот процесс называется контролем версий.

Для чего он нужен? Ну во-первых, чтобы отследить изменения, произошедшие с проектом, со временем. Проще говоря, мы можем посмотреть как менялись файлы программы, на всех этапах разработки и при необходимости вернуться назад и что-то отредактировать. Часто бывают ситуации, когда, во вполне себе работающий код, вам нужно внести определенные правки или улучшить какой-то функционал, по желанию заказчика. Однако после внедрения нововведений, вы с ужасом понимаете, что все сломалось. У вас начинается судорожно дергаться глаз, а в воздухе повисает немой вопрос: “Что делать?” Без системы контроля версий, вам надо было бы долго напряженно просматривать код, чтобы понять как было до того, как все перестало работать. С Гитом же, все что нужно сделать — это откатиться на коммит назад.

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

Установка

Установить git на свою машину очень просто:

Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
```
sudo apt-get install git
```
Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:
```
brew install git
```

Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.

Настройка

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

git config --global user.name "My Name"
git config --global user.email myEmail@example.com

Теперь каждое наше действие будет отмечено именем и почтой. Таким образом, пользователи всегда будут в курсе, кто отвечает за какие изменения — это вносит порядок.
Git хранит весь пакет конфигураций в файле .gitconfig, находящемся в вашем локальном каталоге. Чтобы сделать эти настройки глобальными, то есть применимыми ко всем проектам, необходимо добавить флаг –global. Если вы этого не сделаете, они будут распространяться только на текущий репозиторий.
Для того, чтобы посмотреть все настройки системы, используйте команду:

git config --list

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

git config --global color.ui true
git config --global color.status auto
git config --global color.branch auto

Если вы не до конца настроили систему для работы, в начале своего пути — не беда. Git всегда подскажет разработчику, если тот запутался, например:

Команда git —help — выводит общую документацию по git
Если введем git log —help — он предоставит нам документацию по какой-то определенной команде (в данном случае это — log)
Если вы вдруг сделали опечатку — система подскажет вам нужную команду
После выполнения любой команды — отчитается о том, что вы натворили
Также Гит прогнозирует дальнейшие варианты развития событий и всегда направит разработчика, не знающего, куда двигаться дальше

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

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

Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:

$ mkdir Desktop/git_exercise/
$ cd Desktop/git_exercise/
$ git init

Командная строка должна вернуть что-то вроде:

Initialized empty Git repository in /home/user/Desktop/git_exercise/.git/

Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.

Определение состояния

status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:

$ git status
On branch master
Initial commit
Untracked files:
(use "git add ..." to include in what will be committed)
hello.txt

Сообщение говорит о том, что файл hello.txt неотслеживаемый. Это значит, что файл новый и система еще не знает, нужно ли следить за изменениями в файле или его можно просто игнорировать. Для того, чтобы начать отслеживать новый файл, нужно его специальным образом объявить.

Подготовка файлов

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

$ git add hello.txt

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

$ git add -A

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

$ git status
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached ..." to unstage)
new file: hello.txt

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

Фиксация изменений

Как сделать коммит

Представим, что нам нужно добавить пару новых блоков в html-разметку (index.html) и стилизовать их в файле style.css. Для сохранения изменений, их необходимо закоммитить. Но сначала, мы должны обозначить эти файлы для Гита, при помощи команды git add, добавляющей (или подготавливающей) их к коммиту. Добавлять их можно по отдельности:

git add index.html

git add css/style.css

или вместе — всё сразу:

git add .

Конечно добавлять всё сразу удобнее, чем прописывать каждую позицию отдельно. Однако, тут надо быть внимательным, чтобы не добавить по ошибке ненужные элементы. Если же такое произошло изъять оттуда ошибочный файл можно при помощи команды

git reset:

git reset css/style.css

Теперь создадим непосредственно сам коммит

git commit -m 'Add some code'

Флажок -m задаст commit message — комментарий разработчика. Он необходим для описания закоммиченных изменений. И здесь работает золотое правило всех комментариев в коде: «Максимально ясно, просто и содержательно обозначь написанное!»

Как посмотреть коммиты

Для просмотра все выполненных фиксаций можно воспользоваться историей коммитов. Она содержит сведения о каждом проведенном коммите проекта. Запросить ее можно при помощи команды:

git log

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

git show hash_commit

Ну а если вдруг нам нужно переделать commit message и внести туда новый комментарий, можно написать следующую конструкцию:

git commit --amend -m 'Новый комментарий'

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

Удаленные репозитории

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

1. Что такое удаленный репозиторий

Репозиторий, хранящийся в облаке, на стороннем сервисе, специально созданном для работы с git имеет ряд преимуществ. Во-первых — это своего рода резервная копия вашего проекта, предоставляющая возможность безболезненной работы в команде. А еще в таком репозитории можно пользоваться дополнительными возможностями хостинга. К примеру -визуализацией истории или возможностью разрабатывать вашу программу непосредственно в веб-интерфейсе.
Клонирование
Клонирование — это когда вы копируете удаленный репозиторий к себе на локальный ПК. Это то, с чего обычно начинается любой проект. При этом вы переносите себе все файлы и папки проекта, а также всю его историю с момента его создания. Чтобы склонировать проект, сперва, необходимо узнать где он расположен и скопировать ссылку на него. В нашем руководстве мы будем использовать адрес https://github.com/tutorialzine/awesome-project, но вам посоветуем, попробовать создать свой репозиторий в GitHub, BitBucket или любом другом сервисе:

git clone https://github.com/tutorialzine/awesome-project

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

git clone https://github.com/tutorialzine/awesome-project new-folder

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

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

# This is only an example. Replace the URI with your own repository address.

$ git remote add origin https://github.com/tutorialzine/awesome-project.git

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

3. Отправка изменений на сервер

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

$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/tutorialzine/awesome-project.git
* [new branch] master -> master

Эта команда немного похожа на git fetch, с той лишь разницей, что при помощи fetch мы импортируем коммиты в локальную ветку, а применив push, мы экспортируем их из локальной в удаленную. Если вам необходимо настроить удаленную ветку используйте git remote. Однако пушить надо осторожно, ведь рассматриваемая команда перезаписывает безвозвратно все изменения. В большинстве случаев, ее используют, чтобы опубликовать выгружаемые локальные изменения в центральный репозиторий. А еще ее применяют для того, чтобы поделиться, внесенными в локальный репозиторий, нововведениями, с коллегами или другими удаленными участниками разработки проекта. Подытожив сказанное, можно назвать git push — командой выгрузки, а git pull и git fetch — командами загрузки или скачивания. После того как вы успешно запушили измененные данные, их необходимо внедрить или интегрировать, при помощи команды слияния git merge.
В зависимости от сервиса, который вы используете, вам может потребоваться аутентифицироваться, чтобы изменения отправились. Если все сделано правильно, то когда вы посмотрите в удаленный репозиторий при помощи браузера, вы увидите файл hello.txt

4. Запрос изменений с сервера

Если вы сделали изменения в вашем удаленном репозитории, другие пользователи могут скачать изменения при помощи команды pull.

$ git pull origin master
From https://github.com/tutorialzine/awesome-project
* branch master -> FETCH_HEAD
Already up-to-date.

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

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

Вам не понравился один из ваших локальных Git-репозиториев и вы хотите стереть его со своей машины. Для этого вам всего лишь надо удалить скрытую папку «.git» в корневом каталоге репозитория. Сделать это можно 3 способами:

Проще всего вручную удалить эту папку «.git» в корневом каталоге «Git Local Warehouse».
Также удалить, не устраивающий вас, репозиторий можно на github. Открываете нужный вам объект и переходите в пункт меню Настройки. Там, прокрутив ползунок вниз, вы попадете в зону опасности, где один из пунктов будет называться «удаление этого хранилища».
Последний метод удаления локального хранилища через командную строку, для этого в терминале необходимо ввести следующую команду:

cd repository-path/
rm -r .git

Ветвление

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

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

1. Создание новой ветки

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch <name>

$ git branch amazing_new_feature

Это создаст новую ветку, пока что точную копию ветки master.

2. Переключение между ветками

Сейчас, если мы запустим branch, мы увидим две доступные опции:

$ git branch
amazing_new_feature
* master

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

$ git checkout amazing_new_feature

В Git ветка — это отдельная линия разработки. Git checkout позволяет нам переключаться как между удаленными, так и меду локальными ветками. Это один из способов получить доступ к работе коллеги или соавтора, обеспечивающий более высокую продуктивность совместной работы. Однако тут надо помнить, что пока вы не закомитили изменения, вы не сможете переключиться на другую ветку. В такой ситуации нужно либо сделать коммит, либо отложить его, при помощи команды git stash, добавляющей текущие незакоммиченные изменения в стек изменений и сбрасывающей рабочую копию до HEAD’а репозитория.

3. Слияние веток

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

$ git add feature.txt
$ git commit -m "New feature complete.”

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

$ git checkout master

Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).

$ git merge amazing_new_feature

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

$ git branch -d awesome_new_feature

Если хотите создать копию удаленного репозитория — используйте git clone. Однако если вам нужна только определенная его ветка, а не все хранилище — после git clone выполните следующую команду в соответствующем репозитории:

git checkout -b <имя ветки> origin/<имя ветки>

После этого, новая ветка создается на машине автоматически.

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

git branch -d local_branch_name

где флажок -d являющийся опцией команды git branch — это сокращенная версия ключевого слова —delete, предназначенного для удаления ветки, а local_branch_name – название ненужной нам ветки.
Однако тут есть нюанс: удалить текущую ветку, в которую вы, в данный момент просматриваете — нельзя. Если же вы все-таки попытаетесь это сделать, система отругает вас и выдаст ошибку с таким содержанием:

Error: Cannot delete branch local_branch_name checked out at название_директории

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

Дополнительно

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

1. Отслеживание изменений, сделанных в коммитах

У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:

Вывод git log

$ git log
commit ba25c0ff30e1b2f0259157b42b9f8f5d174d80d7
Author: Tutorialzine
Date: Mon May 30 17:15:28 2016 +0300
New feature complete
commit b10cc1238e355c02a044ef9f9860811ff605c9b4
Author: Tutorialzine
Date: Mon May 30 16:30:04 2016 +0300
Added content to hello.txt
commit 09bd8cc171d7084e78e4d118a2346b7487dca059
Author: Tutorialzine
Date: Sat May 28 17:52:14 2016 +0300
Initial commit

Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]

Вывод git show

$ git show b10cc123
commit b10cc1238e355c02a044ef9f9860811ff605c9b4
Author: Tutorialzine
Date: Mon May 30 16:30:04 2016 +0300
Added content to hello.txt
diff --git a/hello.txt b/hello.txt
index e69de29..b546a21 100644
--- a/hello.txt
+++ b/hello.txt
@@ -0,0 +1 @@
+Nice weather today, isn't it?

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

Вывод git diff

$ git diff 09bd8cc..ba25c0ff
diff --git a/feature.txt b/feature.txt
new file mode 100644
index 0000000..e69de29
diff --git a/hello.txt b/hello.txt
index e69de29..b546a21 100644
--- a/hello.txt
+++ b/hello.txt
@@ -0,0 +1 @@
+Nice weather today, isn't it?

Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.

2. Возвращение файла к предыдущему состоянию

Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита — использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:

$ git checkout 09bd8cc1 hello.txt

3. Исправление коммита

Если вы опечатались в комментарии или забыли добавить файл и заметили это сразу после того, как закоммитили изменения, вы легко можете это поправить при помощи commit —amend. Эта команда добавит все из последнего коммита в область подготовленных файлов и попытается сделать новый коммит. Это дает вам возможность поправить комментарий или добавить недостающие файлы в область подготовленных файлов.
Для более сложных исправлений, например, не в последнем коммите или если вы успели отправить изменения на сервер, нужно использовать revert. Эта команда создаст коммит, отменяющий изменения, совершенные в коммите с заданным идентификатором.
Самый последний коммит может быть доступен по алиасу HEAD:

$ git revert HEAD

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

$ git revert b10cc123

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

4. Разрешение конфликтов при слиянии

Помимо сценария, описанного в предыдущем пункте, конфликты регулярно возникают при слиянии ветвей или при отправке чужого кода. Иногда конфликты исправляются автоматически, но обычно с этим приходится разбираться вручную — решать, какой код остается, а какой нужно удалить.
Давайте посмотрим на примеры, где мы попытаемся слить две ветки под названием john_branch и tim_branch. И Тим, и Джон правят один и тот же файл: функцию, которая отображает элементы массива.
Джон использует цикл:

// Use a for loop to console.log contents.
for(var i=0; i<arr.length; i++) {
console.log(arr[i]);
}

Тим предпочитает forEach:

// Use forEach to console.log contents.
arr.forEach(function(item) {
console.log(item);
});

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

$ git merge tim_branch
Auto-merging print_array.js
CONFLICT (content): Merge conflict in print_array.js
Automatic merge failed; fix conflicts and then commit the result.

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:

Вывод

<<<<<<< HEAD // Use a for loop to console.log contents. for(var i=0; i<arr.length; i++) { console.log(arr[i]); } ======= // Use forEach to console.log contents. arr.forEach(function(item) { console.log(item); }); >>>>>>> Tim's commit.

Над разделителем ======= мы видим последний (HEAD) коммит, а под ним — конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

// Not using for loop or forEach.
// Use Array.toString() to console.log contents.
console.log(arr.toString());

Когда все готово, нужно закоммитить изменения, чтобы закончить процесс:

$ git add -A
$ git commit -m "Array printing conflict resolved."

Как вы можете заметить, процесс довольно утомительный и может быть очень сложным в больших проектах. Многие разработчики предпочитают использовать для разрешения конфликтов клиенты с графическим интерфейсом. (Для запуска нужно набрать git mergetool).

5. Настройка .gitignore

В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore

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

Вот хорошие примеры файлов, которые нужно игнорировать:

Логи
Артефакты систем сборки
Папки node_modules в проектах node.js
Папки, созданные IDE, например, Netbeans или IntelliJ
Разнообразные заметки разработчика.

Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:

*.log
build/
node_modules/
.idea/
my_notes.txt

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

Git bash и git.io

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

Git Bash(Bourne Again Shell) — это приложение, являющееся эмулятором командной строки и предоставляющее, операционной системе, некоторые распространенные утилиты bash и собственно саму систему Git. Это терминал, используемый для взаимодействия с персональным компьютером, посредством письменных команд.
URL-адреса хранилищ на Гитхабе могут быть довольно длинными, из-за больших имен репозиториев и файлов. Работать с такими ссылками очень не удобно. Поэтому сайт github.io создал git.io — неплохой сервис по преобразованию этих длинных и беспорядочных URL-адресов в более короткие и понятные. Сайт был создан в 2011 году и вплоть до недавнего времени отлично справлялся со своими обязанностями. Однако в начале этого года компания Гитхаб, из-за участившихся попыток хакеров использовать сайт в злонамеренных целях, остановила работу сервиса, а чем известила пользователей в своем блоге. Разработчики популярного ресурса рекомендуют пользоваться другими URL-cutter’ами, пока работа сервиса не будет налажена.

Заключение.

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

Официальная документация, включающая книгу и видеоуроки – тут.
“Getting git right” – Коллекция руководств и статей от Atlassian – тут.
Список клиентов с графическим интерфейсом – тут.
Онлайн утилита для генерации .gitignore файлов – тут.

Оригинал статьи доступен на сайте http://tutorialzine.com

Другие статьи по теме

10 полезных Git команд, которые облегчат работу

Шпаргалка по Git, в которой представлены основные команды

Источник

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

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

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

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

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

Адрес электронной почты. Если на почту уже был зарегистрирован аккаунт, на странице появится сообщение об ошибке: «Email is invalid or already taken».

Пароль. Система рекомендует использовать для пароля последовательность из 15 символов или 8, но с использованием хотя бы одной цифры и строчной буквы.

Имя пользователя. «Юзернейм» должен быть уникальным. При этом он не может начинаться или заканчиваться дефисом.

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

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

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

Установка Git

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

Терминал

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

Mac OS

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

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

git --version

Windows

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

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

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

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

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

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

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

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

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

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

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

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

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 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. Откроется встроенный редактор кода.

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

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

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

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

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

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

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

git branch dev

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

git branch

Видно, что выбрана ветка main, то есть все коммиты загружаются в нее. Чтобы работать с веткой 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:

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

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

Создание веток через 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 и сделаем форк.

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

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

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

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

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

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

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

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

Источник