Работа с файлом настройки .gitconfig Сейчас вы работаете в одиночку, но в дальнейшем может понадобиться использовать Git в команде. Чтобы участникам проекта было понятно, кто и какие изменения вносил, нужно представиться и указать имя пользователя и адрес электронной почты. Вы можете указать любую электронную почту и любое имя. Сделать это можно с помощью команды git config (от англ. configuration — «конфигурация», «настройка») с ключом --global (англ. «глобальный»). При этом не имеет значения, в какой директории вы находитесь прямо сейчас: вызов git config --globalсработает везде.
В качестве значения user.name нужно указать своё имя или никнейм. Для настройки параметра user.email указывают электронную почту.
Откройте терминал и заполните свои данные: git config --global user.name "Practicum"
git config --global user.email practicum@ya.ru
![[git_config_1707939562.png]]
Теперь проверьте, что получилось. 2. Выполните команду git config с опцией --list.
git config --list
В ответ командная строка покажет ваши настройки:
user.name=Practicum user.email=practicum@ya.ru Создание репозитория Чтобы Git начал отслеживать изменения в проекте, папку с файлами этого проекта нужно сделать Git-репозиторием. Для этого следует переместиться в неё и ввести команду git init (от англ. initialize — «инициализировать»). Хорошим тоном будет поддерживать порядок в файлах: иметь специальную папку для хранения своих проектов. Это поможет избежать беспорядка в файловой системе. Если у вас ещё нет такой папки, сейчас отличный момент, чтобы её создать.
Если у вас нет папки для проектов, создайте её из консоли. mkdir projects cd projects И после этого давайте создадим папку с нашим проектом. Назовём его, например, first-project-git: mkdir first-project-git cd first-project-git Теперь введите заветную команду, и обычная папка превратится в репозиторий: git init Команда выведет сообщение вида: Инициализирован пустой репозиторий Git в <ваша папка с проектом>/.git/.
Внутри папки проекта (first-project-git) появилась новая папка .git, в ней хранится вся служебная информация. А её содержимое можно посмотреть с помощью команды ls .git:
HEAD — текстовый файл с указанием, куда ведёт ссылка HEAD. Можно посмотреть содержимое этого файла, не выходя из консоли с помощью cat .git/HEAD. config — текстовый файл с настройками репозитория. description — текстовый файл с описанием репозитория. hooks — папка с хуками Git. Хуки — это специальные скрипты, которые можно выполнять перед различными действиями с гитом. info — папка с дополнительной информации о репозитории. Например, там есть файл exclude, в котором можно задавать пути до файлов и папок, которые игнорируются гитом. Однако этот механизм неудобен и чаще всего мы используем .gitignore — файлы о которых мы поговорим попозже. objects — папка с объектами Git. Советуем заглядывать туда почаще после внесённых изменений, чтобы лучше понять, что было сделано. refs — папка со ссылками, сокращение от английского references — ссылки. Содержит в себе ветки и прочие ссылки, о которых мы говорили ранее. «Разгитить» папку, если что-то пошло не так, — rm -rf .git Если вы случайно сделали Git-репозиторием не ту папку, её можно «разгитить». Для этого нужно удалить скрытую подпапку .git.
cd <папка с репозиторием> # перешли в папку rm -rf .git # удалили подпапку .git Разберём подробнее, что такое -rf:
ключ -r (от англ. recursive — «рекурсивно») позволяет удалять папки вместе с их содержимым, с этим ключом мы уже знакомы; ключ -f (от англ. force — «заставить») избавит вас от вопросов вроде «Вы точно хотите удалить этот файл? А этот? И этот тоже?». Будьте осторожны: в подпапке .git хранится история изменений. Если удалить .git, то вся история проекта будет стёрта без возможности восстановления — останется только последняя версия файлов.
Состояние репозитория Текущее состояние репозитория можно посмотреть с помощью команды git status:
git status ![[gitstatus_1707939714.png]] Теперь попробуем внести первое изменение. Подготовка файла к сохранению Создадим файл, используя уже известную команду touch:
touch hello.txt Интересно, как поведёт себя Git, обнаружив, что внутри него новый файл. Узнаем это, введя команду git status:
Untracked files: (use "git add ..." to include in what will be committed) hello.txt ![[gitstatus_untracked_1707939752.png]] Пишет Untracked files, в переводе с английского «не отслеживаемые файлы», а сам файл помечает красным цветом. Значит, файлы в папке есть, но пока они не стали частью репозитория, поэтому гит не хранит информацию о версиях и не может отследить, как файл изменялся.
Чтобы Git понял, что этот файл нужен для сохранения в новой версии, вводим git add и затем через пробел название файла:
git add hello.txt Теперь git status будет выглядеть иначе:
Changes to be committed: (use "git rm --cached ..." to unstage) new file: hello.txt Добавленный файл выделен зелёным цветом, это значит, что git готов сохранить изменения. ![[gitstatus_changes_to_be_committed_1707939776.png]]
Вы также можете добавить несколько файлов и подготовить их к сохранению «разом» с помощью git add --all:
touch todo.txt touch readme.txt ... git status # покажет список новых файлов в папке, но не в репозитории git add --all # добавит все файлы к сохранению версии Добавить все изменённые файлы можно без ключа --all через добавление текущей папки. В таком случае все файлы в ней тоже станут частью репозитория. Обратиться к текущей папке в терминале позволяет точка(.):
git add . # добавить всю текущую папку git status Получилось! Теперь Git видит изменения, но ещё не «помнит» их как версию или ревизию. Файлы, которые отмечены зелёным, теперь отслеживаются и готовы к сохранению. Сохранения пока не произошло, потому что команда git add только запоминает текущее содержимое (контент) файла.
Само сохранение, или фиксацию состояния файлов, называют коммитом (от англ. commit — «совершать», «фиксировать»). «Сделать коммит» означает сохранить текущую версию файла или файлов.
Если провести аналогию, команду git add можно сравнить с добавлением товаров в корзину в интернет-магазине, а коммит — с оформлением и оплатой заказа.
Если сейчас отредактировать любой из «зелёных» файлов в папке first-project-git, он перейдёт в состояние modified (англ. «изменённый») и будет и в «зелёном», и в «красном» списках.
Например, откройте файл todo.txt в любом редакторе (подойдёт даже Xcode) и напишите в нём: 1. Пройти пару уроков Практикума.
Сохраните изменения, а затем снова вызовите команду git status в консоли.
Файл todo.txt теперь есть и в «зелёном», и в «красном» списках:
зелёным отмечена пустая версия файла — в таком виде он был во время последнего запуска команды git add; красным отмечена версия с текстом 1. Пройти пару уроков Практикума. Чтобы запомнить новое состояние файла, нужно снова ввести команду git add и передать ей в качестве параметра название файла, или ключ --all или текущую папку ..
git add todo.txt Делаем первый коммит Сделать коммит можно командой git commit с ключом -m(от англ. message – сообщение), который присваивает коммиту название.
Обычно в таком сообщении содержится пояснение, что именно было изменено. Названия нужны, чтобы найти полезную версию и посмотреть состояние репозитория на момент этого коммита.
Сделайте свой первый коммит, откройте консоль и вызовите команду:
git commit -m "Мой первый коммит" После выполнения команды текущая версия файлов будет сохранена в репозитории под версией "Мой первый коммит". А в консоль выведется сообщение о добавленных изменениях.
Если сразу после этой команды вывести git status, то снова увидите, что гиту нечего сохранять, ведь изменений не было.
Использование git commit в Git похоже на фотографирование. Каждый раз, когда вы делаете commit, это как будто вы делаете снимок текущего состояния вашего проекта. Так же, как фотография фиксирует мгновение, commit захватывает все изменения в файлах в моменте. Позже вы можете вернуться к любому «снимку» (коммиту), чтобы вспомнить или восстановить состояние проекта.
Генерация SSH-ключа Откройте Terminal и введите команду: onlyswift.dev@gmail.com
ssh-keygen -t ed25519 -C "<ВАШ EMAIL при регистрации в GitHub>"
например, так: ssh-keygen -t ed25519 -C "emailme@yandex.me"
Команда выведет в терминал сообщение о готовности сгенерировать приватную и публичную части ключа:
Generating public/private ALGORITHM key pair. Дальше команда предложит:
Ввести путь до папки, где нужно сохранить ключ: Enter file in which to save the key (/Users/practicum/.ssh/id_ed25519) Рекомендуем согласиться с предложенным вариантом — просто нажмите Enter. 2. Ввести парольную фразу для файла:
Enter passphrase (empty for no passphrase) Этот пароль будет нужен каждый раз, когда вы попробуете распечатать часть ключа. Программа предлагает создавать ключ и без пароля; чтобы пропустить шаг, нажмите Enter. 3. Повторить парольную фразу ещё раз:
Enter same passphrase again: Если вводили на предыдущем шаге пароль — повторите его, если нет – ещё раз нажмите Enter.
Готово! Пара ключей сгенерирована; вы увидите в терминале похожее сообщение:
Your identification has been saved in /Users/practicum/.ssh/id_ed25519 Your public key has been saved in /Users/practicum/.ssh/id_ed25519.pub The key fingerprint is: SHA256:hYNj4rHyVdLFOfZ5nOKMdq97B0jdHm4kAjEYfNc1WWc emailme@yandex.me The key's randomart image is: +--[ED25519 256]--+ | ..o+o.. .oE| | = =*. . oo| | o = *.+o + o | | . = + o .=.=o.| | . o . S =.++..| | o . o = .o.| | . . . ... | | o .| | o+ . | +----[SHA256]-----+ Дальше выполните команду, которая добавит ключ SSH-агенту (программа, которая запоминает ваш приватный SSH-ключ и автоматически подставляет его при подключении к серверу через SSH) и сохранит его в связке ключей (Keychain):
ssh-add --apple-use-keychain ~/.ssh/id_ed25519 Теперь скопируйте публичный ключ id_ed25519.pub в буфер обмена:
pbcopy < ~/.ssh/id_ed25519.pub Отлично. Разберёмся, что с этим делать — давайте переходить дальше.
Добавляем SSH-ключ в GitHub аккаунт Зайдите на GitHub и перейдите в Settings (Настройки). ![[05_01_ssh_settings_1707940518.png]]
В левом меню выберите SSH and GPG keys. ![[05_01_ssh_button_1707940549.png]]
Нажмите New SSH key или Add SSH key. ![[05_01_ssh_add_1707940577.png]]
В поле Title введите название ключа (например, название вашего компьютера). ![[05_01_ssh_setup_1707940613.png]]
В поле Key вставьте ключ из буфера обмена горячими клавишами Cmd + V.
Нажмите Add SSH key. ![[SSHKey.mp4]]
Отлично! SSH-ключ настроен.
удалённый репозиторий Откройте терминал, найдите созданный гит-репозиторий first-project-git или создайте новый:
cd ~/projects/first-project-git
git status Теперь откройте главную страницу github.com. Нажмите + рядом с иконкой профиля и выберите New repository: ![[05_01_github_new_repository_1707941052.png]]
Перед вами появится форма с предварительными настройками проекта. Давайте разберёмся, из чего она состоит: ![[05_01_github_fill_fields_1707941096.png]]
Смените протокол подключения с HTTP на SSH: ![[05_01_github_empty_repo_1707941181.png]] Откройте терминал с выбранным до этого проектом и выполните инструкцию из GitHub:
git remote add origin git@github.com:<ВАШ НИКНЕЙМ>/first-project-git.git Команду можно читать как «Git, добавь ссылку на удалённый репозиторий». Команда связывает локальный репозиторий с удалённым — или, проще говоря, сохраняет ссылку на страницу удалённого репозитория. Рассмотрим её подробнее:
git remote add— команда для добавления нового удалённого репозитория. origin — короткое имя, которое мы присваиваем удалённому репозиторию. Origin — стандартное название для основного удалённого репозитория, но вы можете использовать любое другое. git@github.com:<ВАШ НИКНЕЙМ>/first-project-git.git — адрес удалённого репозитория на GitHub для SSH-подключения. Здесь <ВАШ НИКНЕЙМ> лучше заменить на реальный никнейм на GitHub, first-project-git — на название вашего репозитория на GitHub. Эта команда выполняется один раз при настройке репозитория. Дальше git уже «запомнит», где находится удалённая версия, и вы сможете отправлять и получать изменения между локальным репозиторием и удалённым.
Следующую команду git branch -M main можно читать как «Git, возьми ветку и переименуй её в main». Ключ -M отвечает за переименование, а main — это название самой ветки. Это действие обычно делается один раз, чтобы установить стандартное название для вашей основной ветки в проекте. Мы упоминали, что каждый коммит сохраняет актуальное состояние файлов. Сами же коммиты хранятся в ветках (на английском — branches). Если коммит — это снимок состояния файлов, то ветка — временна́я шкала, на которой расположены эти снимки. Как с ними работать, рассмотрим в следующем уроке.
Разбираемся в команде push Выполним и разберём команду:
git push -u origin main git push — указывает Git отправить (или «запушить») изменения из вашего локального репозитория в удалённый. Как мы говорили до этого, push с английского — «толкать». -u – этот ключ означает set upstream: мы устанавливаем связь между локальной веткой и удалённой. В следующий раз, когда вы будете отправлять или получать изменения, Git будет «знать», откуда брать или куда отправлять данные. origin — название стандартного удалённого репозитория. Когда мы сохраняли ссылку на репозиторий командой git remote add, то использовали это короткое название для ссылки на репозиторий. Так Git «поймёт», что ветку нужно искать именно в репозитории с названием origin main — название ветки, которую вы хотите отправить в удалённый репозиторий. Пока что у нас одна ветка, но может быть больше — это тема отдельного урока. Итак, всю команду git push -u origin main можно читать как «Git, отправь мои изменения из локальной ветки main в главную ветку удалённого репозитория (origin) и установи её как основную для будущих использований команды push».
После выполнения этих команд давайте убедимся, что Git выгрузил содержимое локального репозитория в GitHub-репозиторий: ![[05_01_github_push_1707941256.png]]
Что такое ветка Ветка в Git — отдельный поток разработки. В таком потоке можно безопасно пробовать новые идеи и вносить изменения не влияя на основной код проекта.
git branch — просматриваем ветки проекта Откройте терминал и перейдите в наш проект для тренировки — first-project-git. Выполните новую команду:
git branch
- main # мы в основной ветке
При вызове git branch выводятся ветки, которые есть в проекте. Звёздочкой (*) отмечено, в какой ветке вы находитесь сейчас.
Ваш проект выглядит так: ![[6-branch-main_1707942270.png]]
Когда вы добавляете новый коммит в ветку, её состояние меняется — и ваше «положение» на ней тоже.
Измените файл README.md и сделайте ещё один коммит:
echo "Изучаю работу веток" >> README.md git add . && git commit -m "Обновить README" ![[6-branch-main-with-new-commit_1707942299.png]] Коммиты объединяются в последовательность — а это уже целая ветка!
git branch <название_ветки>: создаём ветку Перейдите в терминал и попробуйте создать новую ветку:
git branch new_branch git branch # посмотрите список веток
new_branch # появилась новая
- main # * значит, мы находимся в основной ветке Отлично! Теперь в вашем репозитории две ветки: основная и new_branch.
![[6-branch-branch_1707942340.png]]
git checkout <название_ветки>: переключаемся между ветками Вы создали ветку для экспериментов с рабочим проектом. Чтобы поработать в ней, сначала нужно на неё переключиться.
Например, сейчас вы создали ветку new_branch, но пока находитесь в main. Пора это исправить и научиться перемещаться между ветками!
git checkout new_branch # перешли в новую ветку Switched to branch 'new_branch'
git branch # проверили
- new_branch # теперь находимся тут main Откройте терминал README.md и добавьте заметку из двух строк: - чтобы создать ветку, нужно вызвать команду git branch <название_ветки>
- чтобы переключиться на ветку, нужна команда git checkout <название_ветки>
Затем сделайте коммит: git add . && git commit -m "Добавить git branch и git checkout в README"
Теперь ваш репозиторий выглядит так: ![[6-branch-checkout_1707942423.png]]
Вернитесь в главную ветку командой git checkout main и откройте файл README.md. В нём отобразится только первоначальный текст. Все изменения сохранились в ветку new_branch, а состояние главной ветки не изменилось.
Можно создать ветку и сразу начать в ней работать. За это отвечает команда git checkout с флагом -b (от англ. branch) и названием ветки. Эта команда делает то же самое, что и последовательность команд git branch <название_ветки> && git checkout <название_ветки>.
Убедитесь, что вы в основной ветке. Затем создайте ещё одну ветку another_branch и сразу переключитесь на неё.
git checkout main git checkout -b another_branch # создали ветку и сразу на неё переключились Switched to a new branch 'another_branch'
git branch
- another_branch # сразу в нужной ветке new_branch main Вот как теперь выглядит проект: ![[6-branch-checkout-new_1707942459.png]]
Сливаем ветки Представьте, что закончили разработку новой функциональности в отдельной ветке и готовы объединить её с главной — добавить свои изменения в основную версию проекта. Этот процесс называется слиянием веток или мёрджем (англ. merge — «сливать», «поглощать»). Перед тем как начать слияние, нужно перейти в ветку, куда должны добавиться изменения. Обычно это главная ветка. Перейдите в неё и вызовите команду git merge с именем присоединяемой ветки new_branch в качестве параметра.
git checkout main # переключились на главную ветку
git merge new_branch # объединили ветки Updating 079cfbf..f30d441 Fast-forward README.md | 2 ++ 1 file changed, 2 insertions(+) Ветки объединены! Все коммиты из new_branch добавлены в главную ветку, Git перечислил изменённые файлы и количество изменённых строк в них.
После слияния веток main и new_branch репозиторий перейдёт в такое состояние: ![[6-branch-merge_1707942502.png]]
Возвращаемся в GitHub Допустим, вы закончили работу над задачей в локальной ветке. Теперь вы хотите, чтобы сначала изменения увидели ваши коллеги, а после — слить изменения с основной веткой. Для этого вам нужно переместиться в GitHub. Обычно в основной ветке GitHub хранится актуальная версия проекта. Как правило, изменения сначала загружают в новую ветку и только потом вливают её в основную. Так коллеги смогут оценивать ваши правки до того, как те попадут в главную ветку. Вы уже знаете команду git push: мы говорили, что она загружает изменения в удалённый репозиторий. Теперь скажем точнее: команда отправляет локальную ветку в удалённый репозиторий. Откройте терминал и отправьте последние изменения из основной ветки в удалённый репозиторий:
git push -u origin main
Отлично! Теперь у нас есть актуальная версия проекта.
Убедитесь, что вы в основной ветке. Если нет — перейдите в неё через git checkout main, а затем создайте новую ветку merge-request и перейдите в неё (git checkout -b merge-request). Откройте файл README.md и добавьте туда строку о команде git merge:
С помощью команды git merge можно слить две ветки в одну.
Закомитьте изменения git add . && git commit -m "Добавить merge в README".
Чтобы отправить merge-request в удалённый репозиторий, ещё раз выполните команду push. Теперь необязательно переходить в ветку, чтобы запушить её: git push -u origin merge-request
Откройте GitHub и обновите страницу. После добавления новой ветки произойдёт два события:
Вместо 1 branch (англ. «одна ветка») станет 2 branches (англ. «две ветки»). По клику на список веток теперь можно перейти в ветку feature/merge-request. ![[6-merge-request-branch_1707942568.png]]