Git в командной строке windows — Ваш верный помощник с OS Windows

1.4 Введение — Командная строка

Командная строка

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

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

Источник

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

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

Больше из рубрики Git: введение, основные команды, решение проблем.

Когда мы пишем код, мы постоянно туда что-то добавляем, удаляем, и иногда всё может ломаться. Поэтому перед любыми изменениями стоит сделать копию проекта. Если собирать проекты в папки с именами проект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@example.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ls -al ~/.ssh

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

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

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

ssh-keygen -t ed25519 -C "your_email@example.com"

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

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Терминал спросит, куда сохранить ключ. Если не хотите менять имя файла, которое предлагает терминал, просто нажмите 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 AAAAC3NzaCZvnr4ax+Fr shklyar@htmlacademy.ru

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

Добавляем 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 git@github.com:your-nickname/your-project.git

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

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

➜  device git clone git@github.com: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 git@github.com:_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 git@github.com: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 должен проверить администратор мастер-репозитория — это может быть коллега-разработчик, техлид или наставник на курсе.

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

ТелеграмПодкастБесплатные учебники

Источник

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

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

Содержание

Установка и настройка

Установка
Настройка

Создание репозитория
Рабочий процесс

git add: добавление файлов в индекс
git status: проверка статуса репозитория
git commit: добавление файлов в репозиторий
git log: просмотр журнала коммитов
git show: просмотр коммита
git diff: просмотр изменений до коммита
git difftool: запуск внешнего инструмента сравнения файлов
git restore: отмена изменений
git rm: удаление файлов из индекса
git reset: откат коммита

Ветвление

git branch <branch_name>: создание новой ветки
git branch: просмотр веток
git checkout: переключение между ветками
git merge: слияние репозиториев
git branch -d <branch_name>: удаление ветки

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

git remote add origin url: привязка локального и удалённого репозитория
git remote: просмотр удалённых репозиториев
git remote — v: просмотр удалённых URL-адресов
git push: отправка изменений в удалённый репозиторий
git pull: получение изменений из удалённого репозитория

Практика по основным командам Git

Эксперт

Senior Java-разработчик в компании CDEK.

Эксперт Skillbox, в прошлом работал над программой курса по Java, был программным директором.

Git не входит в стандартный набор программ Windows и macOS. В Linux он встречается, однако не во всех дистрибутивах. Чтобы проверить его наличие, введите в «Терминале» команду:


git --version

Если Git установлен, вы увидете номер доступной версии. В противном случае вы увидете сообщение Unsupported command: git. Значит, утилиту нужно будет установить и настроить.

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

Windows. Скачайте установщик с git-scm.com. На сайте есть три версии:

стандартная 32-разрядная версия с последней сборкой;
автономная версия для установки Git без подключения к интернету;
портативный установщик для загрузки на флешку.

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

✔️ Use Git Bash as default shell — выберите программу Git Bash;
✔️ Integrate Git with the Windows Shell — согласитесь работать с Git через командную строку.

Также Git на Windows можно установить через менеджер пакетов winget от Microsoft. Для этого откройте оболочку PowerShell и введите команду:


winget install --id Git.Git -e --source winget

macOS. В программе «Терминал» установите менеджер пакетов Homebrew:


/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

После этого выполните команду:


$ brew install git

Другие способы установки Git на macOS описаны на сайте git-scm.com.

Linux. Перейдите на git-scm.com и скопируйте в «Терминал» команду для менеджера пакетов вашего Linux-дистрибутива. Вот некоторые варианты:


# Для Debian/Ubuntu 
apt-get install git

# Для Fedora 
yum install git

# Для OpenSUSE
zypper install git

Если у вас macOS или Linux, то после установки Git запустите «Терминал». Если Windows — Git Bash. В этих программах мы будем выполнять все команды.

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

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


git config --global  user.name "Name Surname"

Почту записываем в кавычках:


git config --global  user.email "your@email"

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


git config --global color.ui auto

Осталось убедиться, что данные добавлены и корректно отображаются:


git config --list

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

Переместитесь в папку с проектом и подключите Git:


git init

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

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

pwd — просмотр вашего текущего местоположения;
ls — список папок и файлов в текущей директории, где была выполнена команда;
ls -a — список открытых и скрытых папок и файлов в текущей директории, где была выполнена команда;
cd ~ — переход в домашнюю директорию текущего пользователя;
cd .. — переход на один уровень вверх в иерархии файловой системы;
cd folder_name — переход в выбранную папку;
mkdir folder_name — создать папку с указанным именем.

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

Если вы создадите в проекте файл, то Git его посчитает неотслеживаемым (untracked). Такие файлы нельзя перенести в репозиторий без подготовки к сохранению. За подготовку отвечает индекс — промежуточная зона перед репозиторием. Перенести файлы в индекс можно с помощью команды git add.

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


# Добавляем в индекс один файл
git add file_name
# Добавляем в индекс несколько файлов 
git add file_name_1 file_name_2 file_name_3
# Добавляем в индекс все изменённые файлы 
git add .

У команды git add есть ещё множество вариаций. Например, git add *.js перенесёт в индекс все файлы из текущей папки с расширением .js. Чтобы получить подробную документацию о какой-то команде — вызывайте справку:


git help command_name

Команда git status даёт представление о текущем состоянии репозитория. Она показывает, какие неотслеживаемые файлы попали в проект, какие файлы находятся в индексе и какие сохранённые файлы вы изменили в репозитории.


$ git status   # Запрашиваем текущее состояние репозитория
# Видим файлы, которые находятся в индексе и подготовлены для коммита
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   index.html
        modified:   styles.css
# Видим неотслеживаемые файлы, которые только попали в проект
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        script.js   # Файл script.js не отслеживается Git
# Видим изменённые файлы репозитория, которые ещё не добавлены в индекс 
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        README.md   # Файл README.md был изменён, но не добавлен в индекс

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


git commit -m "Commit message"

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

❌ Добавил свой первый коммит.

✅ Исправил баг №ХХХХХ.

❌ Работал над файлом index.html.

✅ Сверстал header для главной страницы.

Если убрать опцию -m, то после нажатия Enter вы попадёте в текстовый редактор. Там вам нужно будет написать сообщение, сохранить его и выйти. А в Vim это нереально ?

Бывает так: вы закоммитили файл и затем снова его изменяете. В этом случае можно делать новый коммит, минуя индекс. Для этого необходима опция -a:


git commit -am "Commit message"

Другая частая ситуация: вы торопились и ошиблись в сообщении коммита. Можно ввести опцию —amend и перезаписать сообщение последнего коммита:


git commit --amend -m "New commit message"

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


$ git log   # Запрос на просмотр журнала коммитов

# Информация о третьем сделанном коммите
commit 3f6f9e1f58e30e0d3a0d0ab764c0b30a5b621d4a   # Хеш первого коммита
Author: John Doe <johndoe@example.com>   # Автор первого коммита
Date:   Thu Apr 21 10:26:52 2024 +0300   # Дата первого коммита
    Update README.md   # Сообщение первого коммита

# Информация о втором сделанном коммите
commit acd1e81729dc2ee2dc107ba345fa1ab7e6cfbff9
Author: Jane Smith <janesmith@example.com>
Date:   Wed Apr 20 16:45:39 2024 +0300
    Add new feature

# Информация о первом сделанном коммите
commit 7df1e8c33b0a617b3a72c785a67e45d0d932a180
Author: John Doe <johndoe@example.com>
Date:   Mon Apr 18 09:12:21 2024 +0300
    Initial commit

У команды git log множество опций, от которых будет зависеть отображение журнала. Например, можно в одну строку расположить информацию о каждом коммите. Для этого придётся убрать дату, ник автора и сократить размер хеша:


$ git log --oneline   # Запрос на вывод истории коммитов в одну строку
3f6f9e1 Update README.md
acd1e81 Add new feature
7df1e8c Initial commit

Команда git show выводит информацию об одном коммите. Сообщение делится на два блока: часть с метаданными и список изменений, внесённых в коммит.


$ git show abc12345  # Запрос на просмотр коммита с хешем abc12345

# Метаданные
commit abc12345  # Хеш коммита
Author: John Doe <johndoe@example.com>  # Автор коммита
Date:   Thu Apr 21 10:26:52 2024 +0300  # Дата и время коммита
    Update README.md  # Сообщение коммита

# Список изменений в файле README.md
diff --git a/README.md b/README.md
index abcdef1..1234567 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,3 @@
-# My Project  # Старое содержимое строки
+# My Awesome Project  # Новое содержимое строки

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

Команда git diff показывает разницу между последним коммитом и текущим состоянием репозитория. То есть последний коммит сравнивается со всеми неотслеживаемыми файлами, которые ещё не переведены в индекс.

Можно добавить имя файла и сравнить его содержимое с последним коммитом.

Ещё вариант: вместо имени файла можно использовать хеш коммита. Также можно добавить опцию —staged и сравнить версию кода после последнего коммита с отслеживаемым состоянием репозитория — со всеми файлами, которые находятся в индексе.


# Смотрим разницу между последним коммитом и текущим состоянием репозитория
git diff

# Разница между последним коммитом и текущим состоянием файла 
git diff file_name

# Разница между последним коммитом и коммитом с указанным хешем 
git diff commit_hash

# Разница между последним коммитом и отслеживаемым состоянием репозитория 
git diff --staged

Команда git difftool работает по принципу команды git diff — сравнивает файлы и находит в них различия. Только git diff отображает результат в текстовом виде, а git difftool в графическом: команда запускает внешние программы с визуальными инструментами сравнения файлов. Если хотите попробовать — установите Beyond Compare, vimdiff, Meld или другое похожее приложение. После прочтите документацию по git difftool и попрактикуйтесь отображать данные.

Команда git restore возвращает файл к состоянию последнего коммита. Она отменяет все изменения, если файл не перенесён в индекс. Если файл попал в индекс, то вместе с названием команды нужно использовать опцию —staged.


# Вернуть неотслеживаемый файл к состоянию последнего коммита 
git restore file_name

# Вернуть все файлы из индекса к состоянию последнего коммита
git restore --staged 

# Вернуть указанный файл из индекса к состоянию последнего коммита
git restore --staged file_name

Команда git rm позволяет удалить файл, который по ошибке попал в индекс. После выполнения команды файл пропадёт из индекса и из папки на вашем компьютере, в которой хранится проект. Если вы хотите удалить файл только из индекса, то команду git rm нужно использовать вместе с опцией —cached.


# Удалить файл из индекса и рабочей директории
git rm file_name

# Удалить файл из индекса и оставить в папке на компьютере 
git rm --cached file_name

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

На выбор можно использовать три режима: —soft, —mixed и —hard.

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

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

В режиме —hard проект откатывается к указанному коммиту и удаляет все последующие коммиты без возможности их восстановления.


# Откатываемся и переводим последующие коммиты в индекс
git reset --soft commit_hash

# Откатываемся и переводим последующие коммиты в неотслеживаемую зону
git reset --mixed commit_hash

# Откатываемся и удаляем все последующие коммиты
git reset --hard commit_hash

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

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

После первого коммита Git автоматически создаёт первую ветку. Обычно в ней хранят стабильную версию проекта для пользователей продукта. Под остальные задачи разработчики создают отдельные ветки с помощью команды git branch:


git branch branch_name

По названию ветки должно быть понятно, что в ней происходит. Например, если в названии упоминается слово bugfix, то ветка предназначена для исправления ошибок. Слово feature указывает на разработку какой-то функции. А вот случайное название test10.24 не значит ничего, и таких названий лучше избегать.

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


git branch -m old_branch_name new_branch_name

# old_branch_name — старое имя ветки 
# new_branch_name — новое имя ветки

Команда git branch позволяет получить список всех доступных веток в проекте. Также она проставляет символ звёздочки слева от текущей активной ветки:


# Запрашиваем список всех доступных веток 
git branch

# Результат вывода
  bugfix/fix-bug
  * maine
  feature/new-feature

Команда git checkout позволяет переключиться с одной ветки на другую:


git checkout branch_name

Также можно одной командой создать новую ветку и сразу в неё перейти:


git checkout -b branch_name

У команды git checkout есть более современная альтернатива:


git switch branch_name

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

Команда git merge позволяет добавить изменения из одной ветки в другую. Такой процесс называется слиянием, и он завершается появлением общего коммита для объединённых веток. По этому коммиту можно отследить историю каждой ветки.


# Переключаемся на основную ветку, которая будет принимать изменения 
git checkout main_branch

# Сливаем изменения из второстепенной ветки в основную 
git merge secondary_branch

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


# Проверяем текущую ветку
git branch

# Результат вывода
  main_branch
  * secondary_branch

# Переключаемся на основную ветку
git checkout main_branch

# Удаляем второстепенную ветку
git branch -d secondary_branch

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

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

С помощью командной строки переместитесь в папку с проектом на своём компьютере. Теперь вы можете выполнить команду git remote add, которая установит связь между вашим локальным и удалённым репозиторием на GitHub.

К команде нужно добавить два параметра: имя вашего удалённого репозитория и его адрес. Адрес вы найдёте на странице своего профиля во вкладке SSH.


# Перемещение в папку с проектом
cd путь/к/папке/с/проектом

# Привязка локального репозитория к удалённому на GitHub
git remote add origin git@github.com:ваш_профиль/ваш_репозиторий.git

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


# Запрашиваем список удалённых репозиториев, которые связаны с локальным
git remote

# Пример вывода: два удалённых репозитория связаны с нашим локальным
  origin
  upstream

Команда git remote показывает только названия удалённых репозиториев, которые связаны с вашим локальным. К команде можно добавить опцию -v и посмотреть удалённые URL-адреса. По URL-адресам будет видно, какие изменения вы делали.


# Запрос списка удалённых репозиториев с URL-адресами
git remote -v

# Пример вывода с URL-адресами
  origin  https://github.com/user/repo.git (fetch)
  origin  https://github.com/user/repo.git (push)
  upstream  https://github.com/otheruser/repo.git (fetch)
  upstream  https://github.com/otheruser/repo.git (push)

Команда git push загружает изменения из локального репозитория в удалённый.

Во время первой загрузки нужно использовать команду с опцией -u. Это свяжет локальную и удалённую ветки и синхронизирует их для последующих операций. Для второй и всех последующих загрузок опция -u для связанных веток не понадобится.


# Команда для первой загрузки изменений в удалённый репозиторий: текущая ветка будет связана с веткой main в удалённом репозитории origin 
git push -u origin main

# Команда для второй и последующих загрузок изменений в удалённый репозиторий 
git push

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


# Скачиваем изменения из удалённого репозитория и добавляем их в локальную ветку
git pull

Попрактиковаться можно вместе с экспертами Skillbox.

Даниил Пилипенко, CEO центра подбора IT-специалистов SymbioWay, провёл вебинар по работе с системой управления версиями Git и её основным командам: git status, git add, git commit, git log, git branch, git clone и другим.

Вебинар Skillbox: основные команды для работы с Git и GitHub

Источник

Last Updated :
21 Apr, 2020

Git is very important and powerful tool when it comes to the software development life cycle. Now in this article, we are going to see why git is used vastly in the software industry and what kinds of operations we can perform with git. So git is basically a distributed version control system for tracking changes in source code during software development. Git is designed for coordinating work among developers, but it can be used to track changes in any set of files. Its goals include speed, data integrity, and support for distributed, non-linear workflows.
Git uses a version control system in which at some instances in a project a snapshot of the project is taken that is the progress made by that project is stored on a central repository. In simple words suppose the user is developing a web page first it will add its name and stored it as version then it added basic info and stored it as the second version then it added its profile picture and stored it as the third version now suppose the user added a wrong profile picture then there is always an option to revert back to the previous version after that it can add the correct profile picture.

Advantages of Version Control System

Storing Versions: As explained in the above example If we encounter some error in our project code we always have the option to revert back to the previous version with the help of git it is easy to store version. If we try to store them manually It will be a hard task.
Collaboration: In the software industry, multiple employees are working on the same project so with the help of version control system the main copy is stored on central remote server fetched by employees and after changes which are to be made are made employee uploads its own version to the central repository so others can fetch code updated by employees.
Backup: In case if a central repository is crashed then anyone can push its local copy to the central server. As while making changes it has to be made on the local repository.

Git can be used with GUI as well as command-line. In this article, we are going to use the command line.
GIT can be downloaded from here. After the successful installation of GIT, there is a need to configure git using the following commands:

Open terminal:
```
git --version
```
To check version of git

To set your username

git config --global user.name "FIRST_NAME LAST_NAME"

To set your email

git config --global user.email "MY_NAME@example.com"

Working with GIT commandline

Initializing a local repository:

git init

This command will initialise our local repository.

Now our repository is initialized we can add some code to our project

Checking status of the repository:
As you can see a .git file is created as mentioned above. Now to check the status of these files, the following command is used:

git status

Here, working area is where files that are not added to repository yet are stored. These files are called as ‘untracked files’. Staging area is files that are going to be a part of the next commit. Commit means basically storing a version of project at the current instance. As you add new files in your workspace you can add this files to staging area using git add command.

Adding files to the repository:

Now in the previous step we have seen that some files are untracked, with the help of git add filename we add these files to the staging area. git add command is used to add all files in the folder to the staging area

git add

After adding files to the staging area if git status is called again, then it will show files to be committed.

Committing changes:
Now files are ready to be committed they are ready to be added to the local repository

git commit -m "your message"

git commit command allows you to add your files to your local repository -m specifies that you have to pass commit message while committing a code

Every time a commit is made a SHA-256 key is created and assigned to that commit If we wanted to retrieve code at that commit it is possible using this id.

Accessing log of commits:

After you have created several commits, or if you have cloned a repository with an existing commit history, you’ll probably want to look back to see what has happened. That’s where git log comes in picture. This command allows us to see all commits made by user. With the help of commit id you can refer back to the previous version.

git log

Additional commands

git clone "Remote_repo_url"

With the help of git clone command, you can clone various repositories that are present on websites like GitHub, GitLab, bitbucket, etc.
Any repository can be cloned as follows:

git clone "https://github.com/sanketpathak64/Kickstarter-Campaign.git"

Parallel development commands

git branch branch_name

This command allows to create a branch for the project. A branch is like exact copy of the project.

git checkout branch_name

This command allows to switch from one branch to another.

git merge branch_name

This command allows to merge a code of 2 branches in one branch.

Источник

Введение

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

В целом СКВ можно разделить таким образом:

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

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

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

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

Принципы работы с Git

У проектных файлов в Git есть 3 базовых состояния

Измененные (modified) — файлы в процессе рабочего редактирования.
Индексированные (staged) — та часть измененных файлов, которая уже подготовлена к фиксации после редактирования.
Зафиксированные (committed) — файлы, уже сохраненные в локальном репозитории.

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

Чаще всего работа с Git устроена примерно так:

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

Установка Git

Создать свой проект и начать пользоваться Git в нем достаточно просто. Мы будем рассматривать работу в командной строке терминала, потому что там реализован полный набор команд. Вероятно, в будущем вам будет проще воспользоваться встроенными инструментами в крупном приложении (например, в Visual Studio, если вы программист).

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

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

Установка в Linux

Для дистрибутивов, похожих на Fedora, RHEL или CentOS, выполните команду dnf:

    > sudo dnf install git-all

На Ubuntu и других Debian-подобных систем введите apt:

    > sudo apt install git

Более подробные сведения можно получить по ссылке: https://git-scm.com/download/linux.

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

Один из способов установки — воспользоваться Xcode Command Line Tools. В терминале нужно ввести:

    > git --version

И следовать дальнейшим инструкциям.

Если вы пользуетесь Homebrew, запустите команду:

    $ brew install git

Подробности доступны по ссылке: https://git-scm.com/download/mac.

Установка в Windows

Новейшая сборка доступна на официальном сайте Git по ссылке: https://git-scm.com/download/win (загрузка запустится автоматически).

Настройка Git

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

Самый удобный способ изменения конфигурации — встроенная утилита git config. Настройки Git имеют три уровня:

Параметры из файла [path]/etc/gitconfig (системные) могут работать для всех пользователей системы и репозиториев. Они редактируются командой git config —system.
Параметры из файла ~/.gitconfig или ~/.config/git/config (глобальные) применяются к одному пользователю, если запустить команду git config —global.
Локальные параметры из файла config в рабочем каталоге .git/config сохраняют только для выбранного репозитория. Ему соответствует команда git config —local.

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

Всю используемую конфигурацию можно просмотреть так:

    > git config --list --show-origin

Представимся Git, чтобы в рабочих коммитах сохранялось ваше авторство:

    > git config --global user.name "Danil Z"
> git config --global user.email danilz@danilz.com

Также можно выбрать и текстовый редактор, введя команду git config —global core.editor. Например, чтобы выбрать Emacs, выполните:

    > git config --global core.editor emacs

В Windows нужно указывать полный путь к файлу. К примеру, для установки Notepad++ нужно запустить подобную команду:

    > git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

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

Общий список текущих настроек просматривается с помощью команды git config —list. Проверить, что записано в любой из доступных настроек, можно командой с ключом git config <key>:

    > git config user.email

Выбор ветки по умолчанию

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

    > git config --global init.defaultBranch main

Работа в репозитории

Как правило, есть два варианта начать работу с репозиторием Git:

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

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

Linux:

    > cd /home/user/SomeConsoleApp

macOS:

    > cd /Users/user/SomeConsoleApp

Windows:

    > cd C:/Users/user/SomeConsoleApp

Инициализируем репозиторий:

    > git init

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

И, наконец, нужно добавить под контроль версий все существующие файлы командой git add . (точка в конце важна!). Можно добавлять и по одному файлу, с помощью git add <имя файла>.

Заодно создадим начальный коммит командой git commit:

    > git add readme.md
> git commit -m 'Initial project version'

Команду git add можно гибко настраивать с помощью дополнительных параметров (флагов), которые подробно описаны в официальной документации: https://git-scm.com/docs/git-add. К примеру, команда git add —force добавит даже игнорируемые файлы, а git add —update позволит обновить отслеживаемые файлы.

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

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

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

В качестве примера мы будем рассматривать проект, который создадим на ресурсе https://github.com/ . После регистрации на сайте и подтверждения по e-mail нужно создать новый репозиторий, как показано на скриншотах.

Видно, что можно выбрать тип репозитория:

публичный (public) – доступ открыт для любого пользователя, однако права на редактирование выдает владелец проекта;
приватный/скрытый (private) — проект виден только владельцу, другие участники добавляются вручную.

Для нашего примера создадим приватный репозиторий под названием SomeConsoleApp и будем работать с ним далее.

Самые удобные способы клонирования проекта — через протоколы HTTP и SSH, прочесть обо всех более развёрнуто можно по ссылке: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols.

Для наших целей воспользуемся протоколом https и следующей командой:

    > git clone https://github.com/DanZDev2/SomeConsoleApp  SomeConsoleApp

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

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

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

Сохранение снимков и просмотр статуса проекта

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

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

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

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

    On branch master
Your branch is up to date with ‘origin/master’.

nothing to commit, working tree clean

Теперь отредактируем файлы (в этом примере было консольное демо-приложение, созданное с помощью Visual Studio) и сравним статус:

>git status
On branch master
Your branch is up to date with ‘origin/master’.
Untracked files:
(use “git add <file>...” to include in what will be committed)
	Program.cs
	SomeConsoleApp.csproj
	SomeConsoleApp.sln
nothing added to commit but untracked files present (use “git add” to track)

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

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

    > git commit -m "Task 2: basic project template added"

Для удаления ненужных файлов из репозитория можно использовать команду git rm <file-name>. Файл также пропадет из рабочего каталога. Выполнить коммит необходимо и в этом случае; до тех пор структура проекта не изменится.

Файл .gitignore

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

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

    /bin
/obj
*.pdb
*.exe

Если прописать такое содержимое файла .gitignore, то репозиторий git будет полностью игнорировать папки /bin и /obj, а также любые файлы с расширениями .pdb и .exe, хранящиеся в вашем рабочем каталоге.

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

Управление удаленными репозиториями

Просмотреть список текущих онлайн-репозиториев можно командой git remote. Добавить другие — с помощью команды git remote add <shortname> <url>, например:

    >git remote add myDemo https://github.com/DanZDev2/DemoApp
>git remote
myDemo
origin

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

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

Команда для отправки изменений на сервер такова: git push <remote-name> <branch-name>. Если ваша ветка называется master, то команда для отправки коммитов станет такой:

    > git push origin master

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

Следует к тому же помнить, что в разработке для промежуточных правок часто используется не главная ветка (master), а одна из параллельных (например, Dev). Работая в команде, этому обязательно нужно уделять пристальное внимание.

Получение изменений из репозитория (Pull)

Самый простой и быстрый способ получить изменения с сервера — выполнить команду git pull, которая извлечет (fetch) данные с сервера и попытается встроить/объединить (merge) их с вашей локальной версией проекта.

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

Создание веток и переключение между ними

Создадим две дополнительные ветки Dev и Test (например, одна может пригодиться для процесса разработки, а другая — для запуска в тестирование). Введем команду git branch <branch-name> дважды с разными аргументами:

    >git branch Dev
>git branch Test

Ветки созданы, но мы по-прежнему работаем в master. Для переключения на другую нужно выполнить git checkout <branch-name>:

    >git checkout Dev
Switched to branch ‘Dev’
Your branch is up to date with ‘origin/Dev’.

Внесем некоторые изменения в файл README.md и зафиксируем их, чтобы они отразились в ветке Dev:

    >git add .
>git commit -m “dev readme changed”
[Dev #####] dev readme changed
1 file changed, 2 insertions(+)

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

Для переключения обратно на ветку master нужно снова ввести команду git checkout master. Она не изменялась, а значит, после редактирования проекта ветки разойдутся. Это нормальная ситуация для проектов в Git. Важно только понимать, для каких целей используется каждая из веток, и не забывать вовремя переключаться между ними.

Слияние веток (merge)

Работа над проектами часто ведется в несколько этапов, им могут соответствовать ветки (в нашем примере Dev → Test → master). Отдельные ветки могут создаваться для срочного исправления багов, быстрого добавления временных функций, для делегирования части работы другому отделу и т. д. Предположим, что нужно применить изменения из ветки Dev, внеся их в master. Перейдем в master и выполним команду git merge <source-branch>:

    >git merge Dev
Updating #####..#####
Fast-forward
README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

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

Для разрешения конфликтов есть консольная утилита git mergetool. Однако если файл проекта объемный, а общих частей много, пользоваться ей не слишком удобно. Общая рекомендация для таких случаев — пользоваться сторонними инструментами, как и в случае с текстовым редактором для Git.

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

Дальнейшая работа с проектом из репозитория Git, как правило, повторяется по алгоритму:

pull (забрать изменения с сервера);

внести правки, добавить что-то важное в проекте;
add (добавить изменённые файлы к коммиту);
commit (сохранить состояние проекта с комментариями);
push (отправить изменения на сервер).
merge (при необходимости внедрить изменения из другой ветки проекта).

Заключение

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

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

Источник