Пример работы с репозиторием
Подготовка
Итак, для примера у меня есть папка test в которой лежат пара скриптов для бекапа файлов — я хочу запихнуть их в этот репозиторий, инициировав его. Итак, что на входе:
kirill@xxx:test$ tree -a
.
├── .directory
├── file_backup.sh
└── git_backup.sh
0 directories, 3 files
|
1 |
kirill@xxxtest$tree-a . ├──file_backup.sh └──git_backup.sh directories,3files |
kirill@xxx:test$ vim .gitignore
kirill@xxx:test$ cat .gitignore
.*
|
1 |
kirill@xxxtest$vim.gitignore kirill@xxxtest$cat.gitignore .* |
Инициализация и первый коммит
Теперь воспользуемся инструкцией из второго примера на нашей страничке пустого проекта «Existing folder»:
kirill@xxx:test$ git init
Инициализирован пустой репозиторий Git в /home/kirill/Yandex.Disk/8.dev/test/.git/
kirill@xxx:test$ git remote add origin git@гит-сервер:OPS/backups/file-backup-scripts.git
kirill@xxx:test$ git status
На ветке master
Еще нет коммитов
Неотслеживаемые файлы:
(используйте «git add <файл>…», чтобы добавить в то, что будет включено в коммит)
file_backup.sh
git_backup.sh
ничего не добавлено в коммит, но есть неотслеживаемые файлы (используйте «git add», чтобы отслеживать их)
kirill@xxx:test$ git add -A
kirill@xxx:test$ git commit -m «Initial commit»
Initial commit
2 files changed, 231 insertions(+)
create mode 100644 file_backup.sh
create mode 100644 git_backup.sh
kirill@xxx:test$ git status
На ветке master
нечего коммитить, нет изменений в рабочем каталоге
kirill@xxx:test$ git push -u origin master
Подсчет объектов: 4, готово.
Delta compression using up to 4 threads.
Сжатие объектов: 100% (4/4), готово.
Запись объектов: 100% (4/4), 1.95 KiB | 1.95 MiB/s, готово.
Total 4 (delta 1), reused 0 (delta 0)
To гит-сервер:OPS/backups/file-backup-scripts.git
* master -> master
Ветка «master» отслеживает внешнюю ветку «master» из «origin».
|
1 |
kirill@xxxtest$git init ИнициализированпустойрепозиторийGitвhomekirillYandex.Disk8.devtest.git kirill@xxxtest$git remote add origin git@гит-серверOPSbackupsfile-backup-scripts.git kirill@xxxtest$git status Наветкеmaster (используйте«git add<файл>…»,чтобыдобавитьвто,чтобудетвключеновкоммит) file_backup.sh git_backup.sh kirill@xxxtest$git add-A kirill@xxxtest$git commit-m»Initial commit» master(корневойкоммит)e58bc6dInitial commit 2files changed,231insertions(+) create mode100644file_backup.sh create mode100644git_backup.sh kirill@xxxtest$git config user.name»kirill.kazarin» kirill@xxxtest$git config user.email»[email protected]» kirill@xxxtest$git status Наветкеmaster нечегокоммитить,нетизмененийврабочемкаталоге kirill@xxxtest$git push-uorigin master Подсчетобъектов4,готово. Delta compression using up to4threads. Сжатиеобъектов100%(44),готово. Записьобъектов100%(44),1.95KiB|1.95MiBs,готово. Total4(delta1),reused(delta) Toгит-серверOPSbackupsfile-backup-scripts.git *newbranchmaster->master Ветка«master»отслеживаетвнешнююветку«master»из«origin». |
Теперь разберем по пунктам что я сделал:
Я проинициализировал или создал пустой ЛОКАЛЬНЫЙ репозиторий
Я связал его с удаленным репозиторием на сервере
Я узнал статус репозитория и увидел что у меня есть 2 не отслеживаемых файла (заметьте что той ненужной папки в списке нет)
Сказал добавить все файлы в обслуживаемые (флаг -А вообще опасная штука. Используйте его только если в выводе команды статус вы видите только те файлы, которые должны попасть в репозиторий и НИКАКИЕ другие. А то так и ключи, и пароли, и много что еще загружали люди в публичные репы)
Делаю коммит или фиксацию состояния, сразу добавляя сообщение через флаг -m. Иначе откроется редактор в котором вам нужно будет написать пояснительное сообщение к коммиту. На счет стиля сообщений и как их писать будет ниже.
Далее я настроил имя и имейл пользователя, от лица которого эти изменения будут улетать на сервер. Это можно было бы сделать и сразу, после инициализации репозитория
Обратите внимание — я не использовал флаг –global, а значит эти настройки применены только для данного репозитория. Почему я так сделал? Я работаю с большим числом разных гит серверов и на всех у меня разные учетные записи
Я не хочу перенастраивать клиент глобально каждый раз.
Я еще раз запросил статус чтобы убедиться что я зафиксировал все что хотел и что я могу отправлять изменения на сервер
Я отправил изменения на удаленный сервер, протолкнув (push) их.
GitHub поток
Допустим, у вас есть проект, и у вас может быть много разных идей и возможностей в любой момент времени. Некоторые функции могут быть готовы к работе, а некоторые нет. Может быть, вы работаете с другими людьми, которые все делают свое дело. Вот где начинается ветвление!
Филиал — это отдельное пространство, где вы можете опробовать новые идеи. Если вы что-то измените в ветке, это не повлияет на основную ветку, пока вы этого не захотите. Это означает, что вы можете делать с этой веткой все, что захотите, пока не решите, что пришло время объединить ее.
Единственная ветвь, которая собирается навсегда изменить вещи, является основной ветвью. Если вы не хотите, чтобы ваши изменения были развернуты немедленно, внесите их в отдельную ветку и объедините их с основной веткой, когда будете готовы.
Если вы работаете с другими и хотите вносить изменения самостоятельно, или если вы работаете самостоятельно и хотите вносить изменения, не затрагивая основную ветку, вам нужна отдельная ветка. Вы можете создать новую ветку в любое время.
Также довольно просто создать ветку с именем «new_feature» в вашем терминале и переключиться на нее с помощью
git checkout -b new_feature
Как только вы создадите ветку, вы можете внести изменения в эту ветку. Это позволяет легко увидеть, что вы изменили и почему вы это изменили. Каждый раз, когда вы фиксируете свои изменения, вы добавляете сообщение, которое вы можете использовать для описания того, что вы сделали.
Давайте поговорим об оформлении заказа!
git checkout
позволяет проверить хранилище, в котором вы в данный момент не находитесь. Вы можете проверить мастер ветку с
git checkout master
или посмотрите на ветку «new_feature» с
git checkout new_feature
Когда вы закончили работу с веткой, вы можете объединить все свои изменения обратно, чтобы они были видны всем.
git merge new_feature
возьмет все изменения, которые вы внесли в ветку «new_feature», и добавит их в мастер.
Чтобы создать восходящую ветвь, чтобы вы могли отправить свои изменения и установить удаленную ветвь как восходящую, вы добавите свою функцию, запустив
git push --set-upstream origin new_feature
После того, как вы внесете некоторые изменения и решите, что они вам нравятся, вы открываете запрос на включение. Если вы в команде, это когда другие люди в вашей команде могут начать проверять ваши изменения и обсуждать их. Вы можете открыть запрос на удаление в любой момент, будь то, чтобы люди просмотрели ваши окончательные изменения или попросили о помощи, потому что вы застряли на чем-то.
Ветки
В git есть понятие branch (ветка). Ветка — это покоммитный “путь” до некоторого коммита, называемого “концом” (tip) ветки. Мы можем иметь несколько независимых веток при работе. Коммит делается в конкретную ветку, по умолчанию это ветка master. Создать новую ветку можно как на сайте, так и в приложении GitHub Desktop. Для этого нужно выбрать вкладку Current branch и нажать на New branch:
Выбираем имя и в эту ветку пойдет вся информация с ветки master (точнее, новая ветка будет “смотреть” на тот же коммит, что и master), в том числе и все файлы:
И теперь мы можем переключать ветки и вносить изменения в конкретную ветку, не затрагивая основную, в данном случае master. Например, мы удалим один файл, и изменим другой. Удалённый файл будет отмечен красным минусом, а изменённый — желтой точкой. При этом справа видно, что мы работаем в ветке Features.
Делаем коммит в новую ветку и смотрим, что произошло. Как мы видим, в ветке master всё осталось, как прежде. Она по прежнему указывает на тот же коммит, что и раньше.
А вот в ветке Features удалённого файла уже нет. Переключить ветку можно, нажав на кнопку Branch с названием ветки:
Ветки удобно использовать для добавления новых функция, что они не ломали рабочий код до новой функции. После разработки ветку можно объединить с master (merge, смёржить, слить) сделав так называемый Pull request.
Что такое Git?
Git — система контроля версий (version control system, VCS), созданная программистом Линусом Торвальдсом для управления разработкой ядра Linux в 2005 году. Хорошо, а что это всё-таки значит?
Представьте, что вы с коллегами вместе пишете ядро Linuxнаучную статью. У вас на компьютере есть папка, где лежат текстовые документы, картинки, графики и прочие нужные файлы; то же самое есть и у ваших коллег. Когда кто-то из вас изменяет, добавляет или удаляет файлы, остальные этих изменений не видят. Вы пишете друг другу об изменениях, пересылаете обновленные версии файлов, но в процессе работы непременно возникает путаница: какая версия текста — последняя? Куда и когда исчезла пара абзацев? Кто внес те или иные правки? Избежать таких проблем и помогают системы контроля версий. Устроено это так:
- Ваша папка на компьютере — это не просто папка, а локальный репозиторий.
- Она является копией удалённого репозитория, который лежит на веб-хостинге (например, GitHub или BitBucket).
- Eсли вы работаете над проектом с коллегами, то своя локальная копия есть у каждого.
- Kогда вы внесли некоторое количество изменений, вы можете их сохранить, и это действие запишется в журнал; это называется commit (коммит).
- После этого можно отправить изменения в удалённый репозиторий; это называется push (пуш, пу́шить, запу́шу, пуши́ от души).
- Актуальная версия проекта, учитывающая последние изменения всех участников, будет храниться в удалённом репозитории.
- Если вы увидели, что ваши коллеги запушили в удалённый репозиторий что-то новенькое, то можно (и нужно!) “скопировать” это себе на компьютер (в локальный репозиторий); это называется pull (пулл).
Чем-то похоже на Dropbox, Google Drive и прочие облачные хранилища, правда? Только в данном случае ваши файлы синхронизируются не автоматически, а по команде, и возможностей управления ими гораздо больше.
Понятно, что для совместной работы над текстом научной статьи вполне хватит и Google Docs, но вот если, например, вы хотите опубликовать результаты исследования в интернете и сделать для этого собственный сайт, то без VCS обойтись сложно. И ещё раз, системы контроля версий хороши тем, что:
- они позволяют работать над проектом в команде;
- вы видите, кем и когда были внесены те или иные изменения;
- их всегда можно откатить назад;
- вы не потеряете проделанную работу, даже если что-то удалите на своем компьютере;
- ваши наработки могут быть полностью открыты для других (а это доступность знаний и ускорение развития технологий, ура!);
- GitHub и GitLab позволяют не только хранить и просматривать файлы проекта, но и публиковать веб-сайты, документацию и т.п.
Существует много систем управления версиями, но мы будем пользоваться самой распространенной — git. Также нам нужно как-то отдавать гиту команды, и делать это можно двумя способами: с помощью командной строки и через графический интерфейс (graphical user interface, GUI). Графический интерфейс программы — это все те окошки с кнопочками, которые мы привыкли видеть. Существует много графических интерфейсов для Git, например:
- TortoiseGit
- GitKraken
- GitHub Desktop
- Fork
- Git GUI
- Git Extensions
- SourceTree
Мы будем пользоваться программой GitHub Desktop, которую можно скачать отсюда. Если вы уже знакомы с Git, то вы можете выбрать любую программу или пользоваться командной строкой — это не принципиально. Стоит отметить, что пользоваться командной строкой гораздо сложнее чем графическим интерфейсом, поэтому она больше подходит продвинутым пользователям.
Итого:
- Git — разновидность системы контроля версий (самая популярная). Его можно скачать и установить, далее использовать через командную строку.
- Можно использовать графический интерфейс для работы с Git. При этом скачивать и устанавливать сам Git отдельно не нужно, он обычно идет в комплекте с графическим интерфейсом (но не во всех GUI).
- Репозиторий — это место где мы храним наш код проекта и всю информацию по файлам, их изменения и т.д. Репозиторий должен где-то хранится, чтобы у всех был доступ к нему и они могли видеть изменения. Его можно хранить и на домашнем компьютере, но не всегда удобно держать компьютер включенным целыми сутками, поэтому используют хостинги для репозиториев. Одними из самых известных являются GitHub и GitLab.
Я не знаю, что вы только что сказали (Вариант 2)
Я собираюсь предположить, что любой, кто интересуется вариантом 2, является новичком во всем этом и, возможно, имеет папку, полную файлов (или вы планируете иметь один), который вы хотите поместить на GitHub, и вы просто не знаете как это сделать.
Давайте сделаем это!
Скажем, вы хотите создать новый репозиторий. (Вероятно, так и есть! Именно здесь будет жить ваш проект. Если вы не собираетесь создавать новый репозиторий, вы, вероятно, захотите клонировать существующий репозиторий. Мы поговорим об этом позже, но именно так вы получаете чужой проект и информация, которая вам нужна для вашей работы или курса, который вы выбираете.)
Вашхранилищегде вы будете организовывать свой проект. Вы можете хранить папки, файлы, изображения, видео, электронные таблицы, записные книжки Jupyter, наборы данных и все остальное, что нужно вашему проекту. Прежде чем вы сможете работать с Git, вы должны инициализировать репозиторий для вашего проекта и настроить его так, чтобы Git управлял им. Вы можете сделать это прямо на сайте GitHub.
Это хорошая идея, чтобы включитьПРОЧТИ МЕНЯфайл с информацией о вашем проекте. Вы можете создать один в то же время, когда вы создаете свой репозиторий, щелкнув флажок.
- Перейдите на веб-сайт GitHub, посмотрите в верхнем правом углу, нажмите знак +, а затем нажмите «Новый репозиторий».
- Назовите репозиторий и добавьте краткое описание.
- Решите, хотите ли вы, чтобы это был публичный или частный репозиторий
- Нажмите «Инициализировать этот репозиторий с помощью README», если вы хотите включить файл README. (Я определенно рекомендую сделать это! Это первое, на что люди обратятся, когда проверят ваш репозиторий. Это также отличное место для размещения информации, которая вам необходима, чтобы понять или запустить проект.)
Новый репозиторий 
Создание вашего нового хранилища
Вы можете полностью начать работать прямо с этого момента, если хотите! Вы можете загружать файлы, редактировать файлы и т. Д. Прямо из своего репозитория на веб-сайте GitHub. Тем не менее, вы не можете быть удовлетворены только этой опцией.
Есть два способа внести изменения в ваш проект. Вы можете вносить изменения в свои файлы / записные книжки на своем компьютере, а также вносить изменения прямо на GitHub.
Допустим, вы хотите внести некоторые изменения в свой файл README прямо на GitHub.
- Сначала зайдите в свой репозиторий.
- Нажмите на имя файла, чтобы вызвать этот файл (например, нажмите «README.md», чтобы перейти к файлу readme).
- Нажмите значок карандаша в верхнем правом углу файла и внесите некоторые изменения.
- Напишите короткое сообщение в поле, которое описывает сделанные вами изменения (и расширенное описание, если хотите).
- Нажмите кнопку «Подтвердить изменения»
Редактирование вашего файла на GitHub 
Передача ваших изменений
Теперь изменения были внесены в файл README в вашем новом хранилище! (Я хочу обратить ваше внимание на маленькую кнопку, которую вы можете отметить на изображении выше, которая позволит вам создать новую ветку для этого коммита и запустить запрос на извлечение. Мы поговорим об этом позже!). Довольно легко, правда?
Довольно легко, правда?
Я предпочитаю работать с файлами на своем локальном компьютере, а не пытаться заставить все работать с веб-сайта GitHub, поэтому давайте настроим это сейчас.
Дальнейшие коммиты
Теперь давайте изменим несколько файлов после нашего первого коммита. После их изменения, мы увидим, что в результате выполнения команды git status Git обнаружил изменения в файлах, которые он отслеживает:
Вы можете проверить изменения в отслеживаемых файлах, сделанные в последнем коммите, с помощью команды git diff. Если вы хотите просмотреть изменения в определенном файле, используйте команду git diff <file>:
Вам нужно добавить эти файлы снова, чтобы осуществить изменения в отслеживаемых файлах для следующего коммита. Можно добавить все отслеживаемые файлы, выполнив команду:
git add -u
Вы можете избежать использования этой команды, воспользовавшись префиксом -a для команды git commit, который добавит все изменения в отслеживаемые файлы.
Этот процесс, однако, очень опасен, так как может навредить проекту. Например, допустим, что вы открыли файл и изменили его по ошибке.
Если вы избирательно размещаете файлы, то заметите изменения в каждом файле. Но если вы добавите префикс -a к вашему коммиту, все файлы будут закоммичены, и вы не сможете выявить возможные ошибки.
После того, как вы разместили ваши файлы, можно приступить к коммиту. Я упоминал, что с каждым коммитом может быть ассоциировано сообщение, которое мы вводим с помощью префикса -m.
Однако существует возможность ввести сообщение в несколько строк, воспользовавшись командой git commit, которая открывает интерактивную форму для записи:
git commit
Клонируем репозиторий
Теперь нам нужно сделать локальную копию нашего удалённого репозитория. Мы снова воспользуемся кнопкой Clone or download, но теперь используем полную ссылку на репозиторий; эту ссылку нужно скопировать (Если у вас окошко выглядит не так как на картинке, то нажмите в окне на ссылку справа сверху Use HTTPS).
Для дальнеших шагов нам потребуется скачать и установить GitHub Desktop. После установки и первого запуска, возможно, потребуется войти в ваш аккаунт GitHub. Далее выбираем Clone repository или через File, а затем уже Clone repository.
Тут мы выбираем из списка репозиторий:
Тут мы вставляем ссылку на репозиторий:
Вне зависимости от выбора, все файлы с удаленного репозитория перейдут в указанную папку.
Три состояния в Git и переключение между ними
Пример команды: git reset —hard HEAD и git status -s
Как вы, наверное, уже знаете, файл в Git может находится в одном из трёх состояний:
- unstaged — не добавлен в индекс для коммита
- staged — добавлен в индекс для коммита
- commited — закоммичен
(На самом деле есть ещё, как минимум, статус untracked — файл не добавлен в репозиторий — прим. перев.).
С помощью команды git status вы можете получить подробное описание файлов и их состояний. Чтобы добавить файл в индекс для коммита (перевести его из состояния unstaged в состояние staged), нужно выполнить команду git add filename.js. Команда git add . добавляет сразу все файлы (в текущей директории — прим. перев.).
Для более быстрого и простого просмотра состояния файлов можно воспользоваться командой git status -s, результат будет выглядеть примерно так:
Очевидно, что команда git status не покажет вам уже закоммиченные файлы, для их просмотра следует использовать команду git log.
Есть ещё несколько команд для переключения состояния файлов.
Сброс состояния файлов
Сброс позволяет откатиться на определённую версию в истории изменений Git. Всего есть три вида сброса:
- git reset —hard `some-commit-hash` — вернуться на определённый коммит в истории. Все изменения, сделанные после этого коммита пропадут.
- git reset `some-commit-hash` — вернуться на определённый коммит в истории. Все изменения, сделанные после этого коммита, получат состояние «Not staged for commit». Чтобы вернуть их обратно, нужно использовать команды git add и git commit.
- git reset —soft `some-commit-hash` — вернуться на определённый коммит в истории. Все изменения, сделанные после этого коммита, получат состояние «Staged for commit». Чтобы вернуть их обратно, нужно использовать команду git commit.
Поналачу эта информация может показаться бесполезной, однако, когда вы начнёте работать с разными версиями файлов, она вам очень пригодится. Например, я для себя выделил вот такие сценарии использования этих команд:
- Если я хочу отменить все внесённые изменения и начать работу с чистого листа, я использую команду git reset —hard HEAD (самый частый случай).
- Если я хочу отредактировать изменения и/или закоммитить файлы в другом порядке, я использу git reset `some-start-point-hash`.
- Если я просто хочу взять три последних коммита и слить их в один большой коммит, я использую команду git reset —soft `some-start-point-hash`.
Выгрузка отдельных файлов
если вам нужно отменить некоторые локальные изменения для конкретных файлов, но при этом изменения для других файлов трогать не нужно, гораздо проще забрать закоммиченные изменения этих файлов с помощью команды git checkout forget-my-changes.js. Это как git reset —hard, только для конкретного файла.
Также можно забирать разные версии файла из других коммитов или веток: git checkout some-branch-name file-name.js и git checkout `some-commit-hash` file-name.js.
Обратите внимание, что выгруженные файлы будут находиться в состоянии «Staged for commit», и чтобы убрать их из индекса для коммита нужно будет использовать команду git reset HEAD file-name.js. Для возврата в исходное состояние просто наберите git checkout file-name.js ещё раз
Обратите внимание, что команда git reset —hard HEAD file-name.js не сработает. В целом процедура смены состояний в Git несколько запутана и не всегда можно сходу понять, что и как нужно сделать
Я надеюсь, что в этом совете я доступно и понятно всё объяснил.
Как пользоваться Git?
Дальше я буду предполагать, что вы выполнили установку и базовую настройку git. Кроме установки, вам нужно указать правильный адрес электронной почты и имя пользователя для доступа к серверу Git, например, на GitHub. Если вы этого еще не сделали смотрите инструкцию установка Git в Ubuntu 16.04.
Обычно, структура проекта в Git будет зависеть от масштаба и сложности вашей программы. Но для начала мы будем использовать проект, состоящий только из одной ветви. Каждый проект содержит одну ветку по умолчанию, она называется master. Наш первый проект будет называться test.
Создание проекта
Когда настройка git завершена перейдем к вашему проекту. В самом начале вам достаточно создать папку для файлов проекта. Если вы собираетесь работать над несколькими проектами, создайте папку git в вашем домашнем каталоге, а уже туда поместите папки ваших проектов:
Эта команда создаст нужную структуру папок и переводит текущий каталог в только что созданный. Теперь создадим первый файл нашего проекта:
Проект готов, но система контроля версий git еще не знает об этом.
Настройка проекта в git
Перед тем как git начнет отслеживать изменения, нужно подготовить все необходимые конфигурационные файлы. Сначала инициализируем пустой репозиторий в нашей папке:
После того как репозиторий будет создан, вам нужно добавить свои файлы в него. Каждый файл нужно добавлять отдельно или сказать утилите, что необходимо добавить все файлы явно. Пока вы не добавите файл сам он не будет отслеживаться. Новые файлы в будущем тоже нужно добавлять, они не добавляются автоматически. Сначала добавим текущую папку:
Если все прошло хорошо, то команда ничего не выведет.
Фиксация изменений
Изменения тоже автоматически не отслеживаются. Фиксация изменений выполняется с помощью команды commit. Вам нужно указать что было изменено с помощью небольшого комментария, буквально в несколько предложений. Хорошая практика выполнять фиксацию перед каждым серьезным изменением.
Таким образом, вы будете хранить все версии проекта, от самой первой и до текущей, а также сможете знать что, когда и где было изменено. Чтобы создать свой первый коммит выполните:
Команде необходимо передать два параметра, первый — это -m, ваш комментарий, второй -a, означает, что нужно применить действие ко всем измененным файлам. Для первого раза используется этот параметр, но обычно вам нужно указать измененные файлы или каталоги. Например, можно делать так:
Отправка изменений
До этого момента мы делали все в локальном репозитории. Вы можете использовать git локально, если нужен только контроль версий, но иногда нужно обменяться информацией с другими разработчиками и отправить данные в удаленный репозиторий.
Сначала нужно добавить удаленный репозиторий с помощью команды remote. Для этого нужно передать ей URL:
Затем можно посмотреть список удаленных репозиториев:
Вы можете использовать не только github сервера, но и любые другие. Теперь для отправки ваших изменений используйте такую команду:
Команда push указывает, что нужно отправить данные в удаленный репозиторий, origin — наш настроенный репозиторий, а master — ветвь.
Управление ветвями
Для простых проектов достаточно одной ветви. Но если проект большой и он имеет несколько версий, в том числе тестовую, то может понадобиться создать для каждой из них отдельную ветвь. Сначала смотрим доступные ветви:
Опция -a указывает что нужно вывести все ветви, даже не синхронизированные. Звездочка указывает на активную ветвь. Теперь создадим ветвь для разработки с помощью команды checkout:
Переключаться между ветвями можно тоже с помощью той же команды:
Теперь создадим еще один файл:
И добавим его в нашу новую ветвь develop:
Сделаем коммит для внесенных изменений:
Дальше проверим существует ли этот файл в основной ветке master или только в дополнительной. Смотрим текущую ветку:
Затем переключаемся на ветку master и снова смотрим:
Здесь файла нет, так и должно быть. В git есть такая полезная вещь, как слияние. С помощью нее вы можете объединить две ветви. Например, переместить код из рабочей ветки в стабильную. Для этого достаточно выполнить команду merge:
Перед тем как будет выполнено слияние вам нужно ввести комментарий, зачем это нужно. Затем если вы еще раз выполните ls, то увидите, что здесь уже есть нужный файл. Наши примеры git подошли к концу.
