Git основы

Git основы

В статье мы ознакомимся с основными функциями git, расскажем в чём заключается отличие с GitHub и для чего изучать Git новичку.

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

Для чего Git и почему он необходим?

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

Если сказать проще, то это кодовая основа и деяния кода, которые позволяют “объединять” или “соединять” код.

Для чего вам нужно изучить гит:

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

Давайте разберемся на примерах:

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

Основы git

Для работы с Git откройте командую строку Win + R вводим cmd, затем ОК.

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

А так же для упрощения разработки можно скачать приложением GitHub Desktop.

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

git <команда> <аргументы>.

Для вывода руководства по командам Git

git help <команда>.

Git — это не GitHub

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

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

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

1. Подключаем git,
2. создаем профиль на GitHub,
3. создаём репозиторий,
4. грузим работу на GitHub

Управлять репозиторием можно через командную строку cmd.

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

Установка git

Начальное погружение в Git. 

1. Установите Git: ссылка для Windows, macOS или Linux.
2. После установки в командой строке проверьте версию с помощью консольной команды:

git --version.

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

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

• git config --global user.name “Tester”
• git config --global user.email “tester@mail.ru”

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

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

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

Создавать репозиторий будем на ПК

• В папке, где хоте создать проект на вашем ПК зажмите Shift + ПКМ, чтобы в меню появился пункт «Открыть окно команд» или «Открыть окно PowerShell».
• Проверим установлен ли у нас git, для этого вводим команду (Пропишите команду руками, чтобы запомнить в голове)
• git --version
• Для инициализации нового репозитория .git выполните команду 
• git init. 
• Чтобы скопировать уже существующий проект себе локально, существует команда git clone .
• После этого вы должны были получить сообщение вроде такого: Initialized empty Git repository in /path/somedirectory/.git/
• Это значит, что репозиторий был успешно создан, но пока что пуст. Теперь можно создать файл readme.md и поместить внутрь любой текст “Привет, это мой первый репозиторий”. Добавление файлов в репозиторий будет описано ниже

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

Отследить текущий статус вашего репозитория можно командой
git status

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

git status On branch master Initial commit Untracked files (use "git add ..." to include in what will be committed) readme.md

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

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

В Git есть такое понятие как - система подготовленных файлов. Это требуется для объявления файлов, которые мы желаем прослеживать и прибавить в коммит. Сейчас мы с вами добавим файл readme.md и коммитнем (зафиксируем).

Мы имеем один файл, поэтому мы можем написать такую команду:
git add readme.md

Ежели нам необходимо добавить все, что находится в каталоге, мы можем применить:
git add -A 

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

Коммиты

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

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

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

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

Давайте коммитнем наш файл. Для этого напишем команду git commit “тестовый комит”.

Советы по введению в Git

• Все правки коммитьте, но не каждую строку, а глобальные изменения (Пример - добавлена анимация для текста).
• Одно изменение — один коммит. Не добавляйте всё в кучу header и footer и т.д. Это отдельные блоки и загружать их следует раздельно.
• Стиль сообщений: сообщение должно быть меньше 50 символов в длину и обязано показать всю суть коммита - Fixed bugs (исправлены баги). 
• Когда у вас весьма немало незначимых поправок, то отличным вариантом будет делать небольшие коммиты при разработке, но при добавлении в главный репозиторий объединять их в один коммит.

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

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

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

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

git reset --hard HEAD~2

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

Git следит за файлами сходу в 3-х главных сегментах:

• Рабочая директория (локальные файлы ПК)
• Область приготовленных файлов (оглавление последующего коммита)
• Head (крайний коммит в репозитории)

Основные команды по работе с файлами состоят из работы Git перечисленных выше разделов.

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

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

Не отслеживаемый (untracked) — располагается в рабочей области, однако недостает его в остальных версиях и Git не понимает эти файлы.

• Изменён (modified) — в рабочей директории возникла новая версия, которая различает с текущей хранящейся в HEAD(изменения не находятся в последующем коммите).
• Подготовлен (staged) — в рабочей директории и области приготовленных файлов имеется наиболее новая версия по сравнению с хранящейся в HEAD (готов к коммиту).
• Без изменений — одна версия файла во всех сегментах, т. е. в крайнем коммите содержится текущая версия.
• Для просмотра конфигураций, а не модифицированных файлов, следует применять последующие команды:
• git diff — сопоставление рабочего каталога с областью приготовленных файлов;
• git diff --staged — сопоставление области приготовленных файлов с HEAD.

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

Обновление файлов

git add - обновляет пространство приготовленных файлов версиями из каталога.
git commit изменяет HEAD новым коммитом, который готовит снимки файлов в области приготовленных файлов.
git reset . Состоит из 3 режимов. Работа состоит в том, чтобы совершить сброс ветки, индекса и/либо рабочего дерева, чтоб сориентироваться/сравнить данный коммит.
git reset --soft

Возьмем к примеру ветку: 

- A - B - C (master)
HEAD указывает на C и индекс совпадает с C.

После выполнения
git reset --soft B

HEAD станет ориентироваться на B и изменения из коммита C станут в индексе, как будто вы их добавили командой git add. Если вы в данный момент исполните git commit вы получите коммит схожий с C.
git reset --mixed = git reset

Возвратимся к тем же исходным условиям:
- A - B - C (master)

git reflog master - вернуть крайние изменения.

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

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

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

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

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

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

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

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

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

До этого времени все образцы и команды производились на локальном сервере. Однако мы ведь хотим хранить код на доступных хранилищах, которые разрешено просмотреть, обновить и клонировать.

git remote -v — выводит перечень удалённых отслеживаемых репозиториев и названия, которые мы присвоили.
git clone делает копию репозитория и затевает его отслеживание.

Часто встречаемые команды в работе:

• git remote add — прибавляет удалённый репозиторий с данным именованием;
• git remote remove — устраняет удалённый репозиторий с заданным именем;
• git remote rename — переименовывает удалённый репозиторий;
• git remote set-url — присваивает репозиторию с именем новый адрес;
• git remote show — показывает информацию о репозитории.
  
  Команды, которые работают с удалёнными ветками:
• git fetch — приобретает данные из ветки выбранного репозитория, но не стягивает изменения;
• git pull — стягивает данные из ветки выбранного репозитория;
• git push — отправляет изменения в ветку заданного репозитория. Если локальная ветка уже отслеживает удалённую, то разрешено применять элементарно git push либо git pull.

GitHub

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

Необязательно использовать GitHub имеется и очень много остальных платформ. Git и GitHub здорово заточены под совместную работу. В использовании GitHub множество плюсов, из-за больших проектов очень плохо было отслеживать свой код, а тем более его слить в одно целое (да еще и без конфликтов). Отслеживание вашей активности, просмотр исходного кода работ, как своих так и других людей, этот список можно перечислять бесконечно. В GitHub есть такой замечательный термин как “смержиться”, то есть из двух веток объединить всё в одну, это огромный плюс, но об этом чуть позже. Если вы не зарегистрированы на GitHub, то пройдите регистрацию по ссылке.

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

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

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

Предположим вы работаете в команде 5 человек, у вас есть начальная точка - весь проект. Первому, нужно сделать какую-то задачу, Второму - другую задачу и третьему также. При этом не навредив главному проекту, для этого создаются “ветки”. Первый человек, создал ветку Dev1 и написал свой код, таким же образом сделали и остальные. Итог - в проекте есть новые изменения при этом, вы всегда можете вернуться к начальному этапу проекта.

Команды:

• 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.

1. Создание новой ветки
   Основная ветка в каждом репозитории называется master. Для создания еще одной новой ветки, пропишем команду branch 
   Это создаст новую ветку, пока что точную копию ветки master.
2. Переключение между ветками
   Сейчас, если мы запустим branch, мы увидим две доступные опции
   master — это активная ветка, она помечена звездочкой. Нам нужно создать проект, а для этого нам понадобится переключиться на другую ветку. Воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.
3. Слияние веток
   Команда git merge используется для слияния одной или нескольких веток в текущую. Затем она устанавливает указатель текущей ветки на результирующий коммит. Почти все использования имеют вид git merge с указанием единственной ветки для слияния.

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

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

Такие ошибки допускают новички

1. Добавляют на Git node_modules & libs
2. Делают неверные коммиты, один компонент - один коммит
3. Написание кода не в своей ветке, откуда возникают ошибки при git merge
4. Много лишних коммитов
5. Неверно построен файл .gitignore
    

Команды которые должен знать каждый

Инициализация вашего проекта - git init
Отображает все файлы, которые различаются между собой - git status
Инициализация вашего проекта - git -m commit
Удаляет отслеживаемые файлы - git rm
Добавить все файл в отображение - git add .
Восстановление удалённого файла - git checkout myfile.txt
Восстановление удалённой ветки - git checkout myfile.txt
Откат к конкретному коммиту в истории - git reset --hard HEAD~1
Создание новой ветки с изменениями текущей - git checkout -b название-моей-новой-ветки
добавляет удалённый репозиторий с заданным именем - git remote add  <имя> <url>
Cливает данные из ветки заданного репозитория - git pull <имя> <ветка> 
Отправляет изменения в ветку заданного репозитория. - git push  <имя> <ветка>
Создаёт новую локальную ветку и начинает отслеживать удалённую -- git checkout -b <ветка> <имя удалённого репозитория>/<удалённая ветка>

Заключение

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

Вот видите гит уже совсем не страшен, погружайтесь в гит еще больше, а меньше используйте ctrl c + ctrl v, будьте внимательными и всё у вас получится!