Шпаргалка основы git в vscode

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

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

Помню как в самом начале я не понимал с чего начинать, мне было сложно понять, как правильно настроить работу с Git и GitHub. Вот у меня некий сайт или скрипт в vs code студии - как теперь правильно работать. как залить в github. что делать? даже гугление особо не помогало. а вкладка Source Control в VS Code выглядела запутанной. Поэтому я опишу стартовые шаги для разных случаев.

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

А, ну да, git как vs code studio вначале скачивается, устанавливается, в github регистрируемся, создаем репозиторий (открытый или закрытый (приватный), задаем лицензию и т.д.), получаем ключи, чтобы связать vs code. 

1. Скачайте и установите Git.

2. Установите VS Code.

3. Зарегистрируйтесь на GitHub. (к слову альтернатив много, но все поддерживают стандартные команды)

4. Создайте новый репозиторий на GitHub (публичный или приватный, задайте лицензию и прочие настройки).

5. Настройте SSH-ключи или вход через HTTPS, чтобы связать VS Code с GitHub.

Итак, самое начало может быть несколько видов: 1. нам нужно продолжить работу над своим проектом на новом месте (например ноуте) или после переустановки всего или же нам понравился чужой бесплатный и свободно распространяемый, зачастую забытый проект и мы хотим его к себе склонировать, переписать, переделать, отправить уже к себе и хранить у себя (речь не просто плагиат, а есть компоненты, которые в виде "болванки", которые вы качаете, что-то делаете и билдите, получая уже свой код). форк. 2. мы уже работаем или у нас просто пустая папка и мы хотим теперь контролировать версии.

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

1. Клонируем удаленный репозиторий. Если вы хотите взять чужой проект или подтянуть свой на удаленном хранилище (это не обязательно github), например, чтобы изучить или доработать, выполните следующее:

git clone URL_репозитория

Когда обычно клонируют.
1. Например есть скрипты или компоненты, которые требуется предварительно настроить, потом сделать build, чтобы все прописалось в ключи. А потом уже можно работать как со своим компонентом. Грубо говоря некая заготовка. Имейте ввиду, что при клонировании нужно соблюдать лицензию и не нарушать авторские права. 
2. вы работаете за пк, но потом у вас повилось еще одно рабочее место (например ноутбук) и вам нужно продолжить работу там.

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

- Чужой репозиторий останется "привязанным" как origin.
- Чтобы работать с собственным репозиторием, нужно заменить `origin`.

git remote remove origin # Удаляем старый origin 

git remote add origin URL_своего_репозитория # Добавляем свой

Проверяем

git remote -v

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

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

Форк — это копия чужого репозитория в вашем аккаунте GitHub. Это полезно, если вы хотите:

• Вносить изменения в свою копию.
• Развивать проект, не влияя на оригинал.
• Создавать pull request, чтобы предложить свои изменения владельцу оригинального репозитория.

Сделать форк можно так:

На GitHub зайди на страницу чужого репозитория.
Нажми кнопку Fork

Теперь проект появится в вашем аккаунте.

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

git remote add upstream URL_оригинального_репозитория

git fetch upstream

git merge upstream/main

Лично я с форком еще не работал.

Вы можете предложить изменения владельцу оригинального репозитория: Создать pull request через интерфейс GitHub.

Теперь быстро рассмотрим пример, когда Создан пустой репозиторий в GitHub и нужно залить проект из VS Code и здесь уже основы уже работы

Создайте локальную папку или откройте уже существующую в VS Code.

Инициализируйте Git-репозиторий.

git init

Добавьте файлы или папки в отслеживание.

git add .

Это добавит все файлы (точка), или можно добавить только конкретный файл или папку

git add путь/к/файлу

Создаем первый коммит. Другими словами сохраняем измененные файлы с комментарием. Коммиты помогают вернуться к любому состоянию проекта в прошлом. Грубо говоря это снимок текущего состояния проекта. В VS Code это можно сделать во вкладке Source Control: напишите комментарий и нажмите кнопку "Commit".

git commit -m "Первое изменение"

Коммиты должны быть краткие и осмысленные. Например "Добавил подзагрузку классов в bootstrap"

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

git remote add origin URL_вашего_репозитория

Установите основную ветку main (или другую, если это необходимо):

git branch -M main

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

git push -u origin main

А теперь про ветки

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

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

Для разработки использую ветку под названием dev. Но и в ней создаю ветки под разные задачи. То есть в dev делается костяк всего компонента и в ней я хочу разработать еще отдельно панель администратора, то я создаю ветку admin-panel и в ней уже работаю с одной частью. потом сливаю с dev. потом когда все - сливаю в main. Сливать или сливание -  объединение веток. Я не знаю на сколько это правильный подход, так как опыта работы в команде программистов у меня нет. Но в теории командами работают так. Когда сливается код, может возникнуть конфликт, особенно если разные люди изменяли одни и те же файлы. Это бывает редко, но бывает. про это чуть позже.

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

git checkout -b dev

Отправьте ветку на GitHub:

git push -u origin dev

Ветка dev будет использована для разработки, чтобы не трогать main

Все это можно делать из панели Sorce Control не трогая командную строку.

Работаем над задачей в новой ветке

Если нужно сделать конкретную задачу, создаём ещё одну ветку: Команды:

git checkout -b имя_ветки

git push -u origin имя_ветки # Отправляем

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

После завершения задачи объедините ветку с dev:

git checkout dev # Переключаемся на dev

git merge имя_ветки # Сливаем изменения из admin-panel в dev

git push # Отправляем dev в GitHub

После этого все изменения задачи окажутся в ветке dev.

Слияние dev с main через GitHub:

• Создайте pull request.
• Выбираем откуда куда
• Проверьте изменения.
• Выполните слияние.

Обязательно Синхронизируем локальный main с удалённым

git checkout main

git pull origin main

Локальная ветка main будет синхронизирована с GitHub

Решение конфликтов при слиянии

Если при слиянии возникают конфликты, Git покажет конфликтные файлы. В VS Code они отмечаются маркерами:

Посмотреть конфликтные файлы:

git status

Открыть файлы в редакторе (VS Code):  Конфликт будет отмечен:

<<<<<<< HEAD 
# изменения 
======= 
# Изменения из другой ветки 
>>>>>>> 

Уберите маркеры и сохраните нужный код. После этого:

git add <файл>
git commit
git push

Еще команды в самом VS Code

- Создать ветку:  Source Control → кнопка "Create branch".
- Слить ветку:  Source Control → кнопка "Merge branch".
- Подтянуть изменения:  Source Control → кнопка "Pull".
- Отправить изменения:  Source Control → кнопка "Push".

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

Удобство работы в VS Code и JetBrains IDE

Работа с Git в VS Code интуитивно понятна. Здесь можно:

• Создавать ветки.

• Коммитить и пушить изменения.

• Разрешать конфликты слияния.

Всё это доступно через вкладку Source Control, где графический интерфейс заменяет сложные команды.

JetBrains IDE (например, PhpStorm) добавляют ещё больше удобства, интегрируя Git в интерфейс разработки. Там можно визуально отслеживать изменения в коде, просматривать историю коммитов и работать с ветками буквально в пару кликов. JetBrains, например, мне очень нравится, но он платный. VS code же используется много где за счет универсальности и доступности.

Ну и Github не единственная платформа для хранения репозиториев, есть еще  GitLab (пожалуй самая популярная в корпоративном сегменте), Bitbucket, GitVerse.

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

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

git pull - объединяет две операции: git fetch + git merge. Она загружает изменения из удаленного репозитория и сразу сливает их с локальной веткой.

git rebase -  Переписывает историю изменений, чтобы сделать её более линейной. Часто используется для обновления своей ветки на основе изменений в main, сохраняя историю коммитов компактной. 

git stash -  Сохраняет временные изменения в "хранилище", если нужно переключиться на другую ветку, не теряя прогресса. 

git cherry-pick -  Позволяет выбрать определённый коммит из другой ветки и применить его в текущей. 

git blame -  кто и когда вносил изменения в каждую строку файла. Очень полезно при отладке. 

git revert -  Отменяет изменения определенного коммита, создавая новый коммит с отменёнными правками 

git reset - Опасное.  Возвращает состояние репозитория к указанному коммиту. Может затронуть или не затронуть файлы (в зависимости от флага). 

git tag -  Добавляет тег к коммиту, чтобы отметить релизы или важные этапы. 

git log -  Просмотр истории коммитов. Часто используется с различными фильтрами. 

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

Делаем показать сокращенный лог

git log --oneline

находим там код-хеш нужного коммита и далее или переключаемся к этому коммиту

git checkout этотхеш

или 

git switch --detach  этотхеш

это чтобы посмотреть, что там было и если все устраивает и именно это и нужно, то

git revert этотхеш

Это создаст новый коммит, отменяющий указанный.

есть еще вариант мягкого отката действий 

git reset --soft этотхеш 

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

git reset --hard этотхеш

И можно создать новую ветку от этого коммита 

git checkout -b названиеветки этотхеш

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

git log поддерживает много фильтров, можно даже по определенному автору отсортировать. 

Какие еще есть термины:

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

CI/CD -  Процесс автоматического тестирования и деплоя (Continuous Integration / Continuous Deployment). 

Merge Request (MR) / Pull Request (PR) -  Запрос на слияние кода одной ветки с другой. Используется для проверки и обсуждения кода до его добавления в основную ветку. 

Diff - Разница между двумя версиями кода. Позволяет увидеть, какие строки были изменены.

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

Pipeline -  Набор автоматических задач, запускаемых в CI/CD для сборки, тестирования и деплоя приложения. 

Git Flow - подход разделения на ветки feature, develop, release, hotfix

Trunk-Based Development -  разработка  с короткими ветками для изменений 

Upstream -   Оригинальный репозиторий, от которого сделан форк. 

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

Знание Git и GitHub — это важнейший навык для работы в команде разработчиков. Хотя я стараюсь изучать и углублять понимание этой темы, пока что мои знания далеки от экспертного уровня. Я всё ещё сам учусь, пробую различные команды и рабочие процессы, поэтому не могу гарантировать, что здесь все верно и правильно, часть сам подсмотрел и спрашивал. Поэтому врядли бы вам помог еще какими либо советами и ответами.  работа с Git требует практики, поэтому не бойтесь экспериментировать и пробовать новые подходы! 

Вот есть неплохие книги: 

1. Ганди Раджу. Head First. Git. Купить можно здесь - https://shp.pub/73x45c?erid=2SDnjetoTDd (Реклама. ООО "Новый книжный центр" ИНН 7710422909)

2. С. Чакон, Б. Штрауб. Git для профессионального программиста (12+). Купить можно здесь - https://shp.pub/73x46b?erid=2SDnjbxKDHu (Реклама. ООО "Новый книжный центр" ИНН 7710422909)

Ну и много других ресурсов, статей, видео, книг и материалов.

 И еще можно купить такой клевый коврик для мыши с командами Git на Алиэкспресс - https://alii.pub/7644xa?erid=2SDnjccqCqA (Реклама. ООО "АЛИБАБА.КОМ (РУ)" ИНН 7703380158)