Как работать с git: Git за полчаса: руководство для начинающих

Git для новичков (часть 1) / Хабр

Часть 2

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

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

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

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

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

• GitHub

• Bitbucket

• GitLab

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

Как работает

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

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

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

Установка

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

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

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

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

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

# Debian или Ubuntu
sudo apt install git
# CentOS
sudo yum install git

Настройка

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

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

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

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

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

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

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

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

#Добавим все файлы проекта в нам будующий commit
git add .
#Или так
git add --all
#Если хотим добавить конкретный файл то можно так
git add <имя_файла> 
#Теперь создаем commit. Обязательно указываем комментарий.
#И не забываем про кавычки
git commit -m "<комментарий>"

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

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

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

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

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

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

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

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

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

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

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

• GitHub Desktop

• Sourcetree

• GitKraken

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Создаем commit

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

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

Итог

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

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

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

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

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

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

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

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

https://learngitbranching.js.org/

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

Работа с Git через консоль — Блог HTML Academy

Другие материалы по Git

• Введение в системы контроля версий
• Шпаргалка по Git. Решение основных проблем
• Полезные команды для работы с Git

Задача: форкнуть репозиторий в GitHub, создать ветку и работать с кодом.

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

---

Как тестировать сайты

Когда мы пишем код, мы постоянно туда что-то добавляем, удаляем, и иногда всё может ломаться. Поэтому перед любыми изменениями стоит сделать копию проекта. Если собирать проекты в папки с именами проект1, проект1_финали проект2_доделка, вы быстро запутаетесь и точно что-нибудь потеряете. Поэтому для работы с кодом используют системы контроля версий.

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

Git — самая популярная система контроля версий. С Git можно работать через командную строку (или терминал). В каждой системе своя встроенная программа для работы с командной строкой. В Windows это PowerShell или cmd, а в Linux или macOS — Terminal.

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

Вместо встроенных программ можно использовать любую другую — например, Git Bash в Windows или iTerm2 для macOS.

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

Но давайте по порядку — установим Git на компьютер.

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

Windows. Скачайте Git для Windows, запустите exe-файл, следуйте инструкциям.

macOS. Скачайте Git для macOS и запустите dmg-файл. Если он не запускается, зайдите в Системные настройки — Безопасность и нажмите кнопку Open anyway (Всё равно открыть).

Linux. Установите Git через встроенный менеджер пакетов. Если у вас Ubuntu, используйте команду sudo apt-get install git. Команды для других дистрибутивов можно посмотреть здесь.

Как проверить, что Git установился

Откройте терминал и введите команду

git --version

Если Git установлен, то вы увидите номер версии, например, 2.35.1.

Настраиваем Git

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

Добавить имя (введите его внутри кавычек):

git config --global user.name "ваше имя"

Добавить электронную почту (замените email@example. com на вашу почту):

git config --global user.email [email protected]

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

Регистрируемся на GitHub

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

Профиль на Гитхабе и все проекты в нём — ваше публичное портфолио разработчика, поэтому нужно завести профиль, если у вас его ещё нет.

1. Зайдите на сайт https://github. com и нажмите кнопку Sign up.
2. Введите имя пользователя (понадобится в дальнейшей работе), адрес электронной почты (такой же, как при настройке Git) и пароль.
3. На почту придёт код активации — введите на сайте.
4. Появится окно с выбором тарифного плана. Если вы пользуетесь Гитхабом для учёбы, то укажите, что профиль нужен только для вас и вы студент.
5. Опросы и выбор интересов можно пропустить.

На этом всё — вы зарегистрировались и у вас есть собственный профиль.

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

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

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

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

Протокол RSA

Мы будем подключаться к GitHub по SSH. Это работает так:

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

А чтобы подключиться к GitHub с помощью SSH-ключа, сначала нужно его создать.

Проверяем SSH-ключи

Перед созданием нового SSH-ключа проверим, есть ли на компьютере другие ключи. Обычно они лежат в папке с названием .ssh — поэтому посмотрим, есть ли в ней что-то, с помощью команды в терминале:

ls -al ~/.ssh

Полезные команды в терминале Windows

Если у вас уже есть SSH-ключ, то в списке будут файлы с именами вроде id_rsa.pub, id_ecdsa.pub или id_ed25519.pub. А если терминал ругается, что директории ~/.ssh не существует, значит, у вас нет SSH-ключей. Давайте это исправим.

Создаём новый SSH-ключ

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

ssh-keygen -t ed25519 -C "[email protected]"

ed25519 — это алгоритм для генерации ключей. Если ваша система не поддерживает алгоритм ed25519 (и вы увидели ошибку), используйте немного другую команду с алгоритмом rsa:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Терминал спросит, куда сохранить ключ. Если не хотите менять имя файла, которое предлагает терминал, просто нажмите Enter.

> Generating public/private имя-ключа key pair.
> Enter a file in which to save the key (/c/Users/ваш-профиль/.ssh/id_имя-ключа):*[Press enter]*

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

В результате создаётся новый SSH-ключ, привязанный к вашей электронной почте.

Создание ключа по шагам:

Добавляем SSH-ключ в ssh-agent

ssh-agent — программа для хранения и управления SSH-ключами. Давайте запустим её и добавим туда наш SSH-ключ. Запускаем командой eval "$(ssh-agent -s)":

eval "$(ssh-agent -s)"

Если в ответ терминал покажет надпись «Agent pid» и число — значит, всё ок, агент запущен.

Теперь добавим наш ключ командой.

ssh-add ~/.ssh/id_ed25519

Если у вашего ключа другое имя, замените название id_ed25519 именем файла с ключом (это правило применяется и дальше в инструкции). Если вы устанавливали пароль на ключ, введите его два раза после ввода команды ssh-add (терминал подскажет, когда это сделать).

Теперь, если всё хорошо, появится надпись Identity added — значит, можно переходить к добавлению ключа на GitHub.

Копируем SSH-ключ

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

clip < ~/. ssh/id_ed25519.pub

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

Сложный способ. Найдите скрытую папку .ssh

, откройте файл id_ed25519.pub в текстовом редакторе и скопируйте его содержимое.

Простой способ. Введите команду ниже и ключ появится прямо в терминале — его нужно вручную скопировать в буфер обмена. Ключ начинается с ssh-ed22519 или ssh-rsa (или похожей строки) — поэтому копируйте строку прямо с самого начала.

~ cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIO63MT6VCFuZtCLhLj1J6I7dgEU2BsRdIsnvnr4ax+Fr [email protected]

Не копируйте этот ключ из статьи — он уже не работает.

Добавляем SSH-ключ на GitHub

Это нужно сделать, чтобы GitHub вас узнавал.

Перейдите на страницу для работы с ключами в вашем профиле на GitHub и нажмите кнопку New SSH key.

В поле Title нужно добавить название нового ключа. Например, если вы используете Mac, вы можете назвать ключ MacBook Air, или, если ключ для курсов Академии, то Academy. А ключ, который вы скопировали на прошлом шаге, вставьте в поле Key.

Не копируйте ключ со скриншота — он уже не работает.

Теперь нажмите кнопку Add SSH key и, если потребуется, введите свой пароль от GitHub, чтобы подтвердить сохранение. Если всё сделано верно, новый ключ появится в списке на странице https://github. com/settings/keys.

Теперь мы можем поработать с проектом в репозитории.

Что такое репозиторий

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

Если над проектом работает несколько программистов, сначала создаётся мастер-репозиторий — это общий репозиторий с рабочей версией проекта. А каждый программист работает с форком — то есть полной копией мастер-репозитория. В форке вы можете безнаказанно менять код и не бояться что-то сломать в основной версии проекта.

Делаем форк мастер-репозитория

Заходим в нужный репозиторий и нажимаем на «вилку» с надписью fork.

Появится окно Create a new fork — проверьте, что он называется так, как вам нужно, и жмите кнопку Create fork. Через пару секунд всё готово.

Клонируем форк на компьютер — git clone

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

Открываем терминал и переходим в папку с будущим проектом — для этого используем команду cd your-project. Если вы хотите, чтобы проект лежал в папке device, введите

cd device

Если такой папки на компьютере нет, то сначала введите md your-project, чтобы создать эту папку, а затем cd your-project. Подробнее о командах.

Когда перейдёте в папку, введите команду git clone для клонирования репозитория:

git clone [email protected]:your-nickname/your-project.git

Замените your-nickname на ваше имя пользователя на GitHub, а your-project — на название проекта. Проще всего их найти прямо наверху страницы репозитория.

Если вы правильно настроили SSH-ключи, Git скопирует репозиторий на ваш компьютер.

➜  device git clone [email protected]:academy-student/1173761-device-34.git
Клонирование в «1173761-device-34»…
remote: Enumerating objects: 15, done.
remote: Counting objects: 100% (15/15), done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 15 (delta 0), reused 15 (delta 0), pack-reused 0
Получение объектов: 100% (15/15), 145.07 КиБ | 900.00 КиБ/с, готово.

Если вы видите ошибку

Error: Permission denied (publickey), скорее всего, вы ошиблись в настройке SSH-ключа. Вернитесь в этот раздел инструкции и повторите процесс настройки.

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

git clone [email protected]:_your-nickname_/_your-project_.git folder_name

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

В каждом репозитории есть как минимум одна основная ветка, которую создаёт сам Git — она называется

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

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

Создаём новую ветку — git branch

Откройте терминал и введите команду

git branch

Она показывает список веток, с которыми мы работаем в проекте, и выделяет текущую.

Если мы находимся в master , то создаём новую ветку командой

git checkout -b имя-новой-ветки.

➜  1173761-device-34 git:(master) git checkout -b task1
Переключено на новую ветку «task1»
➜  1173761-device-34 git:(task1)

Если текущая ветка не master, переключитесь на неё с помощью команды checkout. После git checkout надо указать название нужной ветки.

git checkout master

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

git branch -m старое-имя-ветки новое-имя-ветки.

Сохраняем изменения — git add

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

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

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

git add -A

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

git add index.html

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

Делаем коммит — git commit

Сделать коммит — значит зафиксировать все сохранённые изменения и дать им название. Это делается с помощью команды commit

git commit -m "ваше сообщение"

Текст сообщения должен быть лаконичным и вместе с этим сообщать о том, что делает коммит (внесённые изменения). Например,

• Добавляет имя наставника в Readme
• Вводит функцию сортировки изображений
• Правит ошибку в поиске городов на карте

Отправляем изменения на GitHub — git push

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

git push origin название-текущей-ветки

Где origin означает репозиторий на компьютере, то есть ваш форк. Слово origin — часть команды, не меняйте это название на своё.

Создаём пулреквест

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

Если к коду нет вопросов, пулреквест принимается. Если нужно что-то исправить — отклоняется, и придётся исправить код и снова пройти цепочку git add — git commit — git push. Если вы и дальше работаете в той же ветке, а пулреквест ещё не принят, все ваши изменения автоматически добавятся в пулреквест, созданный из этой ветки после команды git push origin название-текущей-ветки.

Чтобы создать пулреквест, зайдите на страницу вашего форка на GitHub. Вверху появилась плашка Compare & pull request, а ещё можно зайти на вкладку Pull Requests.

Нажмите на неё и окажетесь на странице открытия пулреквеста. Проверьте описание и нажмите Create pull request.

Готово, теперь ждём остаётся ждать одобрения пулреквеста или комментариев к нему.

Синхронизируем репозитории

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

Теперь код в мастер-репозитории обновился, а в вашем форке нет, вы ведь не обновляли свою версию репозитория с тех пор, как клонировали её себе на компьютер. Приведём форк в актуальное состояние.

В локальном репозитории переключаемся на ветку master.

git checkout master

Забираем изменения из ветки master мастер-репозитория

git pull [email protected]:academy-student/1173761-device-34.git master

Отправляем изменения уже из своей ветки master в ваш форк на GitHub с помощью команды

git push origin master

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

Словарик

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

Git — самая популярная система контроля версий. С Git можно работать через терминал.

Как работает терминал: мы вводим команду и получаем ответ компьютера — или всё получилось, или где-то ошибка, или нужно ввести что-то ещё.

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

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

ssh-agent — программа для хранения и управления SSH-ключами.

Репозиторий — папка с файлами вашего проекта на сервере GitHub или у вас на компьютере.

Мастер-репозиторий — это общий для всей команды репозиторий с рабочей версией проекта.

Форк — полная копия мастер-репозитория, в которой вы можете безопасно работать.

Клонировать форк — скачать его командой git clone, чтобы работать с кодом на своём компьютере.

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

Как пользоваться GitHub: краткий обзор для новичков

Разработчики программ используют в работе различные платформы для обмена исходным кодом, его хранения и распространения. Одной из таких платформ является GitHub. Она настолько популярна, что ее мощностями пользуются даже такие «монстры», как Microsoft и RedHat. Инструментарий платформы включает возможности просмотра кода, а также его распространения с документацией и релизами.

Веб-сервис GitHub востребован для хостинга IT-проектов и совместной разработки. Разработчики системы называют ее «социальной сетью» для программистов. Здесь они объединяют репозитории, комментируют примеры «чужого» кода и используют платформу в качестве облачного хранилища с возможностью быстрой передачи заказчику.

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

Первый шаг к использованию сервиса GitHub заключается в регистрации нового пользователя. В процедуре нет ничего сложного – достаточно зайти на официальный сайт https://github.com/ и создать новую учетную запись. Система запросит рабочую электронную почту.

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

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

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

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Подписаться

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

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

Последовательность действий:

1. Нажать на кнопку «Start a project».
2. Ввести название и описание репозитория.
3. Поставить галочку на «Initialize this repository with a README».
4. Выбрать нужный тип лицензии и нажать на кнопку «Create project».

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

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

Данная отметка обозначает текущую ветку. Создание новой инициируется просто – достаточно в списке начать набирать еще несуществующее название, и система выдаст сообщение «Create branch». Сразу после этого пользователь перекидывается в новую ветку (это стоит учитывать при работе, чтобы случайно не начать редактирование «не тех файлов»).

Изменение файлов и коммиты

Корректировка файлов на GitHub выполняется при помощи коммитов. Это непосредственно само исправление и краткое описание изменений. Такой подход позволяет «внешним» пользователям ориентироваться в нововведениях кода и упрощает контроль командной работы, когда один и тот же файл может редактироваться разными исполнителями.

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

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

Создание запросов слияния (Pull Request) в Github

При подключении к работе сторонних специалистов может понадобиться функция запроса слияния (Pull Request). Инструмент для работы в таком формате называется DIFF. Он подчеркивает любые «чужие» изменения, чтобы владелец программы сразу видел, где код писал не он. Пометки будут доступны только после создания коммита.

Последовательность действий:

1. Открыть вкладку «Pull Request».
2. Нажать на кнопку «Create Pull Request».
3. Выбрать ветку, которую следует слить с основной.
4. Просмотреть внесенные кодером изменения.

После изучения информации созданный запрос на слияние подтверждается нажатием «Merge Pull Request». Новый код будет импортирован в основную ветку, а созданная сторонним исполнителем может спокойно удаляться.

Отчеты об ошибках

Платформа GitHub используется не только для совместной разработки, а еще и для получения обратной связи с пользователями продуктов. Так, на вкладке «Issue» любой «тестировщик» может оставить сообщение о проблемах, с которыми ему пришлось столкнуться при использовании ПО. Чтобы сделать это, нужно нажать кнопку «New issue».

После этого вносится заголовок и текст сообщения. «Проблема» отправляется нажатием на кнопку «Create new issue». Владелец ветки получает уведомления в личном кабинете или на электронную почту, указанную при регистрации.

Заключение

Финалом разработки обычно становится выпуск определенного релиза программного продукта. Это отражается на вкладке «Releases». Здесь следует нажать на кнопку «Create New Release», указать номер версии в поле «Tag Version», внести ее название и небольшое описание. Здесь же прикрепляются архивы с компилированными файлами.

Остается нажать на «Create Release» и убедиться в публикации релиза. Ссылки на исходный код в tar.gz и zip создаются автоматически. Остальные файлы понадобится добавлять вручную.

Настройка репозитория | Atlassian Git Tutorial

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

В данном руководстве обсуждаются следующие основные вопросы:

• Инициализация нового репозитория Git
• Клонирование существующего репозитория Git
• Коммит измененной версии файла в репозиторий
• Конфигурирование репозитория Git для удаленной совместной работы
• Распространенные команды для управления версиями Git

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

Что такое репозиторий Git?

Репозиторий Git — это виртуальное хранилище проекта. В нем можно хранить версии кода для доступа по мере необходимости.

Инициализация нового репозитория: git init

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

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

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

cd /path/to/your/existing/code 
git init

Указание в команде git init существующего каталога проекта приведет к исполнению описанной выше инициализации, но только на уровне этого каталога проекта.

git init <project directory>

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

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

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

git clone <repo url>

Команду git clone выполняют для создания копии (клонирования) удаленного репозитория. В качестве параметра в команду git clone передается URL-адрес репозитория. Git поддерживает несколько различных сетевых протоколов и соответствующих форматов URL-адресов. В этом примере используется SSH-протокол Git. URL-адреса SSH в Git имеют следующий шаблон: git@HOSTNAME:USERNAME/REPONAME. git

Пример URL-адреса SSH в Git имеет вид: [email protected]:rhyolight/javascript-data-store.git, а ниже приведены значения шаблонных параметров:

• HOSTNAME: bitbucket.org
• USERNAME: rhyolight
• REPONAME: javascript-data-store

После исполнения команды последние версии файлов из главной ветки удаленного репозитория будут загружены и помещены в новый каталог. Имя нового каталога будет соответствовать параметру REPONAME. В данном случае это javascript-data-store. В каталоге будет вся история удаленного репозитория и только что созданная главная ветка.

Дополнительную информацию об использовании команды git clone и поддерживаемых форматах URL-адресов в Git см. на странице git clone.

Сохранение изменений в репозитории: git add и git commit

У вас появился репозиторий, созданный путем клонирования или инициализации. Теперь вы можете выполнять коммиты изменений в версиях файлов. В следующем примере предполагается, что вы настроили проект в каталоге /path/to/project. В этом примере предлагаются следующие шаги.

• Измените каталоги на /path/to/project
• Создайте новый файл CommitTest.txt с текстом ~«тест для обучения работе с Git»~
• С помощью команды git add добавьте файл CommitTest.txt в репозиторий проиндексированных файлов
• Создайте новый коммит с комментарием, описывающим, что именно было изменено в коммите

cd /path/to/project 
echo "test content for git tutorial" >> CommitTest.txt 
git add CommitTest.txt 
git commit -m "added CommitTest.txt to the repo"

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

В этом примере представлены две новые команды в Git: add и commit. Этот очень упрощенный пример. Подробнее обе команды объяснены на страницах git add и git commit. Команду git add часто используют с флагом --all. Команда git add --all добавляет все измененные и неотслеживаемые файлы в репозиторий и обновляет дерево изменений репозитория.

Совместная работа в разных репозиториях: git push

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

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

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

Сравнение чистых и клонированных репозиториев

Если в предыдущем разделе («Инициализация нового репозитория») для настройки локального репозитория вы использовали команду git clone, ваш репозиторий уже готов к удаленной совместной работе. Команда git clone автоматически настроит репозиторий, в котором значение remote будет соответствовать URL-адресу Git, из которого был клонирован репозиторий. Это означает, что после изменений файла и выполнения коммита вы можете сразу выполнить команду git push, чтобы отправить эти изменения в удаленный репозиторий.

Если вы использовали команду git init для создания репозитория с нуля, у вас не будет удаленного репозитория, в который можно помещать изменения. Зачастую для инициализации нового репозитория пользователь переходит на сервис Git-хостинга (например, Bitbucket) и создает репозиторий там. Данный сервис предоставит URL-адрес Git, который затем можно добавить в локальный репозиторий Git. После этого можно выполнять команду git push в репозиторий на хостинге. После создания удаленного репозитория на выбранном хостинге вам понадобится обновить локальный репозиторий, выполнив привязку. Этот процесс описывается далее в руководстве по установке и настройке.

Если вы предпочитаете поддерживать собственный удаленный репозиторий, вам нужно создать «чистый репозиторий». Для этого команды git init и git clone принимают аргумент --bare. Наиболее популярная причина использования чистого репозитория — создание удаленного центрального репозитория Git

Конфигурирование и настройка: git config

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

git remote add <remote_name> <remote_repo_url>

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

git push -u <remote_name> <local_branch_name>

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

Дополнительную информацию о команде git remote см. на странице удаленной работы в Git.

Помимо конфигурирования URL-адреса удаленного репозитория, вам может потребоваться установить глобальные параметры Git, например имя пользователя или электронный адрес. Команда git config позволяет настроить инсталляцию Git (или отдельный репозиторий) из командной строки. С помощью этой команды можно установить любые настройки: от информации о пользователе до его предпочтений и характеристик репозитория. Ниже перечислены распространенные варианты конфигурации.

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

• Локальный: /.git/config — настройки на уровне репозитория.
• Глобальный: /.gitconfig — настройки на уровне пользователя. Здесь хранятся настройки с флагом —global.
• Системный: $(prefix)/etc/gitconfig — настройки на уровне всей системы.

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

git config --global user.name <name>

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

Добавление аргумента --local или выполнение команды без параметра уровня конфигурации приведет к установке значения user. name для текущего локального репозитория.

git config --local user.email <email>

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

git config --global alias.<alias-name> <git-command>

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

git config --global alias.ci commit

Так создается команда ci, которую можно использовать как сокращение команды git commit. Подробнее об алиасах в Git см. на странице git config.

git config --system core.editor <editor>

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

git config --global --edit

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

Пояснения

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

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

• /.git/config — настройки на уровне репозитория.
• ~/.gitconfig — личные настройки пользователя. Здесь хранятся настройки с флагом —global.
• $(prefix)/etc/gitconfig — настройки на уровне всей системы.

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

[user] name = John Smith email = [email protected] [alias] st = status co = checkout br = branch up = rebase ci = commit [core] editor = vim

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

Пример

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

Представьтесь репозиторию Git с помощью команды git config

git --global user.name "John Smith" git config --global user.email [email protected]

Выберите любимый текстовый редактор

git config --global core.editor vim

Добавьте алиасы по типу SVN

git config --global alias.st status 
git config --global alias.co checkout 
git config --global alias.br branch 
git config --global alias.up rebase 
git config --global alias.ci commit

Создастся файл ~ /.gitconfig, описанный в предыдущем разделе. Подробную информацию о команде git config см. на странице Git config.

Резюме

Мы показали, как создать репозиторий Git двумя способами: git init и git clone. Этим руководством можно пользоваться при необходимости управления исходным кодом ПО или другим контентом, при хранении которого требуется поддерживать версионность. Кроме того, были представлены команды git add, git commit, git push и git remote и показаны простые примеры их использования.

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

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

Заливаем репозиторий на GitHub

• Редакция

04.02.2022

Поделиться

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

Съемка и монтаж: Глеб Лиманский

Настраиваем доступ по токену

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

Переходим в меню под фото профиля. Settings → Developer settings → Personal access tokens → Create new token.

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

Откроем терминал по адресу нашего проекта. На mac нужно выбрать «новый терминал по адресу папки». На Windows будет вариант «GitBush here».

Чтобы настроить доступ по токену, воспользуемся уже известной утилитой git config: git config —global user. name <username, который задавали при регистрации>

Теперь вводим токен: git config —global user.password <ваш токен>

 

Устанавливаем двухфакторную аутентификацию

Вторая важная настройка безопасности — двухфакторная аутентификация. Settings → Password and Autentication → Enable Two-Factor Authentication. 

В качестве второго фактора лучше использовать не SMS, а приложение, например Google Аuthenticator. Его нужно скачать на телефон, нажать на плюс, чтобы добавить новый код, затем отсканировать qr-код, который появится на сайте, и ввести сгенерированный шестизначный код. После этого нужно скачать коды восстановления и сохранить их в надежное место. 

 

 

Создаем репозиторий на GitHub

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

Задаем имя репозитория, например, git_tutorial. 

Можем добавить описание: «Учимся работать с удаленным репозиторием».

GitHub предлагает нам сразу создать два базовых файла README.md и .gitignore. Но у нас уже есть локальный репозиторий, с которым мы начали работать, добавим эти файлы в него. А на этом шаге просто нажимаем create repository. 

 

Файлы README и gitignore 

Файл README.md — это текстовый файл, в котором на языке markdown можно добавить описание проекта. Файл README необязателен, но помогает лучше ориентироваться в своих и чужих репозиториях. Давайте его добавим в нашу папку с проектом. Напишем заголовок «Тестовый репозиторий» и описание: «Это тестовый репозиторий, в котором я учусь работать с git». 

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

В проекте появился новый файл. Вернемся в терминал и добавим его в отслеживание: git add README.md

Закоммитим: git commit -m “Add README”

 

Файл .gitignore нужен, чтобы прописать те файлы, которые мы не хотим отслеживать. Это могут быть конфигурационные или временные файлы, которые автоматически создаются по ходу работы. Учесть все ненужные файлы, которые могут появиться, и самостоятельно создать gitignore-документ сложно. Поэтому можно использовать шаблоны, а потом уже дополнять их самостоятельно по ходу работы. Мы программируем на python, поэтому для примера я нашла gitignore для python. Создадим файл .gitignore в нашей папке и скопируем в него названия файлов. 

Добавим новый файл в отслеживание и закоммитим изменения.

git add .gitignore

git commit -m “Add gitignore”

Проверим git status. Все закоммичено.

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

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

 

Просматриваем историю изменений

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

У каждого коммита есть уникальный идентификатор — набор цифр и букв. Мы видим кто и когда сделал каждый коммит, какое сообщение он написал. Подробнее посмотреть информацию о конкретном коммите можно с помощью команды: git show <5 первых символов идентификатора>

В таком режиме мы видим, какие изменения были внесены.

Зеленые плюсы — какие строки добавились, красные минусы — какие удалились. 

Чтобы выйти из log, нужно нажать q в английской раскладке.

Еще раз посмотрим всю историю: git log. Наши изменения лежат в ветке master (на Windows будет ветка main), подробнее про ветки мы еще будем говорить на следующем занятии. Сейчас достаточно знать, что это основная ветка. Но на GitHub основная ветка называется main.

Чтобы не возникало проблем при сохранении проекта на сервере, переименуем нашу локальную ветку: git branch -m master main. (Для Windows это делать не нужно)

Проверим историю: git log. Видим, что ветка переименовалась.

 

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

Передадим наш репозиторий на сервер. Связаться с удаленным репозиторием можно по ссылке. Откроем репозиторий на GitHub и скопируем ссылку. 

В открытом терминале пишем команду:

git remote add origin <ссылка на репозиторий> 

(Чтобы вставить скопированную ссылку в терминал на Windows, нужно зажать ctrl и нажать левой кнопкой мыши или тачпада.)

Origin — это имя удаленного репозитория, которое мы будем дальше использовать вместо ссылки. Проверим, подключился ли репозиторий. Команда git remote -v показывает, какие удаленные репозитории присоединены. Мы видим присоединенный репозиторий.

Теперь можем отправить на него наш локальный репозиторий: git push -u origin main 

Обновим страницу: наш репозиторий появился на сайте.

В заголовке видим последний коммит. Если нажмем на часы — увидим историю коммитов. Такую же, как в git log.

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

 

Вносим изменения и исправляем ошибки

Вносим изменения в наш файл test.py: print(“We learn GitHub”)  

Добавляем изменение в отслеживание и закоммитим: git commit -a -m “Add third line”

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

Теперь давайте представим, что мы закоммитили ошибочное изменение. Допишем в файл строку: print(“False line”)

Добавим изменение в отслеживание и закоммитим: git commit -a -m “False commit”

Проверим историю: git log

Мы видим ошибочный коммит.

Чтобы отменить его, воспользуемся командой: git revert <первые 5 символов идентификатора коммита>

Мы попали в текстовый редактор, где уже есть сообщение об отмене коммита, можем написать другое сообщение или сохранить предложенное, чтобы выйти из текстового редактора нажмем cmd+X, затем y и enter.

Проверим историю: git log. Мы видим, что git создал новое сохранение с отменой коммита, а в файле ненужная строка удалилась.

 

Заливаем изменения на сервер

Проверим git status. Дерево чистое, можем заливать коммиты на сервер: git push. Нам не нужно еще раз писать origin main, потому изменения из ветки main на ветку origin мы уже передавали в прошлый раз. Откроем наш репозиторий на сайте. Зайдем в файл test.py. Видим, что третья строка появилась, а четвертая ошибочная строка не закоммитилась, как нам и было нужно.

 

Копируем удаленные репозитории

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

Создадим папку на компьютере для этого репозитория. Откроем терминал в этой папке. Введем команду git clone <ссылка на репозиторий>  

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

Можно это сделать и в терминале, просмотрев все внутренние папки: ls

Перейдем в репозиторий: cd <название клонированной папки с репозиторием>

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

 

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

Работа с Git на хостинге | REG.RU

Что такое Git

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

Для создания проекта (например, сайта) с использованием Git вам понадобится:

• Локальный репозиторий — хранилище Git на локальном компьютере. Сначала вы работаете над проектом на своём рабочем компьютере и сохраняете изменения в локальный репозиторий с помощью коммита (commit). Затем помещаете (push) изменения в удалённый репозиторий. Если над проектом работают несколько разработчиков, у каждого свой локальный репозиторий.

• Удалённый репозиторий — система управления репозиториями кода для Git. Например: GitHub, GitLab, Bitbucket. После завершения локальной работы над кодом каждый разработчик проекта отправляет свою часть кода или изменения в удалённый репозиторий, где всё сливается (merge) воедино, а затем разворачивается (deploy) на сервер проекта.

• Сервер проекта — это виртуальный хостинг, VPS или любой другой сервер. Развернуть свой проект можно несколькими способами. Существуют системы автоматического развёртывания из удалённого репозитория, а также ручное клонирование с помощью Git.

На хостинге REG.RU установлен Git, благодаря чему вы сможете упростить процесс разработки и публикации сайта. Обратите внимание: на хостинге REG.RU по умолчанию используется Git версии 1.7.1. Для запуска версии 2.19.2 используйте алиас git2192.

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

Подготовка к работе

1. Для работы вам необходимо скачать Git с официального сайта и установить на свой локальный компьютер. Для пользователей Linux Git, как правило, доступен из коробки. Для пользователей Windows рекомендуем использовать графические оболочки, например SmartGit или GitKraken.

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

3. Файлы, которые необходимо отправить в удалённый репозиторий, добавьте с помощью команды git add каталог/название_файла или же выполните команду git add . , чтобы добавить все папки и файлы, которые находятся каталоге вашего проекта.

4. Создайте коммит с помощью команды

git commit -m "any comment"

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

Отправка изменений в удалённый репозиторий

Все команды будут выстроены на примере работы с GitHub. Работа с другими хранилищами репозитория происходит по аналогии.

1. 1.

   На сайте GitHub создайте репозиторий. После этого вы получите ссылку на ваш репозиторий, например: https://github.com/userName/regru-hosting.git

2. 2.

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

   git remote add origin https://github.com/userName/regru-hosting.git

3. 3.

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

   git push origin master

   Система запросит ваш логин и пароль от GitHub.

   Готово, после завершения отправки ваши файлы появятся в удалённом репозитории на GitHub.

Публикация сайта с GitHub на хостинг

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

Чтобы клонировать изменения с GitHub на хостинг REG.RU:

1. 1.

   Подключитесь к вашей услуге хостинга по SSH.

2. 2.

   Перейдите в корневой каталог вашего сайта.

3. 3.

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

   git clone https://github.com/mrradu/regru-hosting.git

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

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

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

Создание открытого SSH-ключа

1. 1.

   Проверьте, есть ли SSH-ключи на вашем хостинге. Для этого:

   Перейдите в каталог, в котором они хранятся:

   cd ~/.ssh

   Запросите содержимое каталога:

2. 2.

   В зависимости от вывода команды выберите нужный вариант.

   • Если в выводе команды отображается следующее содержимое:

   authorized_keys2  id_rsa       known_hosts
   config            id_rsa.pub

   Где id_rsa.pub — открытый ключ, а id_rsa — приватный ключ.

   Перейдите в каталог, в котором хранятся SSH-ключи:

   cd ~/.ssh/

   Откройте файл командой:

   cat id_rsa.pub

   • Если в выводе команды вы видите ошибку «No such file or directory», создайте ключи самостоятельно. Для этого:

   Запустите утилиту:

   ssh-keygen

   Укажите имя файла:

   Enter file in which to save the key (~/. ssh/id_rsa): id_rsa

   Где id_rsa — имя файла без расширения.

   Укажите пароль:

   Enter passphrase (empty for no passphrase):

   Вы можете оставить пароль пустым, для этого нажмите Enter.

   Перейдите в каталог, в котором хранятся SSH-пароли:

   cd ~/.ssh/

   Откройте файл командой:

   cat id_rsa.pub

   Где id_rsa.pub — название файла открытого ключа.

Готово, вы сгенерировали ключи.

Помогла ли вам статья?

Да

6 раз уже помогла

Как использовать Git {Руководство для начинающих} + Начало работы с GitHub

Введение

Git — самая популярная в мире система контроля версий ( VCS ), и, следовательно, знание того, как использовать Git, стало обязательным навыком в мир кодирования.

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

Что такое Git и что такое GitHub

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

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

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

Учебное пособие по Git: как использовать Git {Пошаговое руководство для начинающих}

Чтобы начать работу с Git, выполните следующие действия.

Шаг 1.

Установите Git и создайте учетную запись GitHub

Первое, что вам нужно сделать, это установить Git и создать учетную запись GitHub.

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

• Установить Git на Windows
• Установить Git на Mac
• Установить Git на Ubuntu
• Установить Git на CentOS 7
• Установить Git на CentOS 8

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

Чтобы обновить Git, следуйте инструкциям в нашей статье о том, как обновить Git в Windows, macOS или Linux.

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

Выполните следующие действия:

1. Посетите официальную страницу создания учетной записи: Присоединяйтесь к GitHub

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

3. Включите или отключите получение обновлений и объявлений, установив/сняв флажок Настройки электронной почты .

4. Подтвердите, что вы не робот, решив головоломку Captcha .

5. Нажмите Создать учетную запись .

6. GitHub отправляет код запуска на указанный адрес электронной почты. Скопируйте и вставьте код в указанное поле.

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

Теперь вы успешно создали учетную запись GitHub.

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

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

Чтобы создать репозиторий Git, выполните следующие действия:

1. Откройте терминал Git Bash и перейдите в каталог, в котором вы хотите сохранить проект на локальном компьютере. Например:

 cd ~/Рабочий стол
mkdir мой проект
cd myproject/ 

В этом примере мы изменили каталог на Desktop и создали подкаталог с именем myproject .

2. Создайте репозиторий Git в выбранной папке, выполнив команду git init . Синтаксис:

 git init [имя-репозитория] 

Теперь вы успешно создали локальный репозиторий Git.

Шаг 3. Создайте новый репозиторий на GitHub

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

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

1. Войдите в систему и перейдите на домашнюю страницу GitHub.

2. Найдите параметр Новый репозиторий под знаком + рядом с изображением вашего профиля в правом верхнем углу.

3. Введите имя репозитория, краткое описание и выберите параметр конфиденциальности.

4. Нажмите кнопку Создать репозиторий .

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

 git remote add origin https://github.com/[ваше-имя-пользователя]/[имя-репозитория.git]
git push -u мастер происхождения
 

Например:

Шаг 4: Добавление файла в репозиторий

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

Вы можете проверить, какие файлы отслеживает Git, выполнив:

 git status 

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

 git add [имя файла] 

Например:

В этом примере мы указали Git начать отслеживать изменения для файла test.txt . Повторный запуск команды git status показывает, что Git отслеживает указанный файл.

Шаг 5. Удаление файлов из Git

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

Один из способов отключить файлы в Git — запустить команду git reset . Синтаксис:

 git reset [commit] -- [file_path] 

Например:

Примечание: Вы также можете использовать команду rm для удаления файлов в Git.
Синтаксис: git rm --cached [имя-файла] .

Шаг 6. Создайте фиксацию

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

Синтаксис:

 git commit -m "Примечания о фиксации" 

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

Например:

Шаг 7: Отменить последнюю фиксацию

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

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

Чтобы отменить опубликованную фиксацию, используйте следующий синтаксис:

 git revert [хэш] 

Хэш — это код, который идентифицирует каждую фиксацию. Получите хэш фиксации, выполнив:

 git log 

Например:

В этом примере мы сначала запустили команду git log , чтобы получить хэш фиксации, а затем отменили последнюю фиксацию, выполнив git revert с полученным хешем коммита.

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

Шаг 8. Создайте новую ветку

Первая ветка в репозитории git называется master и является основной веткой в ​​проекте.

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

Обычный метод создания новой ветки — запуск:

 git branch [new_branch_name] 

Например:

В этом примере мы создаем новую ветку с именем new-feature .

Шаг 9. Переключение ветвей

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

 git checkout [branch_name] 

Заменить [название_ветки] с именем ветки, к которой вы хотите получить доступ.

Например:

Шаг 10. Переименуйте локальную или удаленную ветку Git

В Git вы можете переименовать локальную или удаленную ветку Git.

Синтаксис для изменения имени локальной ветки Git:

 git branch -m новое имя 

Например:

В этом примере мы изменили имя локальной ветки с new-feature на feature -тестин г.

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

Шаг 11. Удаление локальной или удаленной ветки Git

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

Вы можете удалять локальные и удаленные ветки Git.

Удаление локальной ветви не влияет на удаленную ветвь. Чтобы удалить local Ветка Git, запустите:

 git branch -d [branch_name] 

Используйте следующий синтаксис для удаления remote Git ветки:

 git push [remote_project] --delete [branch_name] 

В этом примере , мы удалили локальную ветку Git:

Шаг 12: Установить вышестоящую ветку

Отправка чего-либо вверх по течению в Git означает, что вы отправляете это обратно владельцу репозитория.

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

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

Шаг 13. Удаление Git Remote

Git Remote — это подключение к репозиторию, размещенному на удаленном сервере — GitHub, BitBucket, GitLab или любом другом удаленном месте.

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

Есть несколько способов удалить удаленный Git. Один из способов — удалить пульт с помощью командной строки. Синтаксис:

 git remote remove [remote name] 

В следующем примере запуск git remote -v показывает доступные удаленные устройства, ‘origin’ и ‘test-remote’. После удаления «test-remote» и повторного запуска git remote -v для получения списка доступных пультов мы видим, что единственным доступным пультом является «origin».

Шаг 14: Слияние Git

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

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

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

1. Запустите команду git status , чтобы убедиться, что HEAD указывает на правильную принимающую (главную) ветвь слияния. Если это не так, запустите git checkout master , чтобы переключиться на ветку master.

2. Запустите git fetch , чтобы получить последние удаленные коммиты, и git pull , чтобы обеспечить наличие последних обновлений в основной ветке.

3. Запустите git merge X , где X — это имя ветки, которую вы хотите объединить с веткой-получателем.

Шаг 15. Разрешение конфликтов слияния

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

Хотя большинство конфликтов слияния разрешается автоматически , бывают случаи, когда git merge не может решить проблему .

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

Шаг 16. Создайте запрос на вытягивание

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

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

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

Выполните следующие действия:

1. В Git Bash создайте пустой файл readme, запустив touch readme.md .

2. Создайте и переключитесь на новую ветку, в которой нужно изменить файл. Запустите:

 git checkout -b create-readme-file 

3. Откройте файл readme в текстовом редакторе и добавьте текст, который вы хотите, чтобы он содержал. В этом примере мы будем использовать текстовый редактор Nano для изменения файла в окне командной строки. Выполнить nano readme.md .

4. После сохранения файла отследите его, запустив git add readme.md .

5. Создайте коммит.

 git commit -m «Добавлен файл readme» 

6. Отправьте изменения на GitHub.

 git push origin create-readme-file 

7. Войдите на свою страницу GitHub. Теперь в вашем репозитории есть опция Create pull request с именем ветки, которое мы создали в командной строке. Нажмите Кнопка сравнения и запроса на вытягивание .

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

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

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

Шаг 17. Синхронизируйте изменения на GitHub и локально

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

Синхронизируйте свой локальный репозиторий с GitHub, выполнив:

 git pull origin master 

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

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

Заключение

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

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

Git — gittutorial Documentation

НАЗВАНИЕ

gittutorial — Введение в Git внести в него изменения и поделиться изменениями с другими разработчиками.

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

Во-первых, обратите внимание, что вы можете получить документацию для такой команды, как git log --graph с:

 $ man git-log 

или:

 $ git help log 

С последним вы можете использовать средство ручного просмотра по вашему выбору; видеть git-help[1] для получения дополнительной информации.

Рекомендуется представиться Git своим именем и общедоступный адрес электронной почты перед выполнением каких-либо операций. Самый легкий способ сделать это:

 $ git config --global user. name "Ваше имя здесь"
$ git config --global user.email [email protected] 

Импорт нового проекта

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

 $ tar xzf проект.tar.gz
$ компакт-диск проект
$ гит инициализация 

Git ответит

 Инициализирован пустой репозиторий Git в .git/ 

Теперь вы инициализировали рабочий каталог — вы можете заметить новый созданный каталог с именем «.git».

Затем скажите Git сделать снимок содержимого всех файлов в текущий каталог (обратите внимание на . ), с git add :

 $ git add . 

Этот моментальный снимок теперь хранится во временной промежуточной области, которую Git вызывает «индекс». Вы можете постоянно хранить содержимое указателя в репозиторий с git commit :

 $ git commit 

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

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

Измените некоторые файлы, затем добавьте их обновленное содержимое в индекс:

 $ git add файл1 файл2 файл3 

Теперь вы готовы к фиксации. Вы можете видеть, что должно быть совершено используя git diff с параметром —cached:

 $ git diff --cached 

(без —cached, git diff покажет вам все изменения, которые вы сделали, но еще не добавили в индекс.) Вы также можете получить краткую сводка ситуации с git status :

 $ git status
На мастере ветки
Изменения, которые необходимо зафиксировать:
Ваша ветка обновлена ​​до «origin/master».
  (используйте "git restore --staged ...", чтобы отменить постановку)
изменено: файл1
изменено: файл2
изменено: file3 

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

 $ git commit 

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

В качестве альтернативы, вместо предварительного запуска git add , вы можете использовать

 $ git commit -a 

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

Примечание к сообщениям фиксации: хотя это и не обязательно, рекомендуется начинайте сообщение коммита с одного короткого (менее 50 символов) строка, обобщающая изменение, за которой следует пустая строка, а затем еще тщательное описание. Текст до первой пустой строки в коммите сообщение рассматривается как заголовок коммита, и этот заголовок используется по всему Гит. Например, git-format-patch[1] превращает зафиксировать в электронной почте, и он использует заголовок в строке темы и остальная часть фиксации в теле.

Git отслеживает содержимое, а не файлы

Многие системы контроля версий предоставляют команду add , которая сообщает система, чтобы начать отслеживать изменения в новом файле. Команда Git добавить делает что-то более простое и мощное: git add используется как для новых и недавно измененные файлы, и в обоих случаях делается снимок заданные файлы и этапы, содержащиеся в индексе, готовые к включению в следующий коммит.

Просмотр истории проекта

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

 $ git log 

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

 $ git log -p 

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

 $ git log --stat --summary 

Управление ветвями

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

 $ git ветка экспериментальная 9.0105 
 Если вы сейчас запустите 
 
 $ git branch 
, вы получите список всех существующих веток:
 Experimental
* master 
 «Экспериментальная» ветвь — это та, которую вы только что создали, а
Ветка «master» — это ветка по умолчанию, которая была создана для вас. автоматически. Звездочка отмечает ветку, в которой вы сейчас находитесь;
введите
 $ git switch Experimental 
, чтобы переключиться на экспериментальную ветку. Теперь отредактируйте файл, зафиксируйте
изменить и вернуться к основной ветке:
 (редактировать файл)
$ git совершить -а
$ git switch master 
 Убедитесь, что сделанное вами изменение больше не видно, так как оно было
сделано на экспериментальной ветке, и вы вернулись на основную ветку.
 Вы можете внести другое изменение в основную ветку:
 (редактировать файл)
$ git commit -a 
 на данный момент две ветки разошлись с разными изменениями
сделано в каждом. Чтобы объединить изменения, сделанные в экспериментальном файле, с основным, запустите
 $ git merge Experiment 
 Если изменения не конфликтуют, все готово. Если есть конфликты,
в проблемных файлах останутся маркеры, указывающие на конфликт;
 $ git diff 
 покажет это. После того, как вы отредактировали файлы, чтобы решить проблему
конфликты,
 $ git commit -a 
 зафиксирует результат слияния. Наконец,
 $ gitk 
 покажет красивое графическое представление результирующей истории.
 На этом этапе вы можете удалить экспериментальную ветку с
 $ git branch -d Experiment 
 Эта команда гарантирует, что изменения в экспериментальной ветке
уже в текущей ветке.
 Если развивать на ветке бред-идею, то пожалеть всегда можно
удалить ветку с
 $ git branch -D Crazy-idea 
 Ветки дешевы и просты, так что это хороший способ попробовать что-нибудь
вне.
 Использование Git для совместной работы 
 Предположим, Алиса начала новый проект с репозиторием Git в
/home/alice/project, и тот Боб, у которого есть домашний каталог на
такая же машина, хочет внести свой вклад.
 Боб начинает с:
 bob$ git clone /home/alice/project myrepo 
 Это создает новый каталог «myrepo», содержащий клон Алисы
репозиторий. Клон наравне с оригиналом
проект, обладающий собственной копией оригинальной истории проекта.
 Затем Боб вносит некоторые изменения и фиксирует их:
 (редактирование файлов)
bob$ git commit -a
(при необходимости повторить) 
 Когда он будет готов, он скажет Алисе извлечь изменения из репозитория.
в /home/bob/myrepo. Она делает это с:
 alice$ cd /home/alice/project
alice$ git pull /home/bob/myrepo master 
 Это объединяет изменения из ветки «master» Боба в ветку Алисы.
текущая ветка. Если Алиса за это время внесла свои изменения,
тогда ей может потребоваться вручную исправить любые конфликты.
 Таким образом, команда "pull" выполняет две операции: извлекает изменения
из удаленной ветки, а затем объединяет их в текущую ветку.
 Обратите внимание, что обычно Алиса хотела бы, чтобы ее локальные изменения были зафиксированы до
инициируя эту «тягу». Если работа Боба противоречит тому, что Алиса делала после
их истории разветвляются, Алиса будет использовать свое рабочее дерево и индекс для
разрешать конфликты, а существующие локальные изменения будут мешать
процесс разрешения конфликтов (Git по-прежнему будет выполнять выборку, но
отказаться от слияния — Алисе придется избавиться от своих локальных изменений в
каким-то образом и снова потяните, когда это произойдет).
 Алиса может посмотреть, что сделал Боб, без предварительного слияния, используя "выборку"
команда; это позволяет Алисе проверить, что сделал Боб, используя специальный
символ "FETCH_HEAD", чтобы определить, есть ли у него что-нибудь стоящее
потянув, вот так:
 alice$ git fetch /home/bob/myrepo master
alice$ git log -p HEAD..FETCH_HEAD 
 Эта операция безопасна, даже если Алиса имеет незафиксированные локальные изменения.
Обозначение диапазона «HEAD..FETCH_HEAD» означает «показать все, что доступно
из FETCH_HEAD, но исключите все, что доступно из HEAD".
Алиса уже знает все, что приводит к ее текущему состоянию (ГОЛОВУ),
и просматривает то, что у Боба есть в его состоянии (FETCH_HEAD), чего у нее нет.
видел с этой командой.
 Если Алиса хочет представить, что делал Боб с тех пор, как их истории разветвились
она может выполнить следующую команду:
 $ gitk HEAD..FETCH_HEAD 
 Здесь используется то же обозначение диапазона с двумя точками, которое мы видели ранее с  git log  .
 Алиса может захотеть посмотреть, что они оба сделали с момента разветвления.
Она может использовать форму с тремя точками вместо формы с двумя точками:
 $ gitk HEAD...FETCH_HEAD 
 исключить все, что достижимо из них обоих».
 Обратите внимание, что эти обозначения диапазона можно использовать как с gitk,
и "журнал git".
 После проверки того, что сделал Боб, если нет ничего срочного, Алиса может
решить продолжить работу, не дёргая Боба. Если история Боба
есть что-то, что Алисе нужно немедленно, Алиса может выбрать
сначала спрячьте ее незавершенную работу, сделайте «вытягивание», а затем, наконец, расчехлите
ее незавершенная работа поверх полученной истории.
 Когда вы работаете в небольшой тесно сплоченной группе, это не
непривычно взаимодействовать с одним и тем же хранилищем снова и снова
опять таки. По определению  удаленный репозиторий , вы можете сделать
это проще:
 alice$ git remote add bob /home/bob/myrepo 
 С этим Алиса может выполнить первую часть операции «вытягивания»
в одиночку, используя команду  git fetch , не объединяя их со своей
ветка, используя:
 alice$ git fetch bob 
 В отличие от полной формы, когда Алиса получает от Боба, используя
удаленный репозиторий, настроенный с помощью  git remote  , что было
fetched хранится в ветке удаленного отслеживания, в данном случае  боб/мастер  . Итак, после этого:
 alice$ git log -p master..bob/master 
 показывает список всех изменений, которые Боб сделал с тех пор, как он отделился от
Основная ветвь Алисы.
 Изучив эти изменения, Алиса
может объединить изменения в свою основную ветку:
 alice$ git merge bob/master 
 Это  слияние  также может быть выполнено  путем извлечения из ее собственного удаленного отслеживания
ветка , например:
 alice$ git pull . пульты/боб/мастер 
 Обратите внимание, что git pull всегда объединяется с текущей веткой,
независимо от того, что еще указано в командной строке.
 Позже Боб может обновить свой репозиторий последними изменениями Алисы, используя
 bob$ git pull 
 Обратите внимание, что ему не нужно указывать путь к репозиторию Алисы;
когда Боб клонировал репозиторий Алисы, Git сохранил ее местоположение.
репозиторий в конфигурации репозитория, и это местоположение
используется для получения:
 bob$ git config --get remote. origin.url
/дом/алиса/проект 
 (Полная конфигурация, созданная клоном  git , видна с помощью  git config -l  и справочная страница git-config[1]
объясняет значение каждой опции.)
 Git также хранит нетронутую копию ветки master Алисы под
name "origin/master":
 bob$ git branch -r
  origin/master 
 Если позже Боб решит работать с другого хоста, он все равно сможет
выполнять клонирование и извлечение по протоколу ssh:
 bob$ git clone alice.org:/home/alice/project myrepo 
 В качестве альтернативы Git имеет собственный протокол или может использовать http;
подробности см. в git-pull[1].
 Git также можно использовать в режиме, подобном CVS, с центральным репозиторием
в которые различные пользователи вносят изменения; см. git-push[1] и
gitcvs-миграция[7].
 Изучение истории 
 История Git представлена ​​в виде серии взаимосвязанных коммитов. Мы
уже видели, что команда  git log  может перечислить эти коммиты. Обратите внимание, что в первой строке каждой записи журнала git также указывается имя
зафиксировать:
 $ журнал git
зафиксировать c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
Автор: Junio ​​C Hamano 
Дата: вторник, 16 мая, 17:18:22 2006 -07:00
    merge-base: Уточнить комментарии к постобработке. 
 Мы можем дать это имя  git show , чтобы увидеть подробности об этом
совершить.
 $ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 
 Но есть и другие способы ссылаться на коммиты. Вы можете использовать любой начальный
часть имени, достаточно длинная, чтобы однозначно идентифицировать фиксацию: 92 # показать второго родителя HEAD 

Вы также можете дать своим коммитам имена; после запуска

 $ git tag v2.5 1b2e1d63ff 

вы можете ссылаться на 1b2e1d63ff по имени «v2.5». Если вы собираетесь поделиться этим именем с другими людьми (например, чтобы идентифицировать выпуск версия), вы должны создать объект «тег» и, возможно, подписать его; видеть git-tag[1] для подробностей.

Будьте осторожны с этой последней командой: помимо потери любых изменений в рабочем каталоге, он также удалит все последующие коммиты из эта ветка. Если эта ветвь является единственной ветвью, содержащей те совершает, они будут потеряны. Кроме того, не используйте git reset на общедоступная ветка, из которой берутся другие разработчики, так как она заставить ненужные слияния на других разработчиков, чтобы очистить историю. Если вам нужно отменить внесенные вами изменения, используйте git revert . вместо.

Команда git grep может искать строки в любой версии вашего проект, поэтому

 $ git grep "hello" v2.5 

ищет все вхождения «hello» в v2.5.

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

 $ git grep "hello" 

— это быстрый способ поиска только тех файлов, которые отслеживаются Git.

Многие команды Git также принимают наборы коммитов, которые можно указать несколькими способами. Вот несколько примеров с git log :

 $ git log v2.5..v2.6 # коммиты между версиями 2.5 и 2.6
$ git log v2.5.. # фиксирует, начиная с версии 2.5
$ git log --since="2 days ago" # коммиты за последние 2 недели
$ git log v2.5.. Makefile # фиксирует, начиная с версии 2.5, которые изменяют
# Makefile 

Вы также можете указать git log «диапазон» коммитов, где первый не обязательно предок второго; например, если кончики ветви «стабильная» и «хозяин» расходились от общего совершить какое-то время назад, то

 $ git log stable..master 

перечислит коммиты, сделанные в ветке master, но не в ветке стабильная ветка, а

 $ git log master..stable 

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

Команда git log имеет недостаток: она должна представлять коммиты в список. Когда в истории есть линии развития, которые расходятся и затем снова объединены, порядок, в котором git log представляет эти коммиты бессмысленны.

Большинство проектов с несколькими участниками (например, ядро ​​Linux, или сам Git) имеют частые слияния, а gitk лучше справляется с визуализация их истории. Например,

 $ gitk --since="2 days ago" drivers/ 

позволяет просматривать любые коммиты за последние 2 недели коммитов. который изменил файлы в каталоге «драйверы». (Примечание: вы можете настройте шрифты gitk, удерживая нажатой клавишу управления, одновременно нажимая «-» или «+».)

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

 $ git diff v2.5:Makefile HEAD:Makefile.in 

Вы также можете использовать git show для просмотра любого такого файла:

 $ git show v2.5:Makefile 

Следующие шаги

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

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

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

Вторая часть этого руководства объясняет объект базу данных, индексный файл и некоторые другие мелочи, которые вам понадобятся. нужно максимально использовать Git. Вы можете найти его на gittutorial-2[7].

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

• git-format-patch[1], git-am[1]: они конвертируют серии коммитов git в патчи, отправленные по электронной почте, и наоборот, полезно для таких проектов, как ядро ​​Linux, которые сильно зависят на патчах, отправленных по электронной почте.

• git-bisect[1]: когда в вашем проект, один из способов отследить ошибку — выполнить поиск по историю, чтобы найти точный коммит, который виноват. Git пополам может помочь вам выполнить бинарный поиск для этой фиксации. это достаточно умен, чтобы выполнять поиск, близкий к оптимальному, даже в случай сложной нелинейной истории с большим количеством слившихся ветвей.

• gitworkflows[7]: дает обзор рекомендуемых рабочие процессы.

• giteveryday[7]: Git на каждый день с примерно 20 командами.

• gitcvs-migration[7]: Git для пользователей CVS.

СМОТРИТЕ ТАКЖЕ

gittutorial-2[7], gitcvs-миграция[7], gitcore-учебник [7], гитглоссарий[7], git-помощь [1], gitworkflows[7], giteveryday[7], Руководство пользователя Git

GIT

Часть пакета git[1]

Основные команды Git — как использовать Git в реальном проекте

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

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

Я создал простой проект, который мы будем использовать в этом уроке.

Интерфейс проекта

Изучив это руководство, вы узнаете, как:

• Создать репозиторий в GitHub
• Инициализировать Git в своем проекте
• Добавить и зафиксировать свой проект
• Отправить проект на GitHub
• Добавить и удалить файл из репозитория

Как создать репозиторий в Github 900 Я построил пример проекта выше, используя HTML и CSS. Чтобы инициализировать Git для проекта, мне нужно будет создать новый репозиторий в моей учетной записи GitHub.

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

Как инициализировать Git

Мы не можем использовать Git в нашем проекте, если мы не инициализируем/запускаем его сначала с помощью команды git init .

Итак, после создания репозитория в GitHub я открою проект в своем редакторе кода VS, перейду к своему терминалу, а затем воспользуюсь git init команда для инициализации/запуска.

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

Кроме того, когда вы открываете папку, в которой хранится/находится ваш проект, вы увидите еще одну папку с именем .git , которая была автоматически создана при выполнении команды git init .

Папка git add.git

Как добавить и зафиксировать свой проект

Как использовать команду

git add

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

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

git add

Как использовать команду

git commit

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

Итак, после того, как ваш проект был добавлен в промежуточную область, следующее, что вам нужно сделать, это зафиксировать его с помощью git commit –m «первая фиксация» команда.

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

Как отправить проект на GitHub

Отправка проекта на Github помогает предотвратить его повреждение или потерю в локальном хранилище. Он также позволяет вам свободно получать доступ к репозиторию GitHub из любого места и с любого компьютера (не обязательно с вашего персонального компьютера).

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

Для этого вы будете использовать команду git remote add origin (имя репозитория) . В моем случае имя моего репозитория — https://github.com/Derekvibe/FoodResturant.git . Запись в терминале должна выглядеть так:

git remote add origin https://github.com/Derekvibe/FoodResturant.git

Если вы не уверены в текущей ветке, над которой работаете, использовать git ветка команда. Если он отображает ветку как master , мы изменим ее на ветку main , выполнив команду git branch –M main .

(моя ветка git)

В моем случае я уже настроил ветку по умолчанию на ветку main , когда устанавливал Git на свой компьютер, выполнив команду git config –global init. default branch main . Поэтому мне не нужно снова запускать команду git branch –M main .

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

Для этого выполните команду git push –u origin main и дождитесь ее полной загрузки.

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

С этого момента после внесения изменений в проект вам просто нужно добавить изменения в область подготовки, запустив git add . Команда . Затем вы можете зафиксировать его с помощью git commit –m «(имя фиксации)» и отправить его в репозиторий Git с помощью git push –u origin main .

Как добавить и удалить файл из репозитория

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

Как добавить новый файл в существующий репозиторий

Напомним: я добавил в свой проект новый файл с именем newfile.txt . Я добавил его в тестовую область, запустив git add newfile.txt , затем зафиксировал его с помощью git commit –m «new commit» и отправил его на GitHub, как мы делали, когда хотели загрузить весь проект на GitHub. .

Когда я обновил свою страницу GitHub, я должен увидеть новый файл, который я создал.

Как удалить файл из существующего репозитория

Если я хочу удалить только что созданный файл из моего проекта в GitHub, я могу сделать это, выполнив команду git rm newfile.txt в терминале.

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

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

Заключение

Из этого руководства вы узнали, как использовать основные команды Git для управления вашими проектами.

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

Надеюсь, этот урок был вам полезен.

Получайте удовольствие от программирования!

---

---

Научитесь программировать бесплатно. Учебная программа freeCodeCamp с открытым исходным кодом помогла более чем 40 000 человек получить работу в качестве разработчиков. Начать

Как использовать Git и GitHub в команде как профессионал — с участием Гарри и Гермионы 🧙

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

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

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

Чтобы начать работу с рабочими процессами Git, рекомендуется ознакомиться с этим учебным пособием по сравнению рабочих процессов.

Проект

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

Они решили использовать GitHub в качестве центрального репозитория, в котором будет храниться вся их работа. В качестве стека технологий для приложений они выбрали React и Ruby on Rails.

Команда

Зельеварение будет создано самими Гарри и Гермионой на их сбережения. Они будут работать в своем домашнем гараже и ожидают, что MVP будет готов через 4 недели.

Давайте посмотрим, как они будут работать вместе над созданием продукта SaaS, и какие препятствия им придется преодолеть при этом.

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

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

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

 мой_адрес_электронной_почты[email protected]
мой_адрес_электронной_почты+hermione@gmail. com
 

Подробнее об этом здесь.

Шаг 1. Как создать две разные учетные записи GitHub

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

Шаг 2: Как настроить локальную среду разработки

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

Мы должны убедиться, что Git установлен в нашей системе:

 git --version
 

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

 sudo apt установить git
 

Шаг 3: рекомендации по совместной работе

Гарри будет работать локально в нашей среде разработки, а Гермиона выберет работу непосредственно на GitHub, используя онлайн-код VSCode (подробнее об этом позже).

С чего начать работу над проектом

Шаг 1: Как создать репозиторий и собрать команду (бесплатно)

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

Чтобы создать репозиторий, она просто воспользовалась веб-интерфейсом GitHub и щелкнула вкладку Репозитории , а затем кнопку Новый . Она назвала репозиторий potionfy и добавила краткое описание и файл Readme.md .

После создания хранилища она пригласила Гарри поработать над ним. Для этого она щелкнула вкладку Настройки в репозитории potionfy , затем в Управление доступом и, наконец, кнопка Добавить людей .

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

Через пару секунд Гарри получил приглашение на свою электронную почту:

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

ПРИМЕЧАНИЕ: В случае, если ссылка-приглашение не работает (как в моем случае), Гарри необходимо перейти в профиль Гермионы на GitHub, нажать на значок репозиторий potionfy и примите приглашение:

Шаг 2: Как создать файл

Гермиона начала проект с создания начального файла, который будет использовать продукт Potionfy SaaS: index.html .

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

Затем она добавила имя файла, его содержимое и осмысленное сообщение фиксации. После нажатия на Кнопка Commit new file , файл создан в репозитории.

Шаг 3: Как создать проблему и работать над ней

Гермионе нужно заняться маркетингом, связанным с запуском Potionfy, поэтому она попросила Гарри добавить простое посадочное сообщение в файл index. html . Итак, она приступила к созданию проблемы в репозитории, щелкнув вкладку Проблемы и нажав кнопку Новая проблема .

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

Работая с этой динамикой, команда будет знать, кто над чем работает.

Шаг 4: Как настроить локальную среду разработки

Чтобы работать с файлом проекта index.html , Гарри решил работать локально, поэтому ему нужно было клонировать репозиторий potionfy в своей среде разработки ( виртуальная машина Linux).

Первое, что ему нужно было сделать, это настроить ключи SSH для работы с GitHub. Он следил за созданием нового ключа SSH на GitHub и добавлял его в руководство по ssh-agent. Затем он добавил ключ в свою учетную запись GitHub, следуя руководству по добавлению нового ключа SSH в учетную запись GitHub.

Затем Гарри открыл репозиторий Гермионы на GitHub и скопировал ссылку для его клонирования:

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

 $ mkdir ~/разработка
$ cd ~/разработка
 

Наконец, он клонировал репозиторий, набрав git clone и вставив код, который он только что скопировал с GitHub (это адрес репозитория ):

 $ git clone [email protected]:Hermione-Colo- Коды /potionfy.git
 

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

 $ ll
всего 12
drwxrwxr-x 3 параллели параллели 4096 17 ноября 07:34 ./
drwxr-xr-x 23 параллели параллели 4096 ноя 17 07:33 ../
drwxrwxr-x 3 parallels parallels 4096 17 ноября 07:34 potionfy/
 

Рабочий процесс GitHub

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

1. Создать ветку
2. Внести изменения
3. Создать запрос на вытягивание
4. Просмотр комментариев
9003 9003 Удалить свой филиал

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

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

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

Он решил сделать это в репозитории GitHub, но он мог сделать то же самое в своей локальной среде с помощью команд Git.

Он выбрал осмысленное имя и поставил перед ним номер соответствующей проблемы (в данном случае это 1 ).

Дополнительную информацию о том, как создать ветку на GitHub, можно найти здесь.

Шаг 2: Локальная работа над веткой

После создания ветки Гарри начал над ней работать.

git pull

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

 ~/разработка/potionfy$ git тянуть
Предупреждение: ключ хоста ECDSA для IP-адреса «13.237.44.5» навсегда добавлен в список известных хостов.
Из github.com: Hermione-Colo-Codes/potionfy
 * [новая ветвь] 1-add-landing-message -> origin/1-add-landing-message
Уже в курсе. 
 

git checkout

Имея новую ветку в своей среде, он переключился на нее с помощью команды git checkout . После этого он убедился, что работает в правильной ветке с помощью команды git branch .

 ~/development/potionfy$ git checkout 1-add-landing-message
Ветвь «1-add-landing-message» настроена для отслеживания удаленной ветки «1-add-landing-message» из «origin».
Переключился на новую ветку «1-добавить-целевое-сообщение»
~/development/potionfy$ ветка git
* 1-добавить целевое-сообщение
  главный
 

Решить проблему

Гарри начал работать над решением проблемы. Для этого он открыл файл index.html и добавил к нему заголовок h2 .

После внесения изменений он увидел, как Git отреагировал на это изменение.

 ~/development/potionfy$ git статус
На ветке 1-добавить посадочное-сообщение
Ваша ветка обновлена ​​с помощью «origin/1-add-landing-message». 
Изменения, не подготовленные для фиксации:
  (используйте "git add ...", чтобы обновить то, что будет зафиксировано)
  (используйте «git restore ...», чтобы отменить изменения в рабочем каталоге)
    изменено: index.html
в фиксацию не добавлено никаких изменений (используйте «git add» и/или «git commit -a»)
parallels@parallels-Parallels-Virtual-Platform:~/development/potionfy$
 

Затем он добавил файл в промежуточную область с помощью команды git add и зафиксировал изменение с помощью команды git commit .

 ~/development/potionfy$ git добавить -A
~/development/potionfy$ git commit -m "Добавить посадочное сообщение. #1"
~/development/potionfy$ статус git
 

Обратите внимание, что сообщение фиксации также включает идентификатор проблемы, который в данном случае #1 .

Отправка в репозиторий

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

 ~/разработка/potionfy$ git push
 

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

Затем Гарри нажал кнопку Сравнить и запрос на вытягивание в репозитории GitHub (убедившись, что его ветка выбрана в раскрывающемся меню ветки слева).

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

Краткий обзор

До этого момента в руководстве мы узнали, как Гарри и Гермиона решили создать приложение SaaS, позволяющее людям создавать свои собственные зелья онлайн и делиться ими с остальным миром. Они назвали это Зельеварение .

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

Теперь мы увидим:

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

Как проводить проверку кода

Шаг 1. Как создать проверку кода

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

Для этого она открывает репозиторий GitHub и щелкает вкладку Запросы на включение , чтобы найти запрос на вытягивание Гарри.

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

Она не совсем уверена в коде

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

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

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

Шаг 2: Как обратиться к обзору и создать изменение кода

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

Гарри отвечает на комментарий Гермионы и нажимает кнопку Разрешить разговор .

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

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

Гарри снова проверяет запрос на вытягивание и обнаруживает, что он содержит Запрошенных изменений .

Шаг 3: Как внедрить изменения

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

 $ git checkout 1-добавить-целевое-сообщение
 

Убедившись, что он работает с правильной веткой, он вносит изменения в файл index. html .

Примечание: для простоты мы не создаем здесь отдельный файл CSS.

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

 $ git добавить -A
$ git commit -m "Добавить цвет и удалить текст. #1"
$ git толчок
 

Шаг 4: Как объединить запрос на включение

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

Затем она щелкает вкладку Файлы изменены и находит те, которые она предложила внедрить в файл index.html .

Поскольку она удовлетворена изменениями, она переходит к их утверждению, нажав кнопку Проверить изменения и выбрав Утвердить 9вариант 0115.

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

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

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

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

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

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

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

После того, как группа проблем будет решена, эта ветка разработки будет объединена с основной веткой (или производство ), что обычно означает изменение версии в приложении.

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

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

Как справляться с конфликтами слияния в Git

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

Как только задача создана, Гарри решает начать над ней работать. Для этого он ответвляется от ветки разработки (путем выбора этой ветки в интерфейсе GitHub) новой ветки с именем 3-email-form (включая номер проблемы в начале, чтобы было ясно, как эта ветвь будет относиться к Проблемы).

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

 $ git тянуть
$ git checkout 3-форма
 

Гарри решает включить простую форму в файл index.html :

 

Имя:

    

    Электронная почта:

    

    
    <тип ввода="сброс" значение="Сброс">

 

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

Гарри размещает и фиксирует свои изменения локально, используя контактную форму . #3 сообщение.

 $ git добавить -A
$ git commit -m "Контактная форма. №3"
$ git толчок
 

Прежде чем Гарри смог создать новый запрос на вытягивание, Гермиона решает самостоятельно создать заполнитель для формы в файле index. html . Для этого она создает новую ветку из development с именем 3-email-form-placeholder .

Для работы с файлом index.html она использует онлайн-редактор кода GitHub (по сути, VSCode для Интернета). Чтобы открыть его, она просто нажимает . на ее клавиатуре, и страница GitHub превращается в интерфейс VSCode (как по волшебству 😉).

Затем она добавляет в файл следующий код:

После сохранения файла она фиксирует изменения прямо в окне своего браузера с помощью графического интерфейса VSCode:

После завершения фиксации она снова открывает GitHub и решает создать собственный запрос на включение и объединить свои изменения с развивать филиал .

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

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

Гарри предполагает, что его ветвь больше не отражает состояние ветки разработки и что ветвь разработки изменилась, потому что кто-то еще объединил изменения, затрагивающие файл index.html , над которым он работал. Тем не менее, он продолжает создавать запрос на включение.

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

Теперь он может видеть, что index.html действительно был изменен, и изменения, внесенные в этот файл, затрагивают строки, которые он сам модифицировал.

Дополнительные сведения об устранении конфликтов см. в статье Разрешение конфликта слияния на GitHub.

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

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

Наконец-то его ветка стала бесконфликтной, и он может объединить свой запрос на извлечение (при условии, что Гермиона просмотрела его код и одобрила его, как она сделала ранее).

Конфликты часто возникают, когда товарищи по команде работают над разными ветвями, затрагивающими общий файл. Отличный способ предотвратить конфликты слияния — выполнить запрос pull в ветке разработки , объединить обновленную разверните ветку в ветку, над которой вы работаете, а затем выполните push , за которым следует pull request .

 $ ветка git
x-my-branch # Это пример имени
$ git checkout разработать
$ git тянуть
$ git checkout x-моя ветка
$ git слияние разработки
# Вы вносите некоторые изменения в файлы ветки x-my-branch
$ git добавить -A
$ git commit -m "<сообщение>"
$ git толчок
 

Заключительные мысли

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

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

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

🐦 Вы можете подписаться и связаться со мной в моем аккаунте Twitter .

Ура!

Дамиан.-

Научитесь программировать бесплатно. Учебная программа freeCodeCamp с открытым исходным кодом помогла более чем 40 000 человек получить работу в качестве разработчиков. Начать

Как работать с репозиторием git?

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

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

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

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

Что такое удаленный сервер?

Удаленный сервер — это не что иное, как удаленный компьютер. Например, сервер битбакет. Bitbucket предоставляет способ управления репозиториями git.

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

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

Как управлять репозиторием git?

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

• с помощью командной строки
• с помощью веб-приложения, такого как bitbucket
• с помощью графического инструмента, такого как sourcetree

Как создать новый репозиторий git с помощью cli?

Допустим, вас наняли в качестве нового разработчика, и вы впервые используете git. Вы установили инструмент командной строки git на свой компьютер Mac, Linux или Windows.

Если вы не знаете, как установить git на свой компьютер, перейдите по ссылке ниже:

Установите git на Mac/Windows/Linux

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

Ниже приведены некоторые шаги, которые вы делаете при работе с git:

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

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

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

 # создать новый каталог проекта
mkdir новый проект
# перейдите в папку вашего нового проекта
компакт-диск новый проект
# сообщаем git, что это будет наш
# корневой каталог проекта локально
git инициировать
# добавим несколько тестовых файлов
# добавляем 5 тестовых текстовых файлов
сенсорный файл{1..5}.txt​ 

Как проверить статус файлов git?

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

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

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

 статус git 

После запуска вышеуказанной команды вы увидите следующий вывод в окне терминала:

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

Как добавить файлы в репозиторий git?

Чтобы добавить эти незащищенные файлы в наш локальный репозиторий git, нам нужно выполнить следующую команду:

 git добавить *. txt 

Команда Git add добавляет файлы в репозиторий git. Теперь нам нужно снова проверить статус этих файлов, чтобы увидеть, действительно ли они добавлены в наш репозиторий git или нет. Давайте проверим статус этих файлов, используя следующую команду:

 статус git 

Команда выше выведет что-то вроде следующего:

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

Как зафиксировать изменения git?

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

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

 # git commit принимает опцию -m
# чтобы добавить сообщение, связанное с вашим
# текущий коммит.  Это хорошая практика
# чтобы всегда добавлять сообщение с описанием ваших изменений
git commit -m "мои первые изменения git" 

Когда вы запустите вышеуказанную команду, вы увидите следующий вывод:

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

 статус git 

Вышеупомянутая команда теперь выводит что-то вроде следующего:

Это дает вам сообщение типа ничего не делать, рабочий каталог чист

На этом этапе вы добавили все файлы вашего проекта в локальный репозиторий git. Вы зафиксировали все свои изменения в репозитории git.

Что вы узнали сегодня?

Вы можете не знать, но вы получите некоторые навыки работы с git, следуя нашему руководству. Некоторые из навыков приведены ниже:

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

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

Получить уведомление

Подпишитесь на нашу рассылку и получайте уведомления о выходе новых статей !!

нет содержимого

Общие команды Git — узнайте, как использовать Git.

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

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

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

git init

Эта команда превращает каталог в пустой репозиторий Git. Это первый шаг в создании репозитория. После запуска git init возможно добавление и фиксация файлов/каталогов.

Использование:

 # изменить каталог на кодовую базу
$ cd /файл/путь/к/коду
# сделать каталог git-репозиторием
$ git init 

На практике:

 # изменить каталог на кодовую базу
$ cd /Пользователи/имя-компьютера/Документы/веб-сайт
# сделать каталог git-репозиторием
$ git инициировать
Инициализирован пустой репозиторий Git в /Users/имя-компьютера/Documents/website/.git/ 

git add

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

Использование:

 $ git add <имя файла или каталога> 

На практике:

 # Чтобы добавить все файлы, которые не были подготовлены:
$ git добавить. 
# Чтобы подготовить определенный файл:
$ git добавить index.html
# Чтобы подготовить весь каталог:
$ git добавить css 

git commit

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

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

Использование:

 # Добавление фиксации с сообщением
$ git commit -m "Сообщение фиксации в кавычках" 

На практике:

 $ git commit -m "Мое первое сообщение фиксации"
[SecretTesting 0254c3d] Мое первое сообщение коммита
1 файл изменен, 0 вставок(+), 0 удалений(-)
режим создания 100644 домашняя страница/index.html 

git status

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

git status вернет текущую рабочую ветку. Если файл находится в промежуточной области, но не зафиксирован, он отображается со статусом git . Или, если изменений нет, он вернет ничего для фиксации, рабочий каталог чист.

Использование:

 $ git status 

На практике:

 # Сообщение, когда файлы не были подготовлены (git add)
$ гит статус
На ветке SecretTesting
Неотслеживаемые файлы:
  (используйте "git add ...", чтобы указать, что будет зафиксировано)
  домашняя страница/index.html
# Сообщение, когда файлы не были зафиксированы (git commit)
$ гит статус
На ветке SecretTesting
Ваша ветка обновлена ​​с помощью «origin/SecretTesting».
Изменения, которые необходимо зафиксировать:
  (используйте "git reset HEAD ...", чтобы убрать стадию)
        новый файл: домашняя страница/index.html
# Сообщение, когда все файлы подготовлены и зафиксированы
$ гит статус
На ветке SecretTesting
ничего не коммитить, рабочий каталог чистый 

git config

С Git возможно множество конфигураций и настроек. git config как назначить эти настройки. Два важных параметра — user user. name и user.email. Эти значения определяют, с какого адреса электронной почты и имени будут выполняться коммиты на локальном компьютере. С git config флаг —global используется для записи настроек во все репозитории на компьютере. Без флага —global настройки будут применяться только к текущему репозиторию, в котором вы сейчас находитесь.

Есть много других переменных, доступных для редактирования в git config . От редактирования цветных выводов до изменения поведения git status . Узнайте о настройках git config в официальной документации Git.

Использование:

 $ git config <настройка> <команда> 

На практике:

 # Глобальный запуск git config
$ git config --global user.email "[email protected]"
$ git config --global user.name "Брайан Керр"
# Запуск git config для текущих настроек репозитория
$ git config user.email "[email protected]"
$ git config user.name "Брайан Керр" 

ветвь git

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

Использование:

 # Создать новую ветку
$ git ветка <имя_ветки>
# Список всех удаленных или локальных веток
$ git ветка -a
# Удалить ветку
$ git branch -d  

На практике:

 # Создать новую ветку
$ git ветка new_feature
# Список веток
$ git ветка -a
* Секретное тестирование
  новая особенность
  пульты/происхождение/стабильный
  пульты/происхождение/постановка
  пульты/происхождение/мастер -> происхождение/SecretTesting
  
# Удалить ветку
$ git ветка -d новая_функция
Удалена ветка new_feature (была 0254c3d). 

git checkout

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

Использование:

 # Проверить существующую ветку
$ git checkout <название_ветки>
# Оформить заказ и создать новую ветку с таким именем
$ git checkout -b  

На практике:

 # Переключение на ветку 'new_feature'
$ git checkout новая_функция
Переключено на ветку 'new_feature'
# Создание и переход на ветку 'staging'
$ git checkout -b постановка
Перешел на новую ветку "постановка" 

git merge

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

Использование:

 # Объединить изменения в текущую ветку
$ git merge  

На практике:

 # Слить изменения в текущую ветку
$ git слить новую_функцию
Обновление 0254c3d..4c0f37c
Перемотка вперед
 домашняя страница/index.html | 297 +++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++
 1 файл изменен, 297 вставок(+)
 режим создания 100644 homepage/index.html 

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

git remote

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

Использование:

 # Добавить удаленный репозиторий
$ git remote <команда>  
# Список именованных удаленных репозиториев
$ git remote -v 

На практике:

 # Добавление удаленного репозитория с именем beanstalk
$ git удаленное добавление источника git@account_name. git.beanstalkapp.com:/acccount_name/repository_name.git
# Список именованных удаленных репозиториев
$ git удаленный -v
происхождение git@account_name.git.beanstalkapp.com:/acccount_name/repository_name.git (выборка)
происхождение git@account_name.git.beanstalkapp.com:/acccount_name/repository_name.git (push) 

Примечание. Удаленный репозиторий может иметь любое имя. Общепринятой практикой является называть удаленный репозиторий «origin».

git clone

Чтобы создать локальную рабочую копию существующего удаленного репозитория, используйте git clone для копирования и загрузки репозитория на компьютер. Клонирование эквивалентно git init при работе с удаленным репозиторием. Git создаст локальный каталог со всеми файлами и историей репозитория.

Использование:

 $ git clone  

На практике:

 $ git clone git@account_name.git.beanstalkapp.com:/acccount_name/repository_name.git
Клонирование в 'repository_name'. ..
удаленный: Подсчет объектов: 5, готово.
remote: Сжатие объектов: 100% (3/3), готово.
удаленный: всего 5 (дельта 0), повторно используется 0 (дельта 0)
Получение объектов: 100% (5/5), 3,08 КиБ | 0 байт/с, готово.
Проверка подключения... сделано. 

git pull

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

Использование:

 $ git pull   

На практике:

 # Извлечение с именованного удаленного
$ git pull origin staging
Из имя_учетной_записи.git.beanstalkapp.com:/имя_учетной_записи/имя_репозитория
 * постановка ветки -> FETCH_HEAD
 * [новая ветвь] постановка -> источник/постановка
Уже актуальный.
# Извлечь из URL (не часто используется)
$ git pull git@account_name.git.beanstalkapp.com:/acccount_name/repository_name.git staging
Из имя_учетной_записи.git.beanstalkapp.com:/имя_учетной_записи/имя_репозитория
 * постановка ветки -> FETCH_HEAD
 * [новая ветвь] постановка -> источник/постановка
Уже актуальный.  

git push

Отправляет локальные коммиты в удаленный репозиторий. git push требует два параметра: удаленный репозиторий и ветку, для которой выполняется push.

Использование:

 $ git push  <ветка>
# Отправляем все локальные ветки в удаленный репозиторий
$ git push —all 

На практике:

 # Отправка конкретной ветки на удаленный сервер с именованным удаленным
$ git push отправка исходного кода
Подсчет предметов: 5, готово.
Дельта-сжатие с использованием до 4 потоков.
Сжатие объектов: 100% (3/3), готово.
Запись объектов: 100% (5/5), 734 байта | 0 байт/с, готово.
Всего 5 (дельта 2), повторно использовано 0 (дельта 0)
Кому git@account_name.git.beanstalkapp.com:/acccount_name/repository_name.git
   объявление189cb..0254c3d Секретное тестирование -> Секретное тестирование
# Отправляем все локальные ветки в удаленный репозиторий
$ git push --все
Подсчет предметов: 4, готово.
Дельта-сжатие с использованием до 4 потоков. 
Сжатие объектов: 100% (4/4), сделано.
Запись объектов: 100% (4/4), 373 байта | 0 байт/с, готово.
Всего 4 (дельта 2), повторно использовано 0 (дельта 0)
удаленный: Разрешение дельт: 100% (2/2), комплектуется 2 локальными объектами.
Кому git@account_name.git.beanstalkapp.com:/acccount_name/repository_name.git
   0d56917..948ac97 мастер -> мастер
   объявление189cb..0254c3d SecretTesting -> SecretTesting 

Расширенные команды Git

git stash

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

Использование:

 # Хранить текущую работу с неотслеживаемыми файлами
$ git тайник -u
# Вернуть спрятанную работу в рабочий каталог
$ git тайник поп 

На практике:

 # Сохранить текущую работу
$ git тайник -u
Сохраненный рабочий каталог и состояние индекса WIP на SecretTesting: 4c0f37c Добавление нового файла в ветку
HEAD теперь находится по адресу 4c0f37c Добавление нового файла в ветку
# Вернуть спрятанную работу в рабочий каталог
$ git тайник поп
На ветке SecretTesting
Ваша ветка и "origin/SecretTesting" разошлись,
и иметь 1 и 1 разные коммиты соответственно. 
  (используйте «git pull», чтобы объединить удаленную ветку с вашей)
Изменения, не подготовленные для фиксации:
  (используйте "git add ...", чтобы обновить то, что будет зафиксировано)
  (используйте "git checkout -- ...", чтобы отменить изменения в рабочем каталоге)
        изменено: index.html
в фиксацию не добавлено никаких изменений (используйте «git add» и/или «git commit -a»)
Утеряны ссылки/тайник@{0} (3561897724c1f448ae001edf3ef57415778755ec) 

git log

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

Использование:

 # Показать весь журнал git
$ git журнал
# Показать журнал git с параметрами даты
$ git log --<после/до/с/до>=<дата>
# Показать журнал git на основе автора коммита
$ git log --="Имя автора"
 

На практике:

 # Показать весь журнал git
$ git журнал
совершить 4c0f37c711623d20fc60b9cbcf393d515945952f
Автор: Брайан Керр  com>
Дата: Вт, 25 октября 17:46:11 2016 -05:00
    Обновление формулировки нижнего колонтитула главной страницы
    
совершить 0254c3da3add4ebe9d7e1f2e76f015a209e1ef67
Автор: Эшли Харпп 
Дата: 19 октября 16:27:27 2016 -05:00
    Мое первое сообщение коммита
# Показать журнал git с параметрами даты
$ git log --before="20 октября"
зафиксировать 0254c3da3add4ebe9d7e1f2e76f015a209e1ef67
Автор: Эшли Харпп 
Дата: 19 октября 16:27:27 2016 -05:00
    Мое первое сообщение коммита
# Показать журнал git на основе автора коммита
$ git log --author="Брайан Керр"
совершить 4c0f37c711623d20fc60b9cbcf393d515945952f
Автор: Брайан Керр 
Дата: Вт, 25 октября 17:46:11 2016 -05:00
    Обновление формулировки нижнего колонтитула главной страницы 

git rm

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

No related posts.