Git github: GitHub — git/git: Git Source Code Mirror

Шпаргалка по Git от GitHub

Установка Git

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

GitHub Desktop

desktop.github.com

Дистрибутивы Git для систем Linux и POSIX доступны на официальном сайте Git SCM.

Git для всех платформ

git-scm.com

Первоначальная настройка

Настройка информации о пользователе для всех локальных репозиториев

$ git config --global user.name "[имя]"

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

$ git config --global user.email "[адрес электронной почты]"

Устанавливает адрес электронной почты, который будет отображаться в информации о выполняемых вами коммитах

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

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

$ git init [название проекта]

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

$ git clone [url-адрес]

Скачивает репозиторий вместе со всей его историей изменений

Внесение изменений

Просмотр изменений и создание коммитов (фиксация изменений)

$ git status

Перечисляет все новые или изменённые файлы, которые нуждаются в фиксации

$ git diff

Показывает различия по внесённым изменениям в ещё не проиндексированных файлах

$ git add [файл]

Индексирует указанный файл для последующего коммита

$ git diff --staged

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

$ git reset [файл]

Отменяет индексацию указанного файла, при этом сохраняет его содержимое

$ git commit -m "[сообщение с описанием]"

Фиксирует проиндексированные изменения и сохраняет их в историю версий

Коллективная работа

Именованные серии коммитов и соединение результатов работы

$ git branch

Список именованных веток коммитов с указанием выбранной ветки

$ git branch [имя ветки]

Создаёт новую ветку

$ git checkout [имя ветки]

Переключается на выбранную ветку и обновляет рабочую директорию до её состояния

$ git merge [имя ветки]

Вносит изменения указанной ветки в текущую ветку

$ git branch -d [имя ветки]

Удаляет выбранную ветку

Операции с файлами

Перемещение и удаление версий файлов репозитория

$ git rm [файл]

Удаляет конкретный файл из рабочей директории и индексирует его удаление

$ git rm --cached [файл]

Убирает конкретный файл из контроля версий, но физически оставляет его на своём месте

$ git mv [оригинальный файл] [новое имя]

Перемещает и переименовывает указанный файл, сразу индексируя его для последующего коммита

Игнорирование некоторых файлов

Исключение временных и вторичных файлов и директорий

Git будет игнорировать файлы и директории, перечисленные в файле

.gitignore с помощью wildcard синтаксиса

$ git ls-files --others --ignored --exclude-standard

Список всех игнорируемых файлов в текущем проекте

Сохранение фрагментов

Сохранение и восстановление незавершённых изменений

$ git stash

Временно сохраняет все незафиксированные изменения отслеживаемых файлов

$ git stash pop

Восстанавливает состояние ранее сохранённых версий файлов

$ git stash list

Выводит список всех временных сохранений

$ git stash drop

Сбрасывает последние временно сохранённыe изменения

Просмотр истории

Просмотр и изучение истории изменений файлов проекта

$ git log

История коммитов для текущей ветки

$ git log --follow [файл]

История изменений конкретного файла, включая его переименование

$ git diff [первая ветка]...[вторая ветка]

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

$ git show [коммит]

Выводит информацию и показывает изменения в выбранном коммите

Откат коммитов

Удаление ошибок и корректировка созданной истории

$ git reset [коммит]

Отменяет все коммиты после заданного, оставляя все изменения в рабочей директории

$ git reset --hard [коммит]

Сбрасывает всю историю вместе с состоянием рабочей директории до указанного коммита.

Синхронизация с удалённым репозиторием

Регистрация удалённого репозитория и обмен изменениями

$ git fetch [удалённый репозиторий]

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

$ git merge [удалённый репозиторий]/[ветка]

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

$ git push [удалённый репозиторий] [ветка]

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

$ git pull

Загружает историю из удалённого репозитория и объединяет её с локальной. pull = fetch + merge

Знакомство с Git и GitHub: руководство для начинающих | by Olga Sayfudinova | NOP::Nuances of Programming

Ищите, с чего бы начать изучение Git и GitHub? Хотите поработать с другими? Усердно трудитесь над проектом? Или вдруг заметили, что заслужить уважение среди технарей можно своим присутствием на GitHub?

…а, может, вам просто захотелось поучаствовать в своем первом open-source проекте?

Тогда эта статья специально для вас!

На самом деле, в Git нет ничего сложного. Если вы быстро читаете и не тратите уйму времени на установку и регистрацию, то начать работать с GitHub вы сможете уже через 10 минут.

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

Если вы сможете все это сделать, то можно считать, что вы успешно справились с задачей. А еще вы сможете поучаствовать в своем первом open-source проекте — Стене на GitHub.

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

Git — это система управления версиями, которая пришлась по душе практически всем — от разработчиков до дизайнеров. GitHub можно считать соцсетью для хранения кода. Это настоящая Мекка для технарей. Здесь вы можете попрактиковаться в разработке и придумать что-то свое, найти множество open-source проектов, передовых технологий, различных функций и дизайнов.

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

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

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

Если в статье вы видите команду с угловыми скобками: < > , то смело удаляйте эти скобки и меняйте их содержимое на нужный вам текст.

Пример: git add <имя_файла>. Здесь вы можете написать нечто подобное: git add hello_world.py . Это означает, что вы хотите добавить в репозиторий файл под названием hello_world.py.

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

git clone
git status
git add
git commit -m “ “
git push

Затем к ним добавим еще вот эти:

git init
git branch
git merge
git checkout

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

Не лишней будет и вот такая команда:

git help

О ней мы также поговорим ниже.

(Если вы работаете на Mac, то у вас уже установлен терминал. Нажмите на иконку с лупой в верхнем правом углу экрана и напечатайте слово terminal).

Шаг 1: Регистрация и установка

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

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

git config — global user.name “<ваше_имя>”

замените <ваше_имя> на свое имя в кавычках. Можете написать все, что угодно. Если хотите задать имя только для одного репозитория, то удалите из команды слово global.

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

git config — global user.email “<адрес_почты@email.com>”

При желании можете скрыть свой электронный адрес. Это сделать несложно, подробнее написано здесь. По сути, вам нужно проставить 2 галочки в своем GitHub-аккаунте.

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

Начнем с создания нового репозитория на сайте GitHub. Вы также можете выполнить git init и создать новый репозиторий из директории проекта.

Репозиторий состоит из трех «деревьев». Первое «дерево» — это рабочая директория, в которой хранятся актуальные файлы. Второе — это index или область подготовленных файлов. А еще есть head — указатель на ваш последний коммит.

Вариант 1. Я уже знаком с терминалом

Вот как начать работу с Git из терминала.

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

git init

Если хотите инициализировать проект со всеми файлами из директории проекта, то выполните команду

git init

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

cd new_project
git init

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

git add <имя_первого_файла>

или добавьте сразу все файлы через:

git add .

Создать коммит с этими изменениями можно через команду:

git commit -m “<сообщение_коммита>”

Если изменения вас устраивают, напишите:

git push

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

git status

При внесении изменений следует обновить и сами файлы:

git add <имя_файла>

или

git add — all

Создайте коммит, добавьте нужное сообщение и отправьте этот коммит в репозиторий.

Вот и все! Теперь вы можете инициализировать репозиторий, создавать коммиты с файлами и сообщениями, а также отправлять коммиты в ветку master.

Если с этим все понятно, то переходите к части 2: «Учимся работать с другими», в которой рассматривается градация веток и совместная работа над проектами.

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

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

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

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

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

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

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

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

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

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

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

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

Изменение файла на GitHubПодготовка коммита с изменениями

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

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

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

Подайте мне вот этот проект!

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

Для клонирования репозитория на компьютер перейдите в репозиторий на GitHub и нажмите большую зеленую кнопку под названием Clone or download (разумеется, вы можете просто скачать репозиторий и избежать всех заморочек с терминалом. Но я в вас верю, поэтому не будем сдаваться!). Проследите, чтобы появилась надпись Clone with HTTPS. Теперь нажмите на иконку буфера обмена для копирования-вставки (либо выделите ссылку и скопируйте ее).

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

Откройте терминал и перейдите в директорию для копирования репозитория. Например, для перехода на Рабочий стол напечатайте вот это:

cd Desktop

Затем клонируйте туда репозиторий по следующей команде:

git clone <то,_что_вы_только_что_скопировали>

Все просто! Не забудьте изменить информацию в угловых скобках на нужную вам. И удалите сами скобки < >.

Если вы не очень хорошо ориентируетесь в терминале, то переход по директориям можно осуществлять через команду cd. Например, откройте терминал и напечатайте ls для отображения перечня доступных директорий. Вполне возможно, что в этом списке вы сразу увидите директорию Desktop. Либо напечатайте cd Desktop. Далее выполните команду git clone и склонируйте репозиторий на Рабочий стол.

Бывает и так, что вместо перечня расположений, вы видите различные имена пользователей. Тогда до того, как перейти в Desktop, вам потребуется выбрать нужного пользователя через команду cd <пользователь> (замените <пользователь> на нужное вам имя). Затем снова напечатайте ls, чтобы увидеть весь список. И вот теперь, увидев в списке Desktop, смело печатайте cd Desktop. Сейчас уже можно выполнять git clone!

Если вдруг в терминале вы захотите «откатиться» на шаг назад, то напишите cd ..

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

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

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

Вот, чем мы займемся:

git status
git add
git commit -m “ “
git push

Но ничего сложного здесь нет!

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

Проверьте статус проекта.

Откройте терминал и перейдите в папку репозитория. Для проверки обновлений выполните:

git status

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

git add <имя_файла>

Либо все сразу:

git add — all

или даже:

git add .

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

Процесс создания коммитов с изменениями начинается с выполнения команды:

git commit -m “<сообщение_о_коммите>”

Коммиты изменений добавляются в head (указатель), а не в удаленный репозиторий. Не забудьте заменить текст в скобках и убрать <>. После внесения изменений создается снимок состояния репозитория, для чего используется командаcommit. А через –m добавляется сообщение об этом снимке.

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

Теперь ваши изменения сохранены в указателе локальной копии проекта. Для отправки изменений на удаленный репозиторий выполните команду:

git push

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

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

Итог: у вас есть свой GitHub репозиторий, вы научились добавлять и изменять в нем файлы.

Читайте также:

Интеграция с Github — Введение в Git

На текущий момент у нас есть репозиторий с двумя коммитами. Содержимое директории hexlet-git выглядит так:

hexlet-git$ ls -a
.git
PEOPLE.md
README.md

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

1. Создайте репозиторий на Гитхабе. Назовите его hexlet-git. Важно, чтобы репозиторий создавался пустым, поэтому не отмечайте галочки, добавляющие файлы.

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

   Выполните эти шаги:

   # Подробнее эти команды мы разберём позже
   hexlet-git$ git branch -M main
   hexlet-git$ git remote add origin [email protected]:<ИМЯ НА ГИТХАБЕ>/hexlet-git.git
   hexlet-git$ git push -u origin main
   

3. Обновите страницу с репозиторием на github.com. Изучите её интерфейс и содержимое репозитория. Обратите внимание на то, что директория .git отсутствует. Почему это так, мы узнаем в одном из следующих уроков.

После этой команды репозиторий, созданный на github.com, «соединяется» с локальным репозиторием

hexlet-git. В данном месте может возникнуть вопрос. Почему соединяется? Разве это не один и тот же репозиторий?

В действительности это разные репозитории. Git относится к так называемым распределённым системам контроля версий. У git нет какого-то центрального места, где бы лежал один главный репозиторий, а разработчики работали с ним со своих компьютеров. В git у каждого разработчика и даже на Github находится свой собственный полноценный репозиторий. Эти репозитории git связывает между собой общей историей и возможностью обмениваться изменениями. В примере выше именно команда git push отправляет изменения во вновь созданный репозиторий.

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

Теперь не важно, какие изменения делаются в локальном репозитории, на Github все коммиты попадут только после команды git push. Не забывайте делать её, бывает такое, что разработчик случайно удаляет локальный репозиторий, забыв запушить (от слова push) изменения.

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

hexlet-git с вашего компьютера.

Клонирование

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

Клонирование — базовая операция при работе с удалёнными репозиториями. Проекты, над которыми работают программисты, всегда находятся в системах, подобных Github. Для работы с ними нужно клонировать репозиторий к себе на компьютер. Делается это с помощью команды git clone. Полную команду для клонирования можно получить на странице репозитория. Для этого нажмите большую зелёную кнопку Code и скопируйте содержимое.

$ git clone [email protected]:<ИМЯ НА ГИТХАБЕ>/hexlet-git.git
$ cd hexlet-git
$ ls -la

# Если эта операция проходит первый раз
# То вероятно вы увидите такое подобное сообщение
The authenticity of host github.com cannot be established. RSA key fingerprint is SHA256: хххххххххх Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added github.com (RSA) to the list of known hosts.
# Наберите yes и нажмите Enter

Мы получили точную копию репозитория, который был у нас до удаления директории hexlet-git.

Получение изменений с Github

Разработчики не только отправляют изменения на Гитхаб, но и забирают изменения оттуда. Чаще всего это изменения, сделанные другими разработчиками проекта, но не обязательно. Бывает такое, что один разработчик работает над одним проектом с разных компьютеров, на каждом из которых своя собственная копия репозитория (git работает только так). В таком случае, перед началом работы нужно всегда выполнять команду

git pull --rebase, которая скачивает из внешнего репозитория новые коммиты и добавляет их в локальный репозиторий.

Обычно, в статьях пишут, что достаточно вызывать git pull, но это может приводить к созданию ненужных merge-коммитов, ухудшающих историю изменений. Правильная работа с git pull требует знания таких вещей, как ветвление и git rebase. Они довольно сложны для новичков и рассматриваются позже, когда появится хоть какой-то опыт работы с git.

Итого

Подведём некоторый итог. Мы создали репозиторий с несколькими коммитами. Этот репозиторий добавлен на Гитхаб и может быть склонирован для дальнейшей разработки. Какую пользу из git мы можем извлечь к текущему моменту? У нас есть запасная копия (бекап) кода на сайте Github. Как минимум, не страшно потерять код. Теперь его легко восстановить при случае и поделиться с другими.

Отдельно стоит сказать, что Гитхаб это хоть и самая популярная, но не единственная площадка для хостинга репозиториев. Кроме него особенно известны Bitbucket и Gitlab. Последний можно даже поставить к себе на сервер и «хостить» репозитории внутри своей компании, что многие и делают по соображениям безопасности или экономии.

Самостоятельная работа

1. Выполните все шаги из урока
2. Добавьте новый файл NEW.md с произвольным содержимым в репозиторий (нужно выполнить коммит)
3. Залейте изменения на Github с помощью git push
4. Обновите страницу репозитория на Github. Там должен появиться последний коммит, то есть те изменения, которые были им совершены

---

Дополнительные материалы

1. Цикл git-разработки (init, commit, push on Github)
2. GitHub — Настройка и конфигурация учетной записи

---

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты.

Ошибки, сложный материал, вопросы >

Нашли опечатку или неточность?

Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.

Что-то не получается или материал кажется сложным?

Загляните в раздел «Обсуждение»:

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

Об обучении на Хекслете

Заливаем гит репозиторий на гитхаб

Всем привет. В прошлом уроке мы создали базовый репозиторий гита и сделали несколько коммитов. Сейчас мы будем заливать нашу работу в гитхаб. Зачем это нужно? Хранить гит проект на своей машине конечно хорошо, но не надежно и не удобно. Для этого используют разные сервисы, где можно хранить свой проект и в любой момент слить его на любую машину, что очень удобно. Самый популярный из этих сервисов github.com. С ним мы и будем работать.

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

Для начала вам понадобится завести аккаунт на гитхаб. У меня аккаунт уже есть, поэтому я нажимаю New Repository. И указываю имя learning_git. И нажимаю Create repository.

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

В нашем случае настройка должна стоять на HTTS. И нас интересует push существующего репозитория. Для этого копируем первую строчку в консоль проекта.

git remote add origin https://github.com/monsterlessons/learning_git.git

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

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

git remote -v

И оно нам выводит репозиторий, который мы добавили.

Теперь давайте вставим вторую строчку.

git push -u origin master

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

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

Мы видим список файлов и название последнего коммита который менял этот файл. Мы можем кликнуть на файл и посмотреть его содержимое. Мы можем нажать history и увидеть коммиты, которые меняли этот файл. Нажав на любой из коммитов мы видим изменения, которые были сделаны, так же как мы смотрели изменения локально с помощью команды git show.

И напоследок в этом уроке еще 2 команды. Первая команда это

git pull

Все что она делает, это сливает в проект новые изменения если они есть из удаленного репозитария. В нашем случае с гитхаба. В нашем случае оно написало что проект up to date так как у нас последние изменения. Но если мы вы дома сделали какие-то изменения, запушили, пришли на работу и написали бы git pull, то оно бы стянуло изменения, которые вы сделали в проекте дома, если вы конечно не забыли их запушить.

Вторую команду вы впринципе уже видели когда мы пушили наши изменения на гитхаб. Это команда

git push

Это очень популярная команда. Если вы хотите запушить ваши изменения на сервер, то вы всегда ее изпользуете. Давайте создадим файл 2.js и запушим его на гитхаб.

touch 2.js
git add .
git commit -m "Added 2.js"
git push

Если теперь мы обновим страницу в браузере, то увидим что у нас стало 4 коммита, а в списке файлов появился 2.js.

Разница между Git и GitHub

Существует ряд очевидных различий между Git и GitHub .

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

Нет ползучести области с Git

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

Дополнительные функции GitHub

основной принцип GitHub ‘value-add’ заключается в том, что он предоставляет платформу на основе cloud для Git. Это само по себе потрясающе. Кроме того, GitHub также предлагает:

• простое отслеживание задач
• a GitHub настольное приложение
• онлайн-редактирование файлов
• правила защиты ветки
• функции запроса на вытягивание
• организационные инструменты
• пределы взаимодействия для горячих голов
• поддержка эмодзи!!! :octocat: :+1:

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

Git и GitHub конкуренты

Иногда, когда дело доходит до различия между Git и GitHub, я думаю, что хорошо посмотреть, с кем они конкурируют. Git конкурирует на плоскости с такими инструментами, как Mercurial, Subversion и RTC, в то время как GitHub больше в пространстве SaaS конкурирует с cloud поставщиками, такими как GitLab и BitBucket Atlassian.

Не требуется GitHub

Одна вещь, о которой я всегда люблю напоминать людям, заключается в том, что вам не нужно GitHub, GitLab или BitBucket, чтобы использовать Git. Git был выпущен в 2005 году? GitHub появился на сцене только в 2007 или 2008 году, поэтому крупные организации занимались распределенным контролем версий с Git задолго до появления поставщиков хостинга cloud. Так что Git прекрасно сам по себе. Ему не нужна услуга хостинга cloud, чтобы быть эффективным. Но в то же время наличие поставщика PaaS, безусловно, не повредит.

Работа с рабочим столом GitHub

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

Я не слишком впечатлен этим инструментом, так как, как только вы узнаете Git, эти вещи не так уж трудно сделать в Bash shell, но это вариант.

Про Git, Github и Gitflow простыми словами

Не самое исчерпывающее, но точно вполне доходчивое руководство по Git, Github и Gitflow – для тех, кого эти слова смущают, хотя не должны.

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

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

Git – это распределенная система контроля версий (version control system – VCS).

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

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

К слову, Git создал вот этот обходительный джентельмен:

Линус Торвальдс, создатель Git и Linux, передает привет Nvidia

Для начала, убедитесь, что у вас установлен Git.

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

Откройте командную строку, и перейдите в Desktop (да, будем оригинальны), а там создайте каталог (например, proglib).

Теперь, проходим в новый каталог и выполняем git init.

Все, у нас есть пустой репозиторий.

Давайте создадим простой README.md файл, что-то вроде:

# Proglib
Hello, readme please

и сохраним.

git status – простая команда, которая будет регулярно использоваться. Она показывает информацию о статусе проекта в git. Если вы выполните ее в каталоге proglib, будет видно, что файл README.md не отслеживается git’ом.

Чтобы добавить файл в контроль, используем команду git add README.md. Ну а если нужно добавить сразу много файлов, можно сказать git add . (то есть буквально add all).

Если выпонить git status еще раз, мы увидим, что теперь в системе появился новый файл, который мы добавили.

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

git commit -m "Added the README.md file»

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

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

Нажмите кнопку Start a project и задайте проекту имя, остальные настройки можно оставить по умолчанию.

Так как мы только что создали репозиторий, будем использовать вариант …or push an existing.

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

Давайте так и сделаем. Выполните в консоли git checkout -b new_feature. Эта команда создаст новую ветку с названием new_feature от ветки мастер (или от любой вашей текущей ветки) и выполнит переход на новую ветку.

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

git add .
git commit -m "New feature changes"
git checkout master
git merge new_feature

Gitflow

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

Но есть один подход, который популярен в сообществе. Знакомьтесь, популярная модуль управления ветками Gitflow:

Схема выглядит беспорядочно, когда видишь ее впервые, так что пойдем по порядку. У нас есть две основные ветки: master и develop.

В ветке master содержится ровно тот же код, что и в рабочей (читай, продакт) версии проекта. А вся работа делается в ветке develop.

Во время работы на основе develop создаются так называемые feature-ветки. Их может быть неограниченное количество.

Далее, у нас есть ветка release, которая используется для подготовки к новому релизу проекта.

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

Вот как в теории, происходит рабочий процесс в Gitflow:

1. Создается репозиторий
2. Репозиторий инициализируется
3. Начинается работа на ветке develop
4. Возникает необходимость опробовать новую штуку – создается feature-ветка и делаются коммиты
5. Закончив работу на feature-ветке, вы сливаете ее с develop
6. Если вы довольны текущей версией, но хотите продолжить работу, создается ветка release, куда перемещается текущая версия. Правка багов будет происходить на этой же ветке.
7. Когда с веткой release покончено, время слить ее в master и продолжить работу с develop
8. Кроме того, этот момент можно отметить на master-ветке

Проделаем описанное выше шаг за шагом, но для начала убедитесь, что у вас есть gitflow-avh – инструмент для работы с Gitflow. На маке его можно установить с помощью homebrew:

brew install git-flow-avh

gitflow-avh  – это коллекция расширений для git, которая помогает избежать многих повторяющихся операций и вообще делает жизнь проще (это не точно). К примеру, при работе с feature-веткой, утилита проверит, слилась ли она в develop и удалит ее, если все прошло хорошо. Конечно, можно следовать модели Gitflow и самостоятельно, делая операции руками, но ведь проще же использовать готовое решение, так?

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

Далее будет несколько вопросов, но если оставить опции по умолчанию, эта команда просто создаст и назовет ветки в соответствие с моделью Gtiflow.

Когда все закончится, вы увидите, что находитесь на ветке develop. Теперь, создадим новую feature-ветку:

git-flow feature start new_docs

Затем, откроем README.md и внесем изменения. После, сделаем коммит:

git add .
git commit -m "Added new documentation»

Теперь, если мы всем довольны, закончим с этой веткой:

git-flow feature finish new_docs

Как можно видеть в выводе в консоли, эта команда сделала следующее:

1. Слила ветки new_docs и develop
2. Удалила new_docs
3. Выполнила переход на ветку develop, чтобы можно было продолжать работу

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

Для начала, необходимо выполнить команду:

git-flow release start 2.0

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

Когда работа закончена, просто напишем:

git-flow release finish 2.0

Вам нужно будет добавить несколько сообщений и меток, а потом утилита сделает следующее:

1. Сольет release и master
2. Пометит release как 2.0
3. Сольет release и develop
4. Удалит release
5. Выполнит переход на develop

Иногда совместная работа напоминает классику:

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

Но даже если вы хорошо знаете человека, вам не всегда может понравится, что кто-то делает коммиты в мастер без вашего ведома. Для таких случаев в github сущестуют pull-request’ы и code review.

Работает это следующим образом: вы делаете какое-то улучшение или фикс на featire-ветке, делаете pull request, кто-то из старших разработчиков, курирующих проект смотрит ваш код (читай, делает code review), возможно, делает какие-то замечания и, в конечном итоге добавляет ваш код в мастер-ветку (или куда-то еще).

На деле отношение к код ревью может быть разным. Буквально, от

до

а иногда даже

И как же к относится к code review? Кончено, это очень важная штука и нужно иметь терпение и делать ревью всех пул реквестов, если речь идет о вашем проекте, например. В долгосрочной перспективе это окупится. И, конечно, легко сказать «just do it», но в некоторых случаях сложившиеся традиции в команде разработчиков могут заставить пересмотреть свое отношение к некоторым вещам.

Создадим новую feature-ветку:

git-flow feature start NewFeatureDocs

Повторим процесс изменения документа и создания коммита.

А теперь сделаем кое-что новенькое:

git-flow feature publish NewFeatureDocs

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

Теперь, нажмите кнопку Compare & pull request:

Здесь можно добавить комментарий к пул-реквесту.

На этом моменте, кто-то из вашей команды должен прийти и проверить ваш код. Вы даже можете дать об этом знать кому следует через инструмент управления проектом, которым ваша команда пользуется (JIRA, Trello, Leankit, Kanbanflow, etc) добавив таск/карточку в соответствующую колонку.

Когда пул-реквест будет подтвержден, вы как автор, должны сделать следующее:

git-flow feature finish NewFeatureDocs

Вы увидите, что Github закрыл пул-реквест и удалил ветку.

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

Использование Git и GitHub — Код

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

GitHub где хранятся репозитории MODX Git. GitHub — это сервис для «безопасного размещения исходного кода и совместной разработки», но он также является социальной сетью для разработчиков. Подробнее о хостинг репозитория GitHub но также не забудьте добавить в закладки сайт Git Reference.

Обзор¶

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

Форк¶

Сначала вы создадите форк хранилища кода MODX для своей учетной записи GitHub. Это «твой форк». Вы будете публиковать ваш вклад (коммиты) в ваш код, а не напрямую в репозиторий modxcms. (Это то, что делает Git распределенными, тогда как SVN централизован вокруг одного репозитория.) Затем, для работы с вашим форком, вам понадобится локальная копия или ее clone.

Вот Учебник GitHub по созданию репо и созданию его локального клона.

Ветки и код¶

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

git checkout -b bug-1111

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

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

git push myRepo bug-1111

Заметка: Убедитесь, что ваша работа и ваши коммиты основаны на «свежем» коде — это поможет вам избежать проблем и помогут интеграторам понять, проанализировать и интегрировать (или отозвать) вашу работу.

Pull Request¶

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

Руководство для участников сообщества¶

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

Больше¶

1. Руководство для участников сообщества
2. Git FAC (часто используемые команды)
3. Руководство участника xPDO GitHub

Связанные¶

GitHub — git / git: зеркало исходного кода Git

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

Git — это проект с открытым исходным кодом, охватываемый GNU General Public Лицензия версии 2 (некоторые части находятся под разными лицензиями, совместим с GPLv2). Первоначально он был написан Линусом. Торвальдса с помощью группы хакеров по сети.

Пожалуйста, прочтите файл INSTALL для получения инструкций по установке.

Многие онлайн-ресурсы Git доступны по адресу https://git-scm.com/ включая полную документацию и инструменты, связанные с Git.

Для начала см. Documentation / gittutorial.txt, затем см. Documentation / giteveryday.txt для полезного минимального набора команд и Documentation / git- .txt для документации по каждой команде. Если git был установлен правильно, то руководство также можно читать с помощью man gittutorial или git help tutorial , а документацию по каждой команде с помощью man git- или git help .

Пользователи CVS могут также захотеть прочитать Documentation / gitcvs-migration.txt. ( man gitcvs-migration или git help cvs-migration , если git установлены).

Обсуждение пользователей и разработка Git происходит на Git. список рассылки — каждый может публиковать отчеты об ошибках, функция запросы, комментарии и патчи на [email protected] (читать Documentation / SubmittingPatches для получения инструкций по отправке исправлений). Чтобы подписаться на список, отправьте электронное письмо с просто «подписаться git» в тело мажордому @ vger.kernel.org. Архивы списков рассылки доступно по адресу https://lore.kernel.org/git/, http://marc.info/?l=git и другие архивные сайты.

Вопросы, относящиеся к безопасности, следует раскрывать в частном порядке список рассылки Git Security [email protected].

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

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

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

Git · GitHub

Git · GitHub

Репозиторий

• мерзавец

  Git Source Code Mirror — это репозиторий только для публикации, и все запросы на вытягивание игнорируются.Пожалуйста, следуйте процедуре Documentation / SubmittingPatches для любых ваших улучшений.

  C 21 820 38 655 7 58 Обновлено 14 июля 2021 г.

• htmldocs

  Готовая HTML-документация Git

  HTML 71 67 0 0 Обновлено 14 июля 2021 г.
• Рубин Массачусетский технологический институт 1,058 1,851 40 (Требуется помощь по 2 вопросам) 7 Обновлено 13 июля 2021 г.
• CSS 270 211 15 1 Обновлено 29 июня 2021 г.
• HTML 351 900 5 5 Обновлено 19 мая 2021 г.

• gitscm-старый В архиве

  Домашняя страница Git, которая потрясает — из файла git.or.cz крутизна

  HTML 83 164 2 0 Обновлено 16 ноября 2018 г.
• C 28 год 22 0 0 Обновлено 23 мая 2017 г.

Наиболее часто используемые темы

Загрузка…

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

Где мир создает программное обеспечение · GitHub

GitHub: Где мир создает программное обеспечение · GitHub

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

65+ миллионов

Разработчики

3+ миллиона

Организации

200+ миллионов

Репозитории

Создавайте как лучшие с GitHub Enterprise

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

Связаться с отделом продаж git checkout -b origin добавить экраны статуса

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

• Проверка кода встроена. Запросы на вытягивание охватывают весь процесс проверки: предлагать изменения, просматривать код, запрашивать ввод, вносить предложения и подписываться в одном месте.

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

• git merge добавить экраны статуса

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

Доступно для iOS и Android

••• трепать

                      ➜ ~ gh pr статус
                      Соответствующие запросы на вытягивание в cli / cli

                      Текущая ветка
                      Нет запроса на перенос, связанного с [main]

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

                      Запрос на проверку кода у вас
                      # 1401 Правильно обрабатывать и устанавливать пустые поля...
                      [octocat: emptyBody]
                      ✓ Прохождение проверок
                      # 1357 Добавлены шаги подтверждения риска ...
                      [octocat: подтверждения]
                      x 1/3 неудачных проверок
                      ➜ ~
                     

Работайте, как хотите. Поместите на него графический интерфейс с помощью GitHub Desktop или оставайтесь в командной строке с помощью GitHub CLI.

Доступно для macOS, Windows и Linux *

* Интерфейс командной строки GitHub доступен в macOS, Windows и Linux
* Рабочий стол GitHub доступен в macOS и Windows

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

Узнать больше о пространствах кодов GitHub

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

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

Настройте по своему желанию. Добавьте свои любимые расширения VS Code, создайте файл конфигурации devcontainer, установите новые темы и измените настройки.

Автоматизируйте что угодно с помощью GitHub Actions

Узнать больше о действиях GitHub

Настройте CI / CD, улучшите DevOps и создайте сценарий всего рабочего процесса с помощью GitHub Actions. Запускайте автоматизированные рабочие процессы с помощью таких событий GitHub, как push, создание задачи, слияние и выпуск.

5,000+

Действия

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

Изучите рынок действий

Вы можете получить все это.Выполняйте действия на любом языке или в любой операционной системе, в Linux, macOS, Windows, ARM и контейнерах. Или все сразу со сборками матриц.

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

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

Узнать больше о Dependabot

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

Сделайте свой вклад

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

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

Git · GitHub

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

Что такое Git?

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

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

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

Зачем нужен Git?

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

Существует множество систем контроля версий, но у Git есть несколько основных преимуществ.

Скорость

Как мы упоминали выше, Git использует сжатие SHA, что делает его очень быстрым.

Конфликты слияния

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

Дешевые отделения

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

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

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

Легкость отката

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

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

Начало работы с Git

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

Существует множества способов использования Git, что не обязательно облегчает его! Но основной рабочий процесс Git состоит из нескольких основных этапов.Вы можете попрактиковаться во всем этом в курсе Introduction to GitHub Learning Lab.

Создать филиал

Основная ветвь обычно называется master . Мы хотим работать над другой веткой , чтобы мы могли сделать запрос на вытягивание и безопасно внести изменения. Для начала создайте ответвление от master . Назовите его, как хотите, но мы рекомендуем называть ветки в зависимости от функции или возможности, которые будут в центре внимания этой ветки. У одного человека может быть несколько веток, а в одной ветке могут работать несколько человек — ветки предназначены для определенной цели, а не для человека.Где бы вы в данный момент ни находились (куда указывает HEAD или какая ветвь, на которую вы в данный момент «извлечены»), будет родительской веткой, которую вы создаете. Это означает, что вы можете создавать ветки из других веток, тегов или любого коммита! Но наиболее типичным рабочим процессом является создание ветви из master , которая представляет собой самый последний производственный код.

Внести изменения (и зафиксировать)

После того, как вы создали ветку и переместили на нее указатель HEAD, «выполнив проверку» в эту ветку, вы готовы приступить к работе.Внесите изменения в свой репозиторий с помощью вашего любимого текстового редактора или IDE.

Далее сохраните изменения. Вы готовы начать коммит!

Чтобы начать коммит, вам нужно сообщить Git, какие изменения вы хотите включить в git add [file] .

После того, как вы сохранили и разместили изменения, вы готовы к фиксации с помощью git commit -m «описательное сообщение фиксации» .

Отправьте изменения на пульт

Пока что, если вы сделали локальную фиксацию, вы единственный, кто может это увидеть.Чтобы другие могли увидеть вашу работу и начать сотрудничество, вы должны «протолкнуть» свои изменения с помощью git push . Если вы впервые запускаете ветку, созданную локально, вам может потребоваться предоставить Git дополнительную информацию. git push -u origin [имя-ветки] сообщает Git, что нужно отправить текущую ветку и создать ветку на пульте дистанционного управления, которая соответствует ей с тем же именем, а также создать связь с этой веткой, чтобы git push будет достаточно информации в будущем.

По умолчанию git push подталкивает только ту ветку, в которой вы в данный момент зарегистрированы.

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

Открыть запрос на вытягивание

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

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

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

Сотрудничайте (получайте отзывы от тестов или коллег, делайте больше коммитов локально, а затем подталкивайте их и получайте больше отзывов)

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

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

Объединить в мастер

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

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

Как использовать Git

Изучение и освоение команд Git

Если вы только начинаете работать с Git, отличным местом для начала является шпаргалка по Git.Он переведен на многие языки, имеет открытый исходный код как часть репозитория github / training-kit и является отличной отправной точкой для изучения основ в командной строке.

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

• git clone [url] : клонировать (загрузить) репозиторий, который уже существует на GitHub, включая все файлы, ветки и коммиты.
• git status : Всегда хорошая идея, эта команда показывает, в какой ветке вы находитесь, какие файлы находятся в рабочем или промежуточном каталоге, и любую другую важную информацию.
• git branch : показывает существующие ветки в вашем локальном репозитории. Вы также можете использовать git branch [banch-name] , чтобы создать ветку из вашего текущего местоположения, или git branch --all , чтобы увидеть все ветки, как локальные на вашем компьютере, так и ветки удаленного отслеживания, хранящиеся из последний git pull или git fetch с пульта дистанционного управления.
• git checkout [имя-ветки] : переключается на указанную ветку и обновляет рабочий каталог.
• git add [файл] : Делает снимки файла для подготовки к управлению версиями, добавляя его в промежуточную область.
• git commit -m «описательное сообщение» : постоянно записывает моментальные снимки файлов в историю версий.
• git pull : обновляет текущую локальную рабочую ветвь всеми новыми коммитами из соответствующей удаленной ветки на GitHub. git pull — это комбинация git fetch и git merge .
• git push : загружает все коммиты локальной ветки на удаленный.
• git log : просматривайте и проверяйте эволюцию файлов проекта.
• git remote -v : показать связанные удаленные репозитории и их сохраненное имя, например origin .

Начало работы с GitHub

Если вам интересно, где заканчивается Git и начинается GitHub, вы не одиноки. Они тесно связаны друг с другом, чтобы сделать работу с ними обоими безупречной. В то время как Git заботится о базовом управлении версиями, GitHub — это платформа для совместной работы, построенная на его основе.GitHub — это место для запросов на вытягивание, комментариев, обзоров, интегрированных тестов и многого другого. Большинство разработчиков разрабатывают локально и используют GitHub для совместной работы. Это варьируется от использования GitHub для размещения общего удаленного репозитория до работы с коллегами и использования таких функций, как защищенные ветки, проверка кода, действия GitHub и т. Д.

Лучшее место для практики использования Git и GitHub — это курс Introduction to GitHub Learning Lab.

Если вы уже знакомы с Git и вам нужно зарегистрировать учетную запись GitHub, перейдите на github.com.

Напишите свой вклад в эту статью на GitHub.

Начните работу с git и GitHub

Проверяйте код, управляйте проектами и создавайте программное обеспечение вместе с 40 миллионами разработчиков.

Зарегистрируйтесь на GitHub Войти

Где мир создает программное обеспечение · GitHub

GitHub: Где мир создает программное обеспечение · GitHub

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

65+ миллионов

Разработчики

3+ миллиона

Организации

200+ миллионов

Репозитории

Создавайте как лучшие с GitHub Enterprise

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

Связаться с отделом продаж git checkout -b origin добавить экраны статуса

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

• Проверка кода встроена. Запросы на вытягивание охватывают весь процесс проверки: предлагать изменения, просматривать код, запрашивать ввод, вносить предложения и подписываться в одном месте.

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

• git merge добавить экраны статуса

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

Доступно для iOS и Android

••• трепать

                      ➜ ~ gh pr статус
                      Соответствующие запросы на вытягивание в cli / cli

                      Текущая ветка
                      Нет запроса на перенос, связанного с [main]

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

                      Запрос на проверку кода у вас
                      # 1401 Правильно обрабатывать и устанавливать пустые поля...
                      [octocat: emptyBody]
                      ✓ Прохождение проверок
                      # 1357 Добавлены шаги подтверждения риска ...
                      [octocat: подтверждения]
                      x 1/3 неудачных проверок
                      ➜ ~
                     

Работайте, как хотите. Поместите на него графический интерфейс с помощью GitHub Desktop или оставайтесь в командной строке с помощью GitHub CLI.

Доступно для macOS, Windows и Linux *

* Интерфейс командной строки GitHub доступен в macOS, Windows и Linux
* Рабочий стол GitHub доступен в macOS и Windows

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

Узнать больше о пространствах кодов GitHub

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

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

Настройте по своему желанию. Добавьте свои любимые расширения VS Code, создайте файл конфигурации devcontainer, установите новые темы и измените настройки.

Автоматизируйте что угодно с помощью GitHub Actions

Узнать больше о действиях GitHub

Настройте CI / CD, улучшите DevOps и создайте сценарий всего рабочего процесса с помощью GitHub Actions. Запускайте автоматизированные рабочие процессы с помощью таких событий GitHub, как push, создание задачи, слияние и выпуск.

5,000+

Действия

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

Изучите рынок действий

Вы можете получить все это.Выполняйте действия на любом языке или в любой операционной системе, в Linux, macOS, Windows, ARM и контейнерах. Или все сразу со сборками матриц.

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

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

Узнать больше о Dependabot

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

Сделайте свой вклад

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

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

Глава 1 Почему Git? Почему GitHub?

Зачем аналитику данных использовать размещенный контроль версий?

Это введение превратилось в отдельную статью, которая, возможно, является лучшим введением на данный момент. Пока я не объединю его обратно, подумайте о том, чтобы прочитать статью: «Извините, у вас есть время поговорить о контроле версий?» https: // dx.doi.org/10.7287%2Fpeerj.preprints.3159v2.

Почему Git?

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

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

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

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

Почему GitHub?

Именно здесь на помощь приходят такие услуги хостинга, как GitHub, Bitbucket и GitLab. Они обеспечивают дом для ваших проектов на основе Git в Интернете.Если вы не понимаете, о чем я говорю, считайте это DropBox, но гораздо лучше. Удаленный хост действует как канал распространения или информационная служба для вашего проекта, управляемого Git. Это позволяет другим людям видеть ваши материалы, синхронизироваться с вами и, возможно, даже вносить изменения. Эти хостинг-провайдеры улучшают традиционные серверы Unix Git с помощью хорошо разработанных веб-интерфейсов.

Даже для частных сольных проектов рекомендуется перенести свою работу в удаленное место для спокойствия.Почему? Потому что довольно легко испортить локальный репозиторий Git, особенно если вы новичок в этом деле. Хорошая новость заключается в том, что часто только инфраструктура Git не работает. Ваши файлы в порядке! Что делает ваш рассол Git еще более разочаровывающим. Существуют официальные решения Git для этих проблем, но они могут потребовать опыта и терпения, которых вы не сможете получить в 3 часа ночи. Если вы недавно разместили свою работу на GitHub, легко получить новую копию, исправить все изменениями, которые существуют только локально, и продолжить свою жизнь.

Мы нацелены на GitHub, а не на Bitbucket или GitLab — ради конкретности. Однако все общие принципы и даже некоторые механизмы будут перенесены на эти альтернативные хостинговые платформы.

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

Будет больно?

Да.

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

Для новых или существующих проектов:

• Выделите ему каталог (он же «папка»).
• Сделайте это проектом RStudio.
• Сделайте это репозиторием Git.
• Занимайтесь своими обычными делами. Но вместо , сохраняющего только отдельных файлов, вы периодически делаете фиксацию , которая делает мультифайловый снимок всего проекта.
  • Создавали ли вы когда-нибудь версию файла, добавляя свои инициалы или дату? Фактически это фиксация , хотя и только для одного файла: это важная для вас версия, которую вы, возможно, захотите проверить или вернуться к ней позже.
• Push периодически фиксируется на GitHub.
  • Это похоже на совместное использование документа с коллегами в DropBox или его отправку в виде вложения электронной почты. Это сигнализирует о том, что вы готовы сделать свою работу доступной для других, и приглашает к комментариям или редактированию.

Это изменение вашего обычного повседневного рабочего процесса. Сначала это кажется странным, но быстро становится второй натурой. Студенты FWIW, STAT 545 должны отправлять всю курсовую работу через GitHub. Это основная тема в классе и в рабочее время в течение первых двух недель. Тогда мы практически не обсуждаем это снова.

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

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

Что такое выплата?

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

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

Сотрудничество : Если вам нужно сотрудничать в области анализа данных или разработки кода, то всем следует использовать Git. Используйте GitHub в качестве центра обмена информацией: люди работают независимо, а затем отправляют работу обратно в GitHub для согласования и передачи остальной части команды. Преимущество Git / GitHub подчеркивается путем сравнения этих двух способов совместной работы над документом:

• Редактировать, сохранять, прикреплять. В этом рабочем процессе у каждого есть одна (или несколько!) Копий документа, которые распространяются через вложения электронной почты.Кто из них «хозяин»? Можно ли вообще сказать? Как разные версии соотносятся друг с другом? Как согласовывать версии? Если вы хотите увидеть лучшую текущую версию, как вы ее получите? Все это обычно решается социальным контрактом и довольно ручным процессом.
• Google Док. В этом рабочем процессе есть только одна копия документа, и она находится в облаке. Любой желающий может получить доступ к самой последней версии по запросу. Кто угодно может редактировать, комментировать или предлагать изменения, и это немедленно становится доступным для всех остальных.Любой желающий может увидеть, кто редактировал документ, и, в случае аварии, сможет вернуться к предыдущей версии. Было спланировано много двусмысленности и надоедливой работы по примирению.

Управление проектом через Git / GitHub больше похоже на сценарий Google Doc и обладает многими из тех же преимуществ. Это определенно сложнее, чем совместная работа над документом Google, но это поможет вам правильно настроиться.

Кто что умеет?

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

Частное хранилище невидимо для мира. Владелец может предоставить другим доступ на чтение, запись (push) или права администратора.

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

Особенности GitHub

возможно, это слишком подробно… точка? или это место где-то еще?

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

• Вып. Помните, как мы разбираемся в инструментах разработки программного обеспечения? Что ж, это баг-трекер. Это список вещей… ошибок, запросов функций, того, что нужно делать, чего угодно.
  • Проблемы тесно интегрированы с электронной почтой и, следовательно, позволяют копировать / вставлять важные разговоры в соответствующее хранилище.
  • Проблемы могут быть назначены людям (например, для dos) и помечены («ошибка» или «отчет о ходе выполнения»).
  Проблемы
  • тесно интегрированы с коммитами и поэтому позволяют записать , что изменения в этой фиксации решают проблему, которая обсуждалась в той проблеме .
  • Как новый пользователь GitHub, одна из наиболее продуктивных вещей, которые вы можете сделать, — это использовать проблемы GitHub для предоставления четкого отчета об ошибке или запроса функции для используемого вами пакета.
• Запросы на вытягивание. Git позволяет проекту иметь несколько независимых ветвей разработки, при этом предполагается, что некоторые из них в конечном итоге должны быть объединены обратно в основную ветвь разработки. Это технические термины Git, но, надеюсь, они имеют смысл и сами по себе. Запрос на вытягивание — это официальное предложение, в котором говорится: «Вот некоторые изменения, которые я хотел бы внести.«Это может быть связано с конкретной проблемой:« Относится к № 14 ». или «Исправления № 56». GitHub облегчает и сохраняет обсуждение предложения в целом и построчно.

Что особенного в использовании R с Git и GitHub?

• Активное сообщество разработчиков пакетов R на GitHub. Прочтите о ресурсах GitHub для R и о поиске здесь.
• Особые рабочие процессы делают полезным делиться исходным кодом, готовыми отчетами и целыми проектами. Узнайте больше о R Markdown, R-скриптах и ​​R-тяжелых проектах.
• Функции RStudio IDE, связанные с Git и GitHub. Это покрыто повсюду.

Аудитория и предварительные требования

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

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

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

Чего это НЕ

Мы стремимся обучать новичков работе с Git на основе принципа «необходимо знать». Git был создан для управления разработкой ядра Linux, которое, вероятно, сильно отличается от того, что вы делаете. Большинству людей нужна небольшая часть функциональности Git, и это будет нашей целью. Если вы хотите полностью представить Git как направленный ациклический граф или трактат о стратегии ветвления Git-Flow, вам будет грустно.

Руководство для начинающих по Git и GitHub

Git — это бесплатное программное обеспечение для управления версиями с открытым исходным кодом .Он был создан Линусом Торвальдсом в 2005 году. Этот инструмент представляет собой систему контроля версий, которая изначально была разработана для работы с несколькими разработчиками над ядром Linux.

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

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

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

Система ветвей в Git позволяет разработчикам работать над задачей индивидуально (например: Одна ветвь -> Одна задача ИЛИ Одна ветвь -> Один разработчик). В основном думайте о Git как о небольшом программном приложении, которое контролирует вашу базу кода, если вы разработчик.

Показывает, как работает Git.

Если мы хотим начать использовать Git, нам нужно знать, где разместить наши репозитории.

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

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

Существует три популярных хостинга Git: GitHub (принадлежит Microsoft), GitLab (принадлежит GitLab) и BitBucket. Мы будем использовать GitHub в качестве нашей службы хостинга.

Git упрощает участие в проектах с открытым исходным кодом.

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

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

Документация

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

Варианты интеграции

GitHub может интегрироваться с распространенными платформами, такими как Amazon и Google Cloud, с такими сервисами, как Code Climate, для отслеживания ваших отзывов и может выделять синтаксис на более чем 200 различных языках программирования.

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

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

GitHub решает эту проблему, отслеживая все изменения, внесенные в репозиторий.

Как и в случае использования Microsoft Word или Google Drive, вы можете иметь историю версий вашего кода, чтобы предыдущие версии не терялись при каждой итерации. Легко вернуться к предыдущей версии и поделиться своей работой.

Продемонстрируйте свою работу

Вы разработчик, который желает привлечь рекрутеров? GitHub — лучший инструмент, на который вы можете положиться.

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

Создание учетной записи GitHub

Чтобы создать учетную запись, вам необходимо перейти на веб-сайт GitHub и заполнить регистрационную форму.

Официальная веб-страница GitHub

Установка Git

Теперь нам нужно установить инструменты Git на наш компьютер.Мы будем использовать CLI для связи с GitHub.

Для Ubuntu:

1. Сначала обновите свои пакеты.

  sudo apt update  

2. Затем установите Git и GitHub с помощью apt-get

  sudo apt-get install git  

3. Наконец, убедитесь, что Git установлен правильно

  git - версия  

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

  git config --global user.name "MV Thanoshan"
git config --global user.email "[email protected]"  

Мы будем работать с проектами GitHub двумя способами.

Тип 1: Создайте репозиторий, клонируйте его на свой компьютер и работайте над ним. (Рекомендуется)

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

Создайте новый репозиторий, нажав кнопку «Новый репозиторий» на веб-странице GitHub.

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

Молодец! Ваш первый репозиторий GitHub создан.

Ваша первая миссия — получить копию репозитория на вашем компьютере. Для этого вам необходимо «клонировать» репозиторий на вашем компьютере.

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

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

  git clone [HTTPS ADDRESS]  

Эта команда создаст локальную копию репозитория, размещенного по данному адресу.

Выходное сообщение команды «git clone»

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

  cd [НАЗВАНИЕ ХРАНИЛИЩА]  

Как вы можете видеть на картинке выше, имя моего репозитория — «My-GitHub-Project», и эта команда заставила меня перейти в этот конкретный каталог.

ПРИМЕЧАНИЕ: При клонировании Git создаст репозиторий на вашем компьютере. Если вы хотите, вы можете получить доступ к своему проекту через пользовательский интерфейс компьютера, вместо того, чтобы использовать указанную выше команду «cd» на терминале.

Теперь в этой папке мы можем создавать файлы, работать с ними и сохранять их локально.Чтобы сохранить их в удаленном месте — например, на GitHub — мы должны выполнить процесс, называемый «фиксация». Для этого вернитесь к своему терминалу. Если вы закрыли его, как я уже говорил, используйте команду «cd».

  cd [НАЗВАНИЕ ХРАНИЛИЩА]  

Теперь в терминале вы находитесь в каталоге хранилища. Коммит состоит из 4 шагов: «status», «add», «commit» и «push». Все следующие шаги должны быть выполнены в рамках вашего проекта. Давайте рассмотрим их один за другим.

1. «статус»: Первое, что вам нужно сделать, это проверить файлы, которые вы изменили.Для этого вы можете ввести следующую команду, чтобы отобразился список изменений.

  git status  

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

  git add [FILENAME] [FILENAME] [. ..]  

В нашем случае мы добавим простой HTML-файл.

  git add sample.html  

3. «commit»: Теперь, когда мы добавили файлы по нашему выбору, нам нужно написать сообщение, чтобы объяснить, что мы сделали.Это сообщение может быть полезно позже, если мы захотим проверить историю изменений. Вот пример того, что мы можем использовать в нашем случае.

  git commit -m «Добавлен образец HTML-файла, который содержит базовый синтаксис»  

4. «push»: Теперь мы можем разместить нашу работу на GitHub. Для этого мы должны «протолкнуть» наши файлы в Remote. Remote — это дубликат нашего репозитория, который находится где-то еще на удаленном сервере. Для этого мы должны знать имя пульта (в основном удаленный называется origin). Чтобы узнать это имя, введите следующую команду.

  git remote  

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

  git push origin master  

Теперь, если мы перейдем в наш репозиторий на веб-странице GitHub, мы увидим файл sample.html, который мы отправили на удаленный компьютер — GitHub!

ПРИМЕЧАНИЕ : Иногда, когда вы используете команды Git в терминале, это может привести вас к текстовому редактору VIM (текстовый редактор на основе интерфейса командной строки).Поэтому, чтобы избавиться от него, вы должны ввести

 : q  

и ENTER.

Описывает, как работают pull & push.

Pulling — это процесс получения от GitHub.

Отправка — это отправка на GitHub.

Тип 2: работайте над своим проектом локально, затем создайте репозиторий на GitHub и отправьте его на удаленный компьютер.

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

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

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

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

  git init  

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

  git status  

Итак, в этом каталоге есть два файла, которые нам нужно «добавить» в наше репо.

  git add [FILENAME] [FILENAME] [...]  

ПРИМЕЧАНИЕ : Чтобы «добавить» все файлы в наш репозиторий, мы можем использовать следующую команду:

  git add.  

После завершения промежуточной области (процесса добавления) мы можем проверить, успешно ли добавлены файлы, выполнив git status

Если эти конкретные файлы выделены зеленым цветом, как на картинке ниже, вы сделал свою работу!

Затем мы должны «зафиксировать» с описанием в нем.

  git commit -m «Добавление формы веб-опроса»  

Если мой репозиторий запущен на GitHub и я перенес его на свой компьютер, к нему уже будет подключен пульт (тип 1). Но если я запускаю свой репозиторий на своем компьютере, с ним не связан пульт, поэтому мне нужно добавить этот пульт (тип 2).

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

ПРИМЕЧАНИЕ : В Типе 2, пожалуйста, не инициализируйте репозиторий с помощью файла README при создании нового репозитория на веб-странице GitHub.

После нажатия кнопки «Создать репозиторий» вы увидите изображение ниже в виде веб-страницы.

Скопируйте адрес HTTPS. Теперь создадим пульт для нашего репозитория.

  git remote add origin [HTTPS ADDRESS]  

После выполнения этой команды мы можем проверить, успешно ли мы добавили удаленное устройство, с помощью следующей команды

  git remote  

И если он выводит «origin» вы добавили пульт в свой проект.

ПРИМЕЧАНИЕ : Просто помните, что мы можем указать любое имя для пульта, изменив имя «origin». Например:

  git remote add [REMOTE NAME] [HTTPS ADDRESS]  

Теперь мы можем без проблем отправить наш проект на GitHub!

  git push origin master  

После выполнения этих шагов один за другим, если вы перейдете на GitHub, вы сможете найти свой репозиторий с файлами!

Спасибо всем за чтение.