Начало работы с Git: подробный гайд для новичков

Статья из группы Random

Вместо вступления

Привет тебе, будущий Senior Software Engineer. Начало работы с Git: подробный гайд для новичков - 1Сегодня поговорим о системе контроля версий, а именно о Git (читается как ГИТ, а не ДЖИТ, как могло бы показаться из грамматики английского языка). Да-да, я знаю что есть еще и Mercurial, SVN… Но будем откровенны: их время уже ушло, и тратить ваше драгоценное время на них не собираюсь. Чтобы вы понимали важность знания гита в наше время, скажу так: без знания/понимания этого вам делать в программировании нечего. Но прелесть в том, что для постоянной работы не нужно держать в голове все команды и возможности. Нужно знать набор команд, которые помогут понимать всё, что происходит.

Основы Git

Git — это распределенная система контроля версий нашего кода. Зачем она нам? Для распределенных команд нужна какая-то система управления работы. Нужна, чтобы отслеживать изменения, которые происходят со временем. То есть шаг за шагом мы видим, какие файлы изменились и как. Особенно это важно, когда анализируешь, что было проделано в рамках одной задачи: это дает возможность возвращаться назад. Представим себе ситуацию: был работающий код, всё в нем было хорошо, но мы решили что-то улучшить, там подправить, сям подправить. Все ничего, но такое улучшение поломало половину функционала, сделало невозможным работу. И что дальше? Без Гита нужно было бы часами сидеть и вспоминать, как же все было изначально. А так мы просто откатываемся на коммит назад — и все. Или что делать, если есть два разработчика, которые делают одновременно свои изменения в коде? Без Гита это выглядит так: они скопировали код из оригинала, сделали что нужно. Наступает момент, и оба хотят добавить свои изменения в главную папку. И что делать в этой ситуации?.. Я даже не берусь оценить время, чтоб проделать эту работу. Таких проблем не будет вовсе, если пользоваться Гитом.

Установка Git

Установим гит на компьютер. Я понимаю, что у всех разные OS, поэтому постараюсь описать для нескольких случаев.

Установка для Windows

Как обычно, нужно скачать exe файл и запустить его. Здесь все просто: жмем на первую ссылку гугла, устанавливаем и всё. Для работы будем использовать bash консоль, которую они предоставляют. Чтобы работать в виндоусе, нужно запустить Git Bash. Вот как он выглядит в меню пуск: Начало работы с Git: подробный гайд для новичков - 2И это уже консоль, в которой можно работать. Чтобы не переходить каждый раз в папку с проектом, чтобы там открыть гит, можно в папке правой кнопкой мыши открыть консоль с нужным нам путем: Начало работы с Git: подробный гайд для новичков - 3

Установка для Linux

Обычно git уже установлен и есть в дистрибутивах линукса, так как это инструмент, первоначально написанный для разработки ядра линукса. Но бывают ситуации, когда его нет. Чтобы проверить это, нужно открыть терминал и прописать: git --version. Если будет вразумительный ответ, ничего устанавливать не нужно. Открываем терминал и устанавливаем. Я работаю на Ubuntu, поэтому могу сказать, что писать для нее: sudo apt-get install git. И все: теперь в любом терминале можно пользоваться гитом.

Установка на macOS

Здесь также для начала нужно проверить, есть ли уже гит (смотри выше, как на линуксе). Если все же нет, самый простой путь — это скачать отседова последнюю версию. Если установлен XCode, то гит уже точно будет автоматически установлен.

Настройка гита

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

git config --global user.name ”Ivan Ivanov”
git config --global user.email ivan.ivanov@gmail.com
Если есть необходимость для конкретного проекта поменять автора (для личного проекта, например), можно убрать --global, и так получится:

git config user.name ”Ivan Ivanov”
git config user.email ivan.ivanov@gmail.com

Немного теории…

Чтобы быть в теме, желательно добавить в свое обращение несколько новых слов и действий… А то говорить будет не о чем. Конечно это некий жаргон и калька с английского, поэтому я буду добавлять значения на английском. Какие слова и действия?
  • гит репозиторий (git repository);
  • коммит (commit);
  • ветка (branch);
  • смерджить (merge);
  • конфликты (conflicts);
  • спулить (pull);
  • запушить (push);
  • как игнорировать какие-то файлы (.gitignore).
И так далее.

Состояния в Гит

У Гита есть несколько состояний, которые нужно понять и запомнить:
  • неотслеживаемое (untracked);
  • измененное (modified);
  • подготовленное (staged);
  • закомиченное (committed).

Как это понимать?

Это состояния, в которых находятся файлы из нашего кода. То есть, их жизненный путь обычно выглядит так:
  1. Файл, который создан и не добавлен в репозиторий, будет в состоянии untracked.
  2. Делаем изменения в файлах, которые уже добавлены в гит репозиторий — находятся в состоянии modified.
  3. Из тех файлов, которые мы изменили, выбираем только те (или все), которые нужны нам (например, скомпилированные классы нам не нужны), и эти классы с изменениями попадают в состояние staged.
  4. Из заготовленных файлов из состояния staged создается коммит и переходит уже в гит репозиторий. После этого staged состояние — пустое. А вот modified еще может что-то содержать.
Выглядит это так (картиночка из официальной доки, так что можно верить)): Начало работы с Git: подробный гайд для новичков - 4

Что такое коммит

Коммит — это основной объект в управлении контроля версий. Он содержит все изменения за время этого коммита. Коммиты связаны между с собой как односвязный список. А именно: Есть первый коммит. Когда создается второй коммит, то он (второй) знает, что идет после первого. И таким образом можно отследить информацию. Также у коммита есть еще своя информация, так называемые метаданные:
  • уникальный идентификатор коммита, по которому можно его найти;
  • имя автора коммита, который создал его;
  • дата создания коммита;
  • комментарий, который описывает, что было сделано во время этого коммита.
Вот как это выглядит: Начало работы с Git: подробный гайд для новичков - 5

Что такое ветка

Начало работы с Git: подробный гайд для новичков - 6Ветка — это указатель какого-то коммита. Так как коммит знает, какой коммит был до него, когда ветка указывает на какой-то коммит, к ней относятся и все те предыдущие. Исходя из этого можно сказать, что веток, указывающих на один и тот же коммит, может быть сколько угодно много. Работа происходит в ветках, поэтому когда создается новый коммит, ветка переносит свой указатель на более новый коммит.

Начало работы с Гитом

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

Работа с гитом в локальном репозитории

Далее я предлагаю вам проделать все те шаги, которые проделал я, в то время как будете читать статью. Это улучшит ваше понимание и усвоение материала. Так что приятного аппетита :) Чтобы создать локальный репозиторий, нужно написать:

git init
Начало работы с Git: подробный гайд для новичков - 7После этого будет создана папка .git в том месте, где находится консоль. .git — это папка, которая хранит всю информацию о гит репозитории. Ее удалять не нужно ;) Далее, добавляются файлы в этот проект, и их состояние становится Untracked. Чтобы посмотреть, какой статус работы на данный момент, пишем:

git status
Начало работы с Git: подробный гайд для новичков - 8Мы находимся в master ветке, и пока мы не перейдем в другую, так все и останется. Таким образом видно, какие файлы изменены, но еще не добавлены в состояние staged. Чтобы добавить их в состояние staged, нужно написать git add. Здесь может быть несколько вариантов, например:
  • git add -A — добавить все файлы из состояния в staged;
  • git add . — добавить все файлы из этой папки и все внутренних. По сути тоже самое, что и предыдущее;
  • git add <имя файла> — добавляет только конкретный файл. Здесь можно пользоваться регулярными выражениями, чтобы добавлять по какому-то шаблону. Например, git add *.java: это значит, что нужно добавить только файлы с расширением java.
Ясно, что первые два варианта простые, а вот с добавлением будет интереснее, поэтому пишем:

git add *.txt
Чтобы проверить статус, используем уже известную нам команду:

git status
Начало работы с Git: подробный гайд для новичков - 9Отсюда видно, что регулярное выражение отработало верно, и теперь test_resource.txt находится в staged состоянии. И, наконец, последний этап (при локальном репозитории, с удаленным будет еще один ;)) — закоммитить и создать новый коммит:

git commit -m “all txt files were added to the project”
Начало работы с Git: подробный гайд для новичков - 10Далее есть отличная команда, чтобы посмотреть на историю коммитов в ветке. Воспользуемся ею:

git log
Начало работы с Git: подробный гайд для новичков - 11Здесь уже видно, что появился наш первый коммит с текстом, который мы передали. Очень важно понять, что текст, который мы передаем, должен максимально точно определять то, что было проделано за этот коммит. Это в будущем будет помогать множество раз. Пытливый читатель, который еще не уснул, может сказать: а что случилось с файлом GitTest.java? Сейчас узнаем, используем для этого:

git status
Начало работы с Git: подробный гайд для новичков - 12Как видим, он так и остался в состоянии untracked и ждет своего часа. А может мы вовсе не хотим его добавлять в проект? Бывает и такое. Далее, чтобы стало интереснее, попробуем изменить наш текстовый файл test_resource.txt. Добавим туда какой-то текст и проверим состояние:

git status
Начало работы с Git: подробный гайд для новичков - 13Здесь хорошо видна разница между двумя состояниями — untracked и modified. GitTest.java находится в состоянии untracked, а test_resource.txt находится в modified. Теперь, когда уже есть файлы в состоянии modified, мы можем посмотреть на изменения, которые были произведены над ними. Сделать это можно при помощи команды:

git diff
Начало работы с Git: подробный гайд для новичков - 14То есть здесь хорошо видно, что я добавил в наш текстовый файл hello world! Добавляем изменения в текстовом файле и коммитим:

git add test_resource.txt
git commit -m “added hello word! to test_resource.txt”
Чтобы посмотреть на все коммиты, пишем:

git log
Начало работы с Git: подробный гайд для новичков - 15Как видим, уже есть два коммита. Таким же образом добавляем и GitTest.java. Теперь без комментариев, просто команды:

git add GitTest.java
git commit -m “added GitTest.java”
git status
Начало работы с Git: подробный гайд для новичков - 16

Работа с .gitignore

Ясно, что мы хотим хранить только исходный код и ничего другого в репозитории. А что может быть еще? Как минимум, скомпилированные классы и/или файлы, которые создают среды разработки. Чтобы гит их игнорировал, есть специальный файл, который нужно создать. Делаем это: создаем файл в корне проекта с названием .gitignore, и в этом файле каждая строка будет шаблоном для игнорирования. В этом примере гит игнор будет выглядеть так:

```
*.class
target/
*.iml
.idea/
```
Смотрим теперь:
  • первая строка — это игнорирование всех файлов с расширением .class;
  • вторая строка — это игнорирование папки target и всего, что она содержит;
  • третья строка — это игнорирование всех файлов с расширением .iml;
  • четвертая строка — это игнорирование папки .idea.
Попробуем на примере. Чтобы посмотреть как это работает, добавим скомпилированный класс GitTest.class в проект и посмотрим статус проекта:

git status
Начало работы с Git: подробный гайд для новичков - 17Ясно, что мы не хотим как-то случайно (если использовать git add -A) добавить скомпилированный класс в проект. Для этого создаем .gitignore файл и добавляем все, что описывалось ранее: Начало работы с Git: подробный гайд для новичков - 18Теперь добавим новым коммитом гит игнор в проект:

git add .gitignore
git commit -m “added .gitignore file”
И теперь момент истины: у нас есть в untracked состоянии скомпилированный класс GitTest.class, который мы не хотели добавлять в гит репозиторий. Вот здесь-то и должен заработать гит игнор:

git status
Начало работы с Git: подробный гайд для новичков - 19Все чисто) Гит игнору +1)

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

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

git branch -a
Начало работы с Git: подробный гайд для новичков - 20Видно, что у нас только одна ветка master, и звездочка перед ней говорит, что мы находимся на ней. К слову, чтобы узнать, на какой ветке мы находимся, можно воспользоваться и проверкой статуса (git status). Далее есть несколько вариантов создания веток (может их и больше, я использую эти):
  • создать новую ветку на основе той, на которой находимся (99% случаев);
  • создать ветку на основе конкретного коммита (1%).

Создаем ветку на основе конкретного коммита

Опираться будем на уникальный идентификатор коммита. Чтобы найти его, напишем:

git log
Начало работы с Git: подробный гайд для новичков - 21Я выделил коммит с комментарием “added hello world…”. У него уникальный идентификатор — “6c44e53d06228f888f2f454d3cb8c1c976dd73f8”. Я хочу создать ветку development начиная с этого коммита. Для этого напишу:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8
Создается ветка, в которой будут только первые два коммита из ветки master. Чтобы проверить это, мы сперва убедимся, что перешли в другую ветку и посмотрим на количество коммитов ней:

git status
git log
Начало работы с Git: подробный гайд для новичков - 22И правда: получилось, что у нас два коммита. Кстати, интересный момент: в этой ветке еще нет файла .gitignore, поэтому наш скомпилированный файл (GitTest.class) теперь подсвечивается в untracked состоянии. Теперь можем провести еще раз ревизию наших веток, написав:

git branch -a
Начало работы с Git: подробный гайд для новичков - 23Видно, что есть две ветки — master и development — и сейчас стоим на development.

Создаем ветку на основе текущей

Второй способ создания ветки — создание на основе другой. Я хочу создать ветку на основе master ветки, поэтому нужно сперва перейти на нее, а уже следующим шагом — создать новую. Смотрим:
  • git checkout master — переходим на ветку master;
  • git status — проверяем, точно ли на мастере.
Начало работы с Git: подробный гайд для новичков - 24Вот здесь видно, что мы перешли на master ветку, здесь уже работает гит игнор, и скомпилированный класс уже не светится как untracked. Теперь создаем новую ветку на основе master ветки:

git checkout -b feature/update-txt-files
Начало работы с Git: подробный гайд для новичков - 25Если есть сомнения, что эта ветка будет не такой же, как и master, можно это легко проверить, написав git log и посмотреть на все коммиты. Там их должно быть четыре.

Резолвим конфликты

Прежде чем разобраться с тем, что такое конфликт, нужно поговорить о слиянии (смердживании) одной ветки в другую. Вот такой картинкой можно показать процесс, когда одну ветку мерджат в другую: Начало работы с Git: подробный гайд для новичков - 26То есть, есть главная ветка. От нее в какой-то момент создают второстепенную, в которой происходят изменения. Как только работа сделана, нужно слить одну ветку в другую. Я не буду описывать разные особенности: я хочу донести в рамках этой статьи только понимание, а уже детали узнаете сами, если будет нужно. Так вот, на нашем примере, мы создали ветку feature/update-txt-files. Как написано в имени ветки — обновим текст. Начало работы с Git: подробный гайд для новичков - 27Теперь нужно создать под это дело новый коммит:

git add *.txt 
git commit -m “updated txt files”
git log
Начало работы с Git: подробный гайд для новичков - 28Теперь, если мы хотим смерджить feature/update-txt-files ветку в master, нужно перейти в master и написать git merge feature/update-txt-files:

git checkout master
git merge feature/update-txt-files
git log
Начало работы с Git: подробный гайд для новичков - 29Как результат — теперь и в мастер ветке есть коммит, который был добавлен в feature/update-txt-files. Эта функциональность добавлена, поэтому можно удалить фиче (feature) ветку. Для этого напишем:

git branch -D feature/update-txt-files
Пока понятно, да? Усложняем ситуацию: теперь допустим, что опять нужно изменить txt файл. Но теперь еще и в мастере этот файл будет изменен также. То есть он будет параллельно изменяться, и гит не сможет понять что нужно делать в ситуации, когда мы захотим смерджить в master ветку новый код. Поехали! Создаем новую ветку на основе master, делаем изменения в text_resource.txt и создаем коммит под это дело:

git checkout -b feature/add-header
... делаем изменения в файле
Начало работы с Git: подробный гайд для новичков - 30

git add *.txt
git commit -m “added header to txt”
Начало работы с Git: подробный гайд для новичков - 31Переходим на master ветку и также обновляем этот текстовый файл в той же строке, что и фиче ветка:

git checkout master
… обновили test_resource.txt
Начало работы с Git: подробный гайд для новичков - 32

git add test_resource.txt
git commit -m “added master header to txt”
И теперь самый интересный момент: нужно смерджить изменения из feature/add-header ветки в master. Мы находимся в мастер ветке, поэтому нужно только написать:

git merge feature/add-header
Но мы получим результат с конфликтом в файле test_resource.txt: Начало работы с Git: подробный гайд для новичков - 33И здесь мы можем видеть, что гит не смог самостоятельно решить, как смерджить этот код и говорит, что нужно вначале разрезолвить конфликт, а уже потом сделать коммит. Ок, открываем в текстовом редакторе файл, в котором конфликт, и видим:Начало работы с Git: подробный гайд для новичков - 34Чтобы понять, что здесь сделал гит, нужно вспомнить, что мы где писали, и сравнить:
  1. между “<<<<<<< HEAD” и “=======” находятся изменения мастер, которые были в этой строке в мастер ветке.
  2. между “=======” и “>>>>>>> feature/add-header” находятся изменения, которые были в feature/add-header ветке.
Таким образом гит показывает, что в этом месте он не смог понять, как слить воедино этот файл, разделил этот участок на две части из разных веток и предложил решить нам самим. Хорошо, твердою волей решаю убрать все, оставить только слово header: Начало работы с Git: подробный гайд для новичков - 35Посмотрим на статус изменений, описание будет несколько другим. Будет не modified состояние, а Unmerged. Так что смело можно было добавить пятое состояние… Но я думаю, что это излишне, посмотрим:

git status
Начало работы с Git: подробный гайд для новичков - 36Убедились, что это другой случай, необычный. Продолжаем:

git add *.txt
Начало работы с Git: подробный гайд для новичков - 37В описании можно заметить, что предлагают написать только git commit. Слушаем и пишем:

git commit
Начало работы с Git: подробный гайд для новичков - 38И все: таким образом мы сделали это — разрезолвили конфликт в консоли. Конечно, в средах разработки можно это сделать немного проще, например, в Intellij IDEA все настроено так хорошо, что можно выполнять все необходимые действия в ней. Но среда разработки делает много чего “под капотом”, и мы зачастую не понимаем, что именно там произошло. А когда нет понимания, тогда могут возникнуть и проблемы.

Работа с удаленными репозиториями

Последний шаг — разобраться еще с несколькими командами, которые нужны для работы с удаленным репозиторием. Как я уже говорил, удаленный репозиторий — это какое-то место, где хранится репозиторий и откуда можно его клонировать. Какие бывают удаленные репозитории? Примеров тьма:
  • GitHub — это крупнейшее хранилище для репозиториев и совместной разработки. Я уже описывал его в предыдущих статьях.
    Подписывайтесь на мой гитхаб аккаунт. Я часто выставляю там свои наработки в тех сферах, которые изучаю во время работы.

  • GitLab — веб-инструмент жизненного цикла DevOps с открытым исходным кодом, представляющий систему управления репозиториями кода для Git с собственной вики, системой отслеживания ошибок, CI/CD пайплайн и другими функциями.
    После новости о том, что Microsoft купила GitHub, некоторые разработчики продублировали свои наработки в GitLab.

  • BitBucket — веб-сервис для хостинга проектов и их совместной разработки, основанный на системе контроля версий Mercurial и Git. Одно время имел большое преимущество перед GitHub в том, что у него были бесплатные приватные репозитории. В прошлом году GitHub также открыл эту возможность для всех бесплатно.

  • И так далее…

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

git clone https://github.com/romankh3/git-demo
Теперь локально есть полная копия проекта. Чтобы быть уверенным, что локально находится последняя копия проекта, нужно, как говорится, спулить данные, написав:

git pull
Начало работы с Git: подробный гайд для новичков - 39В нашем случае сейчас ничего не изменилось удаленно, поэтому и ответ: Already up to date. Но если я внесу какие-то изменения в удаленном репозитории, локальный обновится после того, как мы их спулим. И, наконец, последняя команда — запушить данные на удаленный репозиторий. Когда мы локально что-то сделали и хотим это передать на удаленный репозиторий, нужно сперва создать новый коммит локально. Для этого добавим в наш текстовый файл еще что-нибудь: Начало работы с Git: подробный гайд для новичков - 40Теперь уже обыденная для нас вещь — создаем коммит под это дело:

git add test_resource.txt
git commit -m “prepated txt for pushing”
И теперь команда, чтобы отправить это на удаленный репозиторий:

git push
Начало работы с Git: подробный гайд для новичков - 41Вот и все, что я хотел рассказать. Спасибо за внимание. Подписывайтесь на мой аккаунт на GitHub, в котором я выкладываю разные прикольные проекты-примеры из того, что я изучаю и использую на работе.

Полезные ссылки

Комментарии (54)
Владимир Уровень 0
3 июня 2022
Случилось странное с гитом. Пока я управлял слиянием веток из консоли все было +/- норм, но потом я проделал те же операции с частью веток прямо в удаленном репозитории и началось... Широко открытыми от изумления глазами я наблюдал, как из моего проекта начали исчезать одна за другой папки... Итого: из 8 папок, хранившихся в проекте, осталось 2, а 6 пропали. В сухом остатке в репозитории на гитхабе лежат все 8 папок в ветке master, а в проекте - только 2. При этом просто запулить из удаленного репозитория недостающие папки не выходит. Очень хочется двух вещей: 1) понять что произошло и почему, что бы не попасть в эту неловкую ситуацию снова. 2) понять как исправить не поправимое цивилизованными средствами. upd. проблема решилась сама собой. Не знаю что и как, но клиент IDEA действительно очень удобный
Абдулла Уровень 19, Санкт-Петербург
15 мая 2022
при вводе git commit -m “all txt files were added to the project” пишет error: pathspec 'txt' did not match any file(s) known to git error: pathspec 'files' did not match any file(s) known to git error: pathspec 'were' did not match any file(s) known to git error: pathspec 'added' did not match any file(s) known to git error: pathspec 'to' did not match any file(s) known to git error: pathspec 'the' did not match any file(s) known to git error: pathspec 'project”' did not match any file(s) known to git
Ivasishinav Уровень 18, Минск
28 марта 2022
создаю конфликт в txt файле между master и development ветками, делаю слияние в master ветку, решаю конфликт подправив txt файл вручную, добавляю txt файл в master ветку, пишу git commit и выдает такое окно git status после перезапуска git bash такой совет YesOn для выхода : "Нажимаете клавишу Esc и пишете команду: ":wq", затем нажимаете Enter." помог, спасибо! Но что это за окно не понятно
Alex Уровень 33
23 марта 2022
Через консоль это хорошо, не знаю, может быть я не прав, но зачем всё это, если через IDE проще понятнее и быстрее. Но как пользоваться консолью тоже нужно знать, поэтому к данному материалу я ещё вернусь точно. Но разобраться в том как это работает и как этим пользоваться помогло вот это видео , собственно сегодня только начал разбираться (первый вечер), до этого знал про git в общих чертах что это и зачем нужно, поэтому видео помогло лучше чем статья. К статье вернусь позже. Пишу не ради критики, а для таких же как я, решивших разобраться с нуля, на мой взгляд проще понять через IDE
YesOn Уровень 8, Томск, Россия
11 февраля 2022
Если при выполнении инструкции статьи в разделе: "Резолвим конфликты" после команды:

git commit
вы попали в редактор коммитов и не знаете как оттуда выйти, то делается это так: Нажимаете клавишу Esc и пишете команду: ":wq", затем нажимаете Enter. Ещё, если после этой команды:

git clone https://github.com/romankh3/git-demo
у вас не срабатывает команда

git pull
внимательно посмотрите на скрин инструкции и перейдите в каталог git-demo, для этого нужно набрать в редакторе команду:

cd git-demo
Это на случай, если Вам так и не удалось догадаться. почему что-то пошло не по инструкции, эти моменты просто там пропущены. Наверное чтобы тренировать внимательность, учиться разбираться и осознавать, что ты делаешь 🙂.
YesOn Уровень 8, Томск, Россия
11 февраля 2022
Есть ещё один лайфхак, чтобы не писать длинное название файла с расширением или длинное название ветки начните набирать пару символов. затем нажимайте клавишу Tab на клавиатуре, и в консоли автоматически заполняется нужное название с расширением. Это поможет от опечаток.
Andrei Уровень 18, Минск, Беларусь
28 января 2022
Толковая статья. Спасибо!
4 ноября 2021
Хорошая статья. Её бы еще немного доработать. смерджить(merge), спулить (pull), запушить (push) - в вашем варианте "перевода", получились жаргонные слова. Они не дают нам понимания, жаргон - это только ругательства. Термины "с улицы" или "дворовые". Также как, если бы вы использовали русские ругательства матом. Их можно перевести и подобрать к ним более точные синонимы русского языка. Еще один момент: Вы употребляете "мы находимся" . Не совсем верно. Мы находимся на кафедре, мы находимся перед компьютером. Точнее будет "текущее выбранное приложение", "сейчас у нас выбрана ветка", сейчас у нас выбрана консоль или приложение такое-то.
hidden #2641196 Уровень 51
11 августа 2021
отлично
Roman Beekeeper Уровень 35
11 марта 2021
⚡️UPDATE⚡️ Друзья, создал телеграм-канал 🤓, в котором освещаю свою писательскую деятельность и свою open-source разработку в целом. Не хотите пропустить новые статьи? Присоединяйтесь ✌️