Git инструкция шпаргалка для начинающих

В этой статье мы собрали команды 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

Картинка с сайта: skillbox.ru

Эксперт

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

Источник

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

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

Основы

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

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

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

Установка

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

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

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

Настройка

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

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

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

git config --list

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$ git add hello.txt

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

$ git add -A

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

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

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

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

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

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

git add index.html
git add css/style.css

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

git add .

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

git reset:
git reset css/style.css

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

git commit -m 'Add some code'

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

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

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

git log

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

git show hash_commit

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

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

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

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

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

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

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

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

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

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

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

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

# This is only an example. Replace the URI with your own repository address.
$ git remote add origin https://github.com/tutorialzine/awesome-project.git

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

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

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

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

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

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

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

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

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

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

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

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

Ветвление

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

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

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

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

$ git branch amazing_new_feature

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

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

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

$ git branch
amazing_new_feature
* master

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

$ git checkout amazing_new_feature

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

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

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

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

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

$ git checkout master

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

$ git merge amazing_new_feature

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

$ git branch -d awesome_new_feature

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

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

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

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

git branch -d local_branch_name

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

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

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

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

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

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

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

Вывод git log

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


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

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


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

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


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

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

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

$ git checkout 09bd8cc1 hello.txt

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

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

$ git revert HEAD

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

$ git revert b10cc123

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

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

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

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

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

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

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

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

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

Вывод

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Git bash и git.io

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

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

Заключение.

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

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

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

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

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

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

Источник

Инструкция-шпаргалка для начинающих

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

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

Если в один прекрасный момент вам ударило в голову желание насадить разумное, доброе, вечное, и пересадить всех с SVN на GIT, сразу встают три проблемы:

  • Объяснить зачем это нужно разработчикам и руководству
  • Ввести в обиход новую схему работы с кодом
  • Научить ничего не подозревающих девелоперов новым техникам

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

Основные постулаты работы с кодом:

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

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

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

Предупреждаю сразу, инструкция отвечает на вопрос «зачем» разработчику, незнакомому с DVCS, а не начальству.
Так же, предполагается, что master ветку никогда не трогают с —force, желательно, чтобы это было невозможно вообще (зарезано на уровне gitolite).
Инструкция — начинающих разработчиков, а не Tips & Tricks, из этих соображений я опустил моменты «выхода из самосозданной задницы». Все случаи не упомнишь, гораздо проще разрулить на месте по факту если что-то из ряда вон выходящее.

Собственно инструкция: Работа с Git.pdf (135Kb).
Для желающих адаптировать её к своей ситуации, исходник: Работа с Git.odt (90Kb).
p.s.: Забыл сказать о лицензии: Public Domain. Делайте что хотите, только в терновый куст не бросайте.

Буду благодарен каким-либо полезным комментариям, указанием на очепятки и прочему фидбеку.

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку

Источник

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

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

  1. Основы Git
  2. Коммиты
  3. Файловая система
  4. Просмотр изменений
  5. Удалённые репозитории
  6. Работа с ветками
  7. Продвинутое использование

Git — это система контроля версий (VCS), которая позволяет отслеживать и фиксировать изменения в коде: вы можете восстановить код в случае сбоя или откатить до более ранних версий. А ещё это must-have инструмент для взаимодействия нескольких разработчиков на одном проекте. Подробнее об этом в руководстве по командной разработке с Git.

С Git работают через командную строку или инструменты вроде GitHub Desktop. Команды Git принимают вид git <команда> <аргументы>, где аргументом может быть путь к файлу. В команды также включаются опции, которые обозначаются как --<опция>. Забыли, как использовать команду? Откройте руководство с git help <команда>.

Установка Git

Введение в Git всегда начинается с установки: скачайте Git для Windows, macOS или Linux и проверьте версию с помощью git --version.

Настройка конфигурационного файла

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

Вы можете напрямую отредактировать файл .gitconfig в текстовом редакторе или сделать это командой git config --global --edit. Для отдельных полей это git config --global <поле> <значение> — поля user.name и user.email.

Также можно настроить текстовый редактор для написания сообщений коммитов, используя поле core.editor. А вот поле commit.template позволяет указать шаблон, который будет использоваться при каждом коммите. Ещё одно полезное поле — alias, которое привязывает команду к псевдониму. Например, git config --global alias.st "status -s" позволяет использовать git st вместо git status -s

Команда git config --list выведет все поля и их значения из конфигурационного файла.

Создаём Git-репозиторий

Для инициализации нового репозитория .git подойдёт git init или, если хотите скопировать существующий, git clone <адрес репозитория>.

Введение в Git: от установки до основных команд 1

Картинка с сайта: tproger.ru

Коммиты

Основы работы с Git предполагают понимание коммитов. Команда git commit откроет текстовый редактор для ввода сообщения коммита. Также эта команда принимает несколько аргументов:

  • -m позволяет написать сообщение вместе с командой, не открывая редактор. Например git commit -m "Пофиксил баг";
  • -a переносит все отслеживаемые файлы в область подготовленных файлов и включает их в коммит (позволяет пропустить git add перед коммитом);
  • --amend заменяет последний коммит новым изменённым коммитом, что бывает полезно, если вы неправильно набрали сообщение последнего коммита или забыли включить в него какие-то файлы.

Советы для эффективного введения в Git:

  • Коммитьте как можно чаще.
  • Одно изменение — один коммит: не помещайте все не связанные между собой изменения в один коммит, разделите их, чтобы было проще откатиться.
  • Формат сообщений: заголовок должен быть в повелительном наклонении, меньше 50 символов в длину и должен логически дополнять фразу this commit will ___(this commit will fix bugs — этот коммит исправит баги). Сообщение должно пояснять, почему был сделан коммит, а сам коммит показывает, что изменилось.
  • Если у вас много незначительных изменений, хорошим тоном считается делать небольшие коммиты при разработке, а при добавлении в большой репозиторий объединять их в один коммит.

История коммитов в Git

Введение в Git: от установки до основных команд 2

Картинка с сайта: tproger.ru

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

Мы можем ссылаться на коммит либо через его контрольную сумму, либо через его позицию относительно HEAD, например HEAD~4 ссылается на коммит, который находится 4 коммитами ранее HEAD.

Файловая система Git

Введение в Git: от установки до основных команд 3

Картинка с сайта: tproger.ru

Git отслеживает файлы в трёх основных разделах:

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

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

Просмотр изменений в файловых системах

Команда git status отображает все файлы, которые различаются между тремя разделами. У файлов есть 4 состояния:

  1. Неотслеживаемый (untracked) — находится в рабочей директории, но нет ни одной версии в HEAD или в области подготовленных файлов (Git не знает о файле).
  2. Изменён (modified) — в рабочей директории есть более новая версия по сравнению с хранящейся в HEAD или в области подготовленных файлов (изменения не находятся в следующем коммите).
  3. Подготовлен (staged) — в рабочей директории и области подготовленных файлов есть более новая версия по сравнению с хранящейся в HEAD (готов к коммиту).
  4. Без изменений — одна версия файла во всех разделах, т. е. в последнем коммите содержится актуальная версия.

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

Мы можем использовать опцию -s для команды git status, чтобы получить более компактный вывод (по строке на файл). Если файл не отслеживается, то будет выведено ??; если он был изменён, то его имя будет красным, а если подготовлен — зелёным.

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

  • git diff — сравнение рабочей директории с областью подготовленных файлов;
  • git diff --staged — сравнение области подготовленных файлов с HEAD.

Если использовать аргумент <файл/папка>, то diff покажет изменения только для указанных файлов/папок, например git diff src/.

Обновление файловых систем

Команда git add <файл/папка> обновляет область подготовленных файлов версиями файлов/папок из рабочей директории.

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

Действие команды git reset <коммит> состоит из трёх потенциальных шагов:

  1. Переместить указатель HEAD на <коммит> (например, при откате коммита в рабочей директории и области подготовленных файлов будут более новые версии файлов, чем в HEAD). Также указатель HEAD ветки будет перемещён на этот коммит.
  2. Обновить область подготовленных файлов содержимым коммита. В таком случае только в рабочей директории будут новейшие версии файлов.
  3. Обновить рабочую директорию содержимым области подготовленных файлов. С этим нужно быть осторожнее, поскольку в итоге будут уничтожены изменения файлов.

По умолчанию команда git reset выполняет только шаги 1 и 2, однако её поведение можно изменить с помощью опций --soft (только 1 шаг) и --hard (все шаги).

Если передать путь к файлу/папке, то команда будет выполнена только для них, например git reset --soft HEAD~1 src/.

Команда git checkout HEAD <файл> приводит к тому же результату, что и git reset --hard HEAD <файл> — перезаписывает версию файла в области подготовленных файлов и в рабочей директорией версией из HEAD, то есть отменяет изменения после последнего коммита.

С другой стороны, git checkout <файл> (уже без HEAD) перезаписывает версию файла в рабочей директории версией в области подготовленных файлов, то есть отменяет изменения с момента последней подготовленной версии.

Наконец, git rm <файл> отменяет отслеживание файла и удаляет его из рабочей директории, опция --cached позволит сохранить файл.

Введение в Git: от установки до основных команд 4

Картинка с сайта: tproger.ru

Игнорирование файлов

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

  • файлы с чувствительной информацией вроде паролей;
  • большие бинарные файлы;
  • файлы сборок, которые генерируются после каждой компиляции;
  • файлы, специфичные для ОС/IDE, например, .DS_Store для macOS или .iml для IntelliJ IDEA — нам нужно, чтобы репозиторий как можно меньше зависел от системы.

Для игнорирования используется файл .gitignore. Чтобы отметить файлы, которые мы хотим игнорировать, можно использовать шаблоны поиска (считайте их упрощёнными регулярными выражениями):

  • /___ — позволяет избежать рекурсивности — соответствует файлам только в текущей директории;
  • __/ — соответствует всем файлам в указанной директории;
  • *___ — соответствует всем файлам с указанным окончанием;
  • ! — игнорирование файлов, попадающих под указанный шаблон;
  • [__] — соответствует любому символу из указанных в квадратных скобках;
  • ? — соответствует любому символу;
  • /**/ — соответствует вложенным директориям, например a/**/d соответствует a/d, a/b/d, a/b/c/d и т. д.

Мы даже можем использовать шаблоны поиска при указании файла/папки в других командах. Например, git add src/*.css добавит все файлы .css в папке src.

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

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

  • -p показывает изменения в каждом коммите;
  • --stat показывает сокращённую статистику для коммитов, например изменённые файлы и количество добавленных/удалённых строк в каждом их них;
  • -n показывает n последних коммитов;
  • --since=___ и --until=___ позволяет отфильтровать коммиты по промежутку времени, например --since="2019-01-01" покажет коммиты с 1 января 2019 года;
  • --pretty позволяет указать формат логов (например, --pretty=oneline), также можно использовать --pretty=format для большей кастомизации, например --pretty=format:"%h %s";
  • --grep и -S фильтруют коммиты с сообщениями/изменениями кода, которые содержат указанную строку, например, git log -S имя_функции позволяет посмотреть добавление/удаление функции;
  • --no-merges пропускает коммиты со слиянием веток;
  • ветка1..ветка2 позволяет посмотреть, какие коммиты из ветки 2 не находятся в ветке 1 (полезно при слиянии веток). Например, git log master..test покажет, каких коммитов из ветки test нет в master (о ветках поговорим чуть позже).
  • --left-right ветка1...ветка2 показывает коммиты, которые есть либо в ветке 1, либо в ветке 2, но не в обеих; знак < обозначает коммиты из ветка1, а > — из ветка2. Обратите внимание: используется три точки, а не две;
  • -L принимает аргумент начало,конец:файл или :функция:файл и показывает историю изменений переданного набора строк или функции в файле.

Другой полезной командой является git blame <файл>, которая для каждой строки файла показывает автора и контрольную сумму последнего коммита, который изменил эту строку. -L <начало>, <конец> позволяет ограничить эту команду заданными строками. Это можно использовать, например, для выяснения того, какой коммит привёл к определённому багу (чтобы можно было его откатить).

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

Примечание Не путайте git grep с git log --grep! Первый ищет по файлам среди коммитов, а последний смотрит на сообщения логов.

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

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

При использовании команды git clone <url репозитория> мы не только загружаем себе копию репозитория, но и неявно отслеживаем удалённый сервер, который находится по указанному адресу и которому присваивается имя origin.

Наиболее употребляемые команды:

  • git remote add <имя> <url> — добавляет удалённый репозиторий с заданным именем;
  • git remote remove <имя> — удаляет удалённый репозиторий с заданным именем;
  • git remote rename <старое имя> <новое имя> — переименовывает удалённый репозиторий;
  • git remote set-url <имя> <url> — присваивает репозиторию с именем новый адрес;
  • git remote show <имя> — показывает информацию о репозитории.

Следующие команды работают с удалёнными ветками:

  • git fetch <имя> <ветка> — получает данные из ветки заданного репозитория, но не сливает изменения;
  • git pull <имя> <ветка> — сливает данные из ветки заданного репозитория;
  • git push <имя> <ветка> — отправляет изменения в ветку заданного репозитория. Если локальная ветка уже отслеживает удалённую, то можно использовать просто git push или git pull.

Введение в Git: от установки до основных команд 5

Картинка с сайта: tproger.ru

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

GitHub

GitHub — это платформа, которая хранит Git-репозитории на своих серверах, и основы распределенной системы управления версиями Git подразумевает умение с ней работать. Вы можете хранить свои удалённые репозитории или участвовать в Open Source проектах на GitHub.

Да, есть и другие платформы, но GitHub идеален для введения в Git и дополняет VCS новыми возможностями.

Например, вы можете сделать форк удалённого репозитория, то есть создать свою копию репозитория на севере GitHub. Это полезно в тех случаях, когда у вас нет прав на создание ветки в оригинальном репозитории. Когда вы воспользуетесь командой git clone, ваш локальный репозиторий будет отслеживать удалённый форк как origin, а оригинальный репозиторий как upstream.

После этого вам может понадобиться слить тематическую ветку вашего удалённого репозитория в основную ветку оригинального. Для этого вы можете создать новый Pull Request — запрос на внесение изменений, где GitHub проверяет наличие конфликтов прежде чем повзолить вам провести слияние. Зачастую существуют и другие проверки перед слиянием, например просмотр и одобрение кода или даже запуск тестов. В запросе можно обсудить код, а все коммиты, которые вы отправляете в удалённую тематическую ветку, будут автоматически добавлены в запрос, даже если он был создан до этих коммитов.

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

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

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

Введение в Git: от установки до основных команд 6

Картинка с сайта: tproger.ru

Команды:

  • git branch <имя ветки> — создаёт новую ветку с HEAD, указывающим на HEAD. Если не передать аргумент <имя ветки>, то команда выведет список всех локальных веток;
  • git checkout <имя ветки> — переключается на эту ветку. Можно передать опцию -b, чтобы создать новую ветку перед переключением;
  • git branch -d <имя ветки> — удаляет ветку.

Локальный и удалённый репозитории могут иметь немало ветвей, поэтому когда вы отслеживаете удалённый репозиторий — отслеживается удалённая ветка (git clone привязывает вашу ветку master к ветке origin/master удалённого репозитория).

Привязка к удалённой ветке:

  • git branch -u <имя удалённого репозитория>/<удалённая ветка> — привязывает текущую ветку к указанной удалённой ветке;
  • git checkout --track <имя удалённого репозитория>/<удалённая ветка> — аналог предыдущей команды;
  • git checkout -b <ветка> <имя удалённого репозитория>/<удалённая ветка> — создаёт новую локальную ветку и начинает отслеживать удалённую;
  • git branch --vv — показывает локальные и отслеживаемые удалённые ветки;
  • git checkout <удалённая ветка> — создаёт локальную ветку с таким же именем, как у удалённой, и начинает её отслеживать.

В общем, git checkout связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как git reset перемещает общий HEAD.

Прятки и чистка

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

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

Однако порой у вас есть незавершённые изменения, которые нельзя фиксировать. В такой ситуации их можно сохранить и «спрятать» с помощью команды git stash. Чтобы вернуть изменения, используйте git stash apply.

Возможно, вместо этого вы захотите стереть все внесённые изменения. В таком случае используйте команду git clean. Опция -d также удалит неотслеживаемые файлы. Совет: добавьте опцию -n, чтобы увидеть, что произойдёт при запуске git clean без непосредственного использования.

Слияние

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

Слиние включает в себя создание нового коммита, который основан на общем коммите-предке двух ветвей и указывает на оба HEAD в качестве предыдущих коммитов. Для слияния мы переходим на основную ветку и используем команду git merge <тематическая ветка>.

Введение в Git: от установки до основных команд 7

Картинка с сайта: tproger.ru

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

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

			<<<<<<< HEAD:index.html
 Everything above the ==== is the version in master. 
 =======
 Everything below the ==== is the version in the test branch. 
 >>>>>>> test:index.html

Замените в этом блоке всё на версию, которую вы хотите оставить, и подготовьте файл. После разрешения всех конфликтов можно использовать git commit для завершения слияния.

Введение в Git: от установки до основных команд 8

Картинка с сайта: tproger.ru

Перемещение

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

Введение в Git: от установки до основных команд 9

Картинка с сайта: tproger.ru

Для перемещения используется команда git rebase <основная ветка> <тематическая ветка>, которая воспроизводит изменения тематической ветки на основной; HEAD тематической ветки указывает на последний воспроизведённый коммит.

Перемещение vs. слияние

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

Сценарий:

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

Перемещайте изменения только на вашей приватной локальной ветке — не перемещайте коммиты, от которых зависит ещё кто-то.

Откат коммитов — revert и reset

Похожие дебаты по поводу того, что лучше использовать, возникают, когда вы хотите откатить коммит. Команда git revert <коммит> создаёт новый коммит, отменяющий изменения, но сохраняющий историю, в то время как git reset <коммит> перемещает указатель HEAD, предоставляя более чистую историю (словно бы этого коммита никогда и не было). Важно отметить, что это также означает, что вы больше не сможете вернуться обратно к этим изменениям, например, если вы всё-таки решите, что отмена коммита была лишней. Чище — не значит лучше!

Продвинутое использование

На этом основное введение в Git заканчивается, и начинается более глубокое изучение.

Интерактивная подготовка

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

  • status — показывает для каждого файла краткое описание того, что (не)подготовлено;
  • update — подготавливает отслеживаемые файлы;
  • revert — убрать один или несколько файлов из подготовленной области;
  • add untracked — подготавливает неотслеживаемый файл;
  • patch — подготавливает только часть файла (полезно, когда вы, например, изменили несколько функций, но хотите разбить изменения на несколько коммитов). После выбора файла вам будут показаны его фрагменты и представлены возможные команды: Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?. Можно ввести ?, чтобы узнать, что делает каждая команда;
  • diff — показывает список подготовленных файлов и позволяет посмотреть изменения для каждого из них;
  • quit — выходит из интерактивной консоли;
  • help — показывает краткое описание каждой команды.

Символ * рядом с файлом означает, что команда изменит его статус (подготовлен/неподготовлен в зависимости от того, происходит ли обновление или откат). Если нажать Enter, не введя ничего ни в одном из под-меню команды, то все файлы перейдут в (не)подготовленное состояние. Создание патчей доступно в интерактивной консоли и через команду git add -p.

Правка истории

Для большего контроля над историей коммитов локальной ветки можно использовать команду git rebase -i HEAD~n, которая откроет интерактивную консоль для перемещения набора последних n коммитов, перечисленных в порядке от старых к новым (то есть в том порядке, в котором они будут перемещены). Таким образом вы можете «редактировать историю», однако помните, что оригинальные коммиты нельзя изменить, только переместить.

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

Изменение сообщения/разбивка коммитов

Для указания коммита, который вы хотите изменить, используется команда edit. Затем, когда Git будет проводить перемещение, он остановится на этом коммите. После этого вы можете использовать git commit --amend, чтобы изменить сообщение или подготовить забытые файлы. Если вы хотите разделить коммит, после остановки введите git reset HEAD^ (в результате HEAD будет перемещён на один коммит назад и все изменённые в этом коммите файлы перейдут в статус неподготовленных). Затем вы сможете зафиксировать файлы в отдельных коммитах обычным образом.

После завершения редактирования введите git rebase --continue.

Перезапись нескольких коммитов

Иногда вам может потребоваться перезаписать несколько коммитов — в таких случаях можно использовать git filter-branch. Например, чтобы удалить случайно зафиксированный файл, можно ввести git filter-branch --tree-filter 'git rm -f <имя файла>' HEAD. Однако учтите, что при этом вся история перемещается.

Объединение нескольких коммитов

Введение в Git: от установки до основных команд 10

Картинка с сайта: tproger.ru

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

Перенос отдельного коммита

Кроме слияния/перемещения всех коммитов в тематической ветке, вас может интересовать только определённый коммит. Допустим, у вас есть локальная ветка drafts, где вы работаете над несколькими потенциальными статьями, но хотите опубликовать только одну из них. Для этого можно использовать команду git cherry-pick. Чтобы получить определённые коммиты, из которых мы хотим выбирать, можно использовать git log <основная ветка>..<тематическая>.

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

Введение в Git: от установки до основных команд 11

Картинка с сайта: tproger.ru

Закрепите введение в Git информацией о типичных ошибках в данной VCS и способах их решения.

Источник

Основы git

Это небольшое руководство и шпаргалка по git, собранное из курса Основы Git

Перед началом

Чтобы освоить git все-таки хорошо знать командную строку. Если такие команды как touch, ls, rm, cd вызывают в вас чувство недоумения и ужас, то стоит попробовать свои силы в командной оболочке, тут может помочь эта статья

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

Пользуйтесь клавишей TAB — она поможет дозаполнить пути, и флаги

Если вы вдруг попали в какой-то текстовый редактор и не знаете как оттуда выбраться, скорее всего это vim :). Нажмите Esc, потом наберите :qa! и нажмите Enter

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

Глеб написал хорошую статью, а ночью словил приступ ненависти к себе и всю ее переписал. Утром эту статью перечитал друг, и сказал, что раньше было лучше. Как откатиться к прошлой версии. Что там было? Может быть у кото-то в месседжере сохранилась часть. Остальное можно дописать. Глеб в ужасе.

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

Например, те же Яндекс.Документы имеют встроенную систему контроля версий.

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

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

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

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

Основые команды

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

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

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

Не стоит заводить вложенные репозитории, это может свести с ума git

Если нужно отменить репозиторий, нужно удалить папку .git

После этого вся информация о коммитах пропадет

git status

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

  • Инициализирован ли репозиторий
  • какая ветвь активна
  • Какие файлы отслеживаются
  • какие будут добавлены в коммит
  • а какие не будут
    — вот на такие вопросы поможет ответить git status
On branch master // ветвь называется master
Your branch is up to date with 'origin/master'. // синхронизирована с удаленным репозиторием

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)
       modified:   README.md // вот этот файл, что вы читаете изменен, но в коммит не добавлен пока

no changes added to commit (use "git add" and/or "git commit -a") // содержание коммита

А если, например, запустить в каталоге, в котором нет репозитория получим вот такое сообщения об ошибке

fatal: not a git repository (or any of the parent directories): .git

Изменения и коммиты

Добавление файла git add

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

Ещё можно вопспользоваться командой git add --all, по сути это аналог git add . — подготовить все файлы в каталоге и подкаталогах к запоминанию

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

git commit

Если git add приглашала всех людей встать в кадр фотоаппарата, то git commit уже большая белая «сделать фотографию».

git commit -m "Сообщение"

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

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

git commint -am "Сообщение"

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

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

git log

Показывает последние правки в репозитории.

На выходе мы получаем список коммитов и сообщений к ним, и ещё важную инфу

commit 23cb3aa087bec2a830e2319ac54eaf41b9a18316 (HEAD -> master)
Author: Frolenko Dima <mail@frolenkodima.ru>
Date:   Wed Aug 23 08:12:57 2023 +0300

    Добавлено описание команд add и commit в ридми

commit 180f1a29bef81d7b3468ee63423e4eb67ba0210a (origin/master, origin/HEAD)
Author: Frolenko Dima <mail@frolenkodima.ru>
Date:   Tue Aug 22 20:34:25 2023 +0300

    Добавить главку о git status

commit bda9f7de743ca0dfe2c85d08e93187b985837c39
Author: frol <mail@frolenkodima.ru>
Date:   Mon Aug 21 16:04:30 2023 +0300

    Добавил забытые комманды. Как много я знаю оказывается!

commit 14865c3c767814a36ea24b4f1de606f2a17743d0
Author: frol <mail@frolenkodima.ru>
Date:   Mon Aug 21 16:02:04 2023 +0300

    Набросал каркас

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

О правилах хорошего тона в репозиториях читайте в главе «Правила хорошего тона»

Рассмотрим подближе вывод одного сообщения

commit 23cb3aa087bec2a830e2319ac54eaf41b9a18316 (HEAD -> master)
Author: Frolenko Dima <mail@frolenkodima.ru>
Date:   Wed Aug 23 08:12:57 2023 +0300

    Добавлено описание команд add и commit в ридми

После слова коммит идёт куча символов 23cb3aa087bec2a830e2319ac54eaf41b9a18316, это хеш коммита, его идентификационный номер. Он уникален и по нему можно точно определить коммит

(HEAD -> master) означает, что это головной коммит, самый свежий. Ключевое слово HEAD можно использовать вместо хеша, чтобы указать на самый свежий коммит. Мастер это имя ветки(про ветки читай раздел git branch)

В поле Author написанны данные автора, а в поле Date дата коммита

Есть так же сокращенная версия вывода

Где мы получим:

7a70c67 (HEAD -> master, origin/master, origin/HEAD) Добавлена комманда git log в описание, и незначительные правки по тексту
23cb3aa Добавлено описание команд add и commit в ридми
180f1a2 Добавить главку о git status
  • 7a70c67 — это сокращенный хеш, им можно пользоваться как обычным длинным хешем
  • HEAD -> master, origin/master, origin/HEAD — ветки с изменениями,
  • и далее сообщение коммита

Статусы файлов

После инициализации репозитория файлы могут находиться в четырех статусах:

+ `untracked` — пока не добавлен в репозиторий, не отслеживается
+ `tracked` — отслеживаются изменения
+ `modified` — был изменен с момента коммита, или добавления в индекс
+ `staged` — добавлен в индекс(подготовлен для коммита)

Кроме первого случая возможны пересечения.

Изначально созданный файл лежит просто так, и git на него не обращает особого внимания. Такой файл untracked. После того, как мы добавили файл командой git add он становится staged(выбран для коммита, пришлашен на фотографию). После коммита, он станет tracked. Изменим его, он становится modified, а если его добавить в коммит, то он становится staged, причем modified с него снимается. Если после того, как мы уже подготовили файл staged, изменим его, то он получит статус modified. Таким образом будет иметь все три статуса, кроме untracked. В таком случае не все изменения войдут в коммит, какие-то останутся для следуюещего раза. Это бывает иногда удобно.

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

modified+git add = staged
untracked + git add = staged
staged + git commit = tracked
modified + git commit = modified // изменения не добавлены в индекс, это нужно дополнительно сделать командой git add
untracked + git commit = untracked

Жизненный цикл файла в репозитории можно было бы изобразить вот так

graph LR;
    untracked -- "git add" --> staged;
    tracked -- "изменения" --> modified;
    staged -- "git commit" --> tracked;
    modified -- "git add" --> staged;
    staged -- "изменения" --> modified;



Loading


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

То, что делаешь у себя папке все это хранится локально, и только на одном компе. Это и не очень надежно, и не очень практично. А нам хотелось бы, чтобы:

  • Код был доступен на каждом компьютере
  • Код был сохранен на каком-то общем сервере
  • Можно было бы поделиться кодом

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

Github

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

SSH

Вася держит свой проект на сервере, и не хочет чтобы кто-то ещё мог его редактировать

Даша и Лена работают над совместным проектом, но не хотят чтобы туда мог вносить правки кто-то ещё

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

В этом нам поможет ssh — протокол безопасной обочки. Он позволит в условиях интернета идентифицироваться на серверах и работать с ними.

Тут нужно раз сформировать ключи шифрования командой ssh-generate

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

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

Разобраться поможет статья на хабре

Добавление удаленного репозитория git add remote

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

git add remote имя_репозитория ссылка_на_репозиторий

В случае этого репозитория выглядит вот так

git add remote origin https://github.com/thefrol/git-basics-doc

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

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

Отправка git push

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

  • origin — имя удаленного репозитория, это имя мы указывали в команде git add remote
  • main — имя отправляемой ветки. Если не получается отправить main можно попробовать master, а вообще имя ветки можно посмотреть командой git status

А потом каждый раз, когда хотите отправить коммиты, просто вводить

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

Посмотреть привязанные репозитории git remote -v

Чтобы узнать какие репозитории уже подключены в этом проекте введите

И вот вывод

origin  https://github.com/thefrol/git-basics-doc.git (fetch)
origin  https://github.com/thefrol/git-basics-doc.git (push)

Правила хорошего тона

README.md

Сообщения коммитов

Хорошее сообщение содержит информацию о том что и где было изменено.

Плохое сообщение «Добавил забытые комманды. Как много я знаю оказывается!»

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

Автор

Гайд был написан Дмитрием Фроленко, августовскими вечерами 2023 г на диване

Источник

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Co er system wilo инструкция
  • Эвлас 2м анализатор влажности инструкция по применению
  • Иноферт форте капсулы инструкция
  • Трамецента спрей инструкция по применению взрослым в нос
  • Алпет р инструкция по применению