Linux где лежит git

Обновлено: 02.07.2024

Git — один из видов систем контроля версий (или СКВ). Такие системы записывают изменения в набор файлов, а позже позволяют вернуться к определенной версии.
Вам может пригодиться СКВ, если вы, например, программист, системный администратор, дизайнер (или в целом работаете с массивом изменяющихся файлов) и хотите сохранить каждую версию проекта. Вы сможете вернуться к любому из сохраненных состояний, просмотреть изменения и увидеть их авторов. Так гораздо проще исправлять возникающие проблемы.

В целом СКВ можно разделить таким образом:

Локальные — все файлы хранятся только в вашей операционной системе, например, разложены по папкам с версиями.
Централизованные — проект хранится на сервере, а ваша рабочая версия включает только текущий набор файлов.
Распределенные — копии проекта (и вся информация о версиях) располагаются не только на сервере, но и на нескольких клиентских машинах, чтобы обеспечить устойчивость к отказу сервера.

Очевидно, что Git — не единственная система контроля версий, однако по многим параметрам самая удобная и популярная на сегодняшний день. Благодаря распределенной структуре репозитории Git хранятся на всех клиентских компьютерах, что защищает от потерь данных и позволяет полноценно управлять версиями проекта оффлайн.

Главная отличительная черта Git состоит в подходе к обработке данных. Каждый раз при сохранении данных проекта (коммите) система фиксирует состояние файла (делает снимок) и создает ссылку на этот снимок. Последующие изменения отражаются через ссылки на более ранние версии файла. Нет необходимости снова сохранять файл целиком. К тому же, основываясь на контрольных hash-суммах, система снимков обеспечивает целостность всей истории изменений. На практике это означает, что невозможно (либо крайне трудно) полностью удалить данные из рабочего каталога и утратить к ним любой доступ. В большинстве случаев данные можно восстановить из ранней версии проекта.

Таким образом, систему контроля версий в Git проще всего представлять как поток снимков (сохраненных состояний проекта).

Принципы работы с Git

У проектных файлов в Git есть 3 базовых состояния

Измененные (modified) — файлы в процессе рабочего редактирования.
Индексированные (staged) — та часть измененных файлов, которая уже подготовлена к фиксации после редактирования.
Зафиксированные (committed) — файлы, уже сохраненные в локальном репозитории.

У Git есть рабочий каталог, где хранятся метаданные и локальная база рабочего проекта. Именно эта часть копируется, когда вы клонируете проект (репозиторий) с сервера.

Чаще всего работа с Git устроена примерно так:

Вы вносите правки в файлы рабочей копии проекта.
Индексируете их, подготавливая к коммиту (здесь Git создает снимки новых правок).
Делаете коммит, и индексированные правки наконец сохраняются в вашем каталоге Git.

Установка Git

Создать свой проект и начать пользоваться Git в нем достаточно просто. Мы будем рассматривать работу в командной строке терминала, потому что там реализован полный набор команд. Вероятно, в будущем вам будет проще воспользоваться встроенными инструментами в крупном приложении (например, в Visual Studio, если вы программист).

Однако командная строка все равно удобна для тонкой настройки и «нестандартных» действий, поэтому полезно представлять себе, как управлять проектом через нее.

Сначала потребуется установить Git на свой компьютер.

Установка в Linux

Для дистрибутивов, похожих на Fedora, RHEL или CentOS, выполните команду dnf:

На Ubuntu и других Debian-подобных систем введите apt:

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

Один из способов установки — воспользоваться Xcode Command Line Tools. В терминале нужно ввести:

И следовать дальнейшим инструкциям.

Если вы пользуетесь Homebrew, запустите команду:

Установка в Windows

Настройка Git

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

Самый удобный способ изменения конфигурации — встроенная утилита git config. Настройки Git имеют три уровня:

Если запускать git config без параметров, будет использоваться локальный уровень, никакие из более глобальных настроек не изменятся.

Всю используемую конфигурацию можно просмотреть так:

Представимся Git, чтобы в рабочих коммитах сохранялось ваше авторство:

В Windows нужно указывать полный путь к файлу. К примеру, для установки Notepad++ нужно запустить подобную команду:

Стоит отметить, что на практике текстовый редактор в Git может и не пригодиться, особенно если вы активно используете стороннее ПО — например, в Visual Studio все текстовые заметки для Git можно писать в отдельном окне. Текстовые редакторы в командной строке отличаются своеобразным управлением, которое потребует от вас отдельного изучения.

Выбор ветки по умолчанию

Итак, наконец можно создать репозиторий в выбранном каталоге командой git init. Основная ветка автоматически будет названа master. Изменить это (в нашем случае задав ветку main) можно так:

Работа в репозитории

Как правило, есть два варианта начать работу с репозиторием Git:

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

Если у вас на компьютере уже есть рабочий проект, но еще не назначен контроль версий, то нужно сначала перейти в каталог проекта.

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

И, наконец, нужно добавить под контроль версий все существующие файлы командой git add . (точка в конце важна!). Можно добавлять и по одному файлу, с помощью git add <имя файла>.

Заодно создадим начальный коммит командой git commit:

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

Клонирование существующего репозитория

Когда вы работаете в команде, разрабатываемые проекты часто размещают на сервере. Это один из самых распространенных сценариев. Вам нужно получить копию проекта последней версии на свой компьютер, чтобы далее вносить в него свой вклад.

Видно, что можно выбрать тип репозитория:

публичный (public) – доступ открыт для любого пользователя, однако права на редактирование выдает владелец проекта;
приватный/скрытый (private) — проект виден только владельцу, другие участники добавляются вручную.

Для нашего примера создадим приватный репозиторий под названием SomeConsoleApp и будем работать с ним далее.

На вашем компьютере в каталоге, куда вы перешли в командной строке, должен появиться каталог SomeConsoleApp, внутри него — каталог .git и все скачанные файлы репозитория последней версии.

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

Правила и периодичность обновления могут быть почти любыми, но хорошим тоном обычно считается сохранять рабочую (или промежуточно завершенную) версию. Важное требование для команд разработчиков — возможность сборки проекта, иначе другие участники команды будут вынуждены тратить время на борьбу с ошибками компиляции.

Сохранение снимков и просмотр статуса проекта

Как упоминалось ранее, часть файлов в рабочем каталоге может и не находиться под контролем версий. За отслеживаемыми файлами «наблюдает» Git, они были как минимум в прошлом снимке состояния проекта. Неотслеживаемыми могут быть, например, вспомогательные файлы в рабочем проекте, если они не зафиксированы в прошлой версии проекта и не готовы к коммиту. Их можно выделить в отдельную категорию для Git, о чем будет рассказано далее.

Сразу после клонирования все файлы проекта будут отслеживаемыми. Отредактировав их и привнеся что-то новое, вы индексируете (stage) и фиксируете (commit) правки, и так для каждой версии проекта.

Проверить состояние файлов в рабочем каталоге можно командой git status. После клонирования консоль выведет примерно такую информацию:

Теперь отредактируем файлы (в этом примере было консольное демо-приложение, созданное с помощью Visual Studio) и сравним статус:

Теперь зафиксируем изменения. В коммит войдут только те файлы, которые вы изменили и добавили командой git add. Остальные будут лишь дополнительными файлами в каталоге проекта.

Стандартный способ — команда git commit, которую мы уже видели раньше. Без дополнительных аргументов она откроет встроенный текстовый редактор, поэтому для простоты рекомендуется добавить аргумент -m и вписать комментарий в кавычках:

Для удаления ненужных файлов из репозитория можно использовать команду git rm <file-name>. Файл также пропадет из рабочего каталога. Выполнить коммит необходимо и в этом случае; до тех пор структура проекта не изменится.

Файл .gitignore

Как упоминалось ранее, в рабочий каталог могут попадать файлы, которые вам бы не хотелось отправлять на сервер. Это и документы с вашими экспериментами или образцами, и автоматически генерируемые части проекта, актуальные только на вашем компьютере. Git может полностью игнорировать их, если создать в рабочем каталоге файл с названием .gitignore и внести в него все имена ненужных файлов и папок.

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

Если прописать такое содержимое файла .gitignore, то репозиторий git будет полностью игнорировать папки /bin и /obj, а также любые файлы с расширениями .pdb и .exe, хранящиеся в вашем рабочем каталоге.

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

Управление удаленными репозиториями

Просмотреть список текущих онлайн-репозиториев можно командой git remote. Добавить другие — с помощью команды git remote add <shortname> <url>, например:

Отправка изменений в удаленный репозиторий (Push)

На вашем компьютере есть проект со внесенными изменениями, но вы хотите поделиться новой версией со всей командой.

Команда для отправки изменений на сервер такова: git push <remote-name> <branch-name>. Если ваша ветка называется master, то команда для отправки коммитов станет такой:

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

Следует к тому же помнить, что в разработке для промежуточных правок часто используется не главная ветка (master), а одна из параллельных (например, Dev). Работая в команде, этому обязательно нужно уделять пристальное внимание.

Получение изменений из репозитория (Pull)

Самый простой и быстрый способ получить изменения с сервера — выполнить команду git pull, которая извлечет (fetch) данные с сервера и попытается встроить/объединить (merge) их с вашей локальной версией проекта.

На этом этапе могут возникать конфликты версий, когда несколько человек поработали над одними и теми же файлами в проекте и сохранили свои изменения. Избежать этого можно, если изолировать части проекта, поручив работу над одной частью только одному человеку. Разумеется, на практике это не всегда выполнимо, поэтому в Git есть инструменты для разрешения конфликтов версий. Они будут рассмотрены далее.

Создание веток и переключение между ними

Создадим две дополнительные ветки Dev и Test (например, одна может пригодиться для процесса разработки, а другая — для запуска в тестирование). Введем команду git branch <branch-name> дважды с разными аргументами:

Ветки созданы, но мы по-прежнему работаем в master. Для переключения на другую нужно выполнить git checkout <branch-name>:

Внесем некоторые изменения в файл README.md и зафиксируем их, чтобы они отразились в ветке Dev:

Для переключения обратно на ветку master нужно снова ввести команду git checkout master. Она не изменялась, а значит, после редактирования проекта ветки разойдутся. Это нормальная ситуация для проектов в Git. Важно только понимать, для каких целей используется каждая из веток, и не забывать вовремя переключаться между ними.

Слияние веток (merge)

Работа над проектами часто ведется в несколько этапов, им могут соответствовать ветки (в нашем примере Dev → Test → master). Отдельные ветки могут создаваться для срочного исправления багов, быстрого добавления временных функций, для делегирования части работы другому отделу и т. д. Предположим, что нужно применить изменения из ветки Dev, внеся их в master. Перейдем в master и выполним команду git merge <source-branch>:

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

Для разрешения конфликтов есть консольная утилита git mergetool. Однако если файл проекта объемный, а общих частей много, пользоваться ей не слишком удобно. Общая рекомендация для таких случаев — пользоваться сторонними инструментами, как и в случае с текстовым редактором для Git.

Дальнейшая работа с проектом из репозитория Git, как правило, повторяется по алгоритму:

Заключение

Мы рассмотрели, как устанавливать и настраивать Git в различных ОС, создавать новые и клонировать существующие репозитории, получать и отправлять новые версии проекта, а также ознакомились с базовыми концепциями ведения веток.

Этой информации обычно хватает для повседневных задач, связанных с хранением рабочих проектов.

Данное краткое руководство демонстрирует основные команды в терминале Bash:

Открытие терминала

Первая задача: открыть терминал сразу в нужном каталоге.

Linux

В Linux достаточно щёлкнуть правой кнопкой мыши на каталоге и выбрать пункт меню Open in Terminal или Открыть в терминале :

В Mac всё немного сложнее, необходимо настроить отображение этого пункта меню в Finder.

Для этого необходимо перейти в Системные настройки , затем пункт меню Клавиатура , в разделе Службы выбрать раздел Файлы и папки и поставить флажок напротив Новый терминал по адресу папки :

После чего при клике правой кнопкой мыши на каталоге появится необходимый пункт меню:

Windows (Git Bash)

В Windows всё достаточно просто - клик правой кнопкой мыши на каталоге и выбор Git Bash Here :

Первоначальная настройка Git

После установки Git первое, что мы сделаем - укажем наши имя и адрес электронной почты. Это важно, потому как этой информацией подписывается каждый коммит (кто сделал изменения и его электронная почта). Для настройки потребуется ввести команды:

Если указана опция --global , настройки применятся глобально, то есть для всех ваших действий в системе Git. Без этой опции настройки применяются локально, для текущего репозитория, и не влияют на глобальные настройки.

Одно окно терминала подразумевает, что вы можете в один момент времени находиться только в одном каталоге, который называется Current Working Directory (текущий каталог), так же как и в одном открытом окне Nautilus , Finder или проводника Windows.

Вы можете выполнять команды относительно текущего каталога или относительно абсолютного пути.

Абсолютный путь - это путь, начинающийся от корня файловой системы. Корень файловой системы обозначается символом / .

Например, в Git Bash (Windows) абсолютный путь для каталога Program Files , будет чаще всего выглядеть следующим образом: /c/Program Files/ .

Для домашнего каталога в Ubuntu (Linux), абсолютный путь будет выглядеть следующим образом: /home/user/ , где user - имя пользователя.

Bash (Git Bash в том числе) используют символ / для разделения каталогов.

Ещё два специальных обозначения помимо корня файловой системы:

. - обозначает текущий каталог;
.. - обозначает родительский каталог.

Важно: в терминале символ ` ` (пробел) является символом, разделяющим команды и опции. Поэтому если в пути есть пробел, то варианта два:

заключать путь в кавычки, то есть "Program Files" ;
использовать символ backslash для экранирования пробела: Program\ Files .

Переменные окружения

Командная оболочка устанавливает ряд переменных, которые выполняют специфические функции. Так, переменная с именем PATH содержит список путей, в которых будет производиться поиск программы, если вы наберёте её название в терминале.

Для вывода содержимого конкретной переменной используется команда echo следующим образом:

Команда printenv позволяет отобразить все переменные окружения:

Видно, что в переменных окружения содержится достаточно много информации о системе.

Автодополнение

В командных оболочках работает автодополнение по клавише Tab :

дополняются имена команд;
дополняются пути.

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

Ключевые команды

В этом разделе будут описаны ключевые команды, необходимые нам для работы. Естественно, список этот далеко не полный.

Текущий рабочий каталог

pwd - сокращение от “Print Working Directory”.

Отображение текущего рабочего каталога:

Смена рабочего каталога

cd - сокращение от “Change Directory”.

Переход в определённый каталог:

path может быть как абсолютным, так и относительным путём.

Например, перейти на каталог выше:

Перейти в подкаталог src :

Если перед путём нет слеша - он трактуется как относительный (относительно текущего каталога).

Листинг каталога

ls - сокращение от “List”.

Отображает листинг (содержимое каталога):

По умолчанию, ls не отображает файлы, начинающиеся с . , например, .gitignore . Для отображения таких файлов нужно использовать флаг -a :

Создание файлов

Для создания файлов используются специальные программы (например, для создания текстовых файлов - текстовые редакторы).

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

nano - простой текстовый редактор.

Для того, чтобы создать файл достаточно ввести команду nano и имя файла:

Откроется редактор следующего вида:

Пункты меню в нижней части вызываются с помощью горячих клавиш, где символ ^ обозначает клавишу Ctrl .

То есть чтобы записать файл и выйти следует последовательно нажать Ctrl + O (запись) и Ctrl + X (выход).

Редактор nano установлен в большинстве Unix-подобных операционных системах и Git Bash.

Редактор Vim (a programmer’s text editor) - профессиональный редактор, позволяющий достичь максимальной производительности при работе с любыми текстовыми файлами. Настолько популярен, что для любой графической среды (IDE, текстовых редакторов вроде VS Code, Atom, Sublime) всегда есть плагин, включающий возможность редактирования кода в режиме “Vim Mode”.

На освоение работы в Vim нужно потратить достаточно много времени, для этого вы можете воспользоваться интерактивным учебником vimtutor :

Мы лишь скажем, что для выхода из этого редактора (если вы всё-таки осмелились его открыть) нужно нажать клавишу Esc , затем ввести команду :q! - это позволит вам закрыть открытый файл без сохранения изменений.

VS Code

В видео-лекциях используется VS Code. В Windows вы можете правой кнопкой открыть каталог сразу в VS Code.

В Mac OS и Linux вы можете открыть терминал по адресу папки и в терминале выполнить команду code . & , которая откроет выбранный вами каталог в этом редакторе.

Если ни то, ни другое у вас не получилось, то просто откройте VS Code и через File - Open откройте нужный каталог.

Создание каталогов

mkdir - сокращения от “Make Directory”.

Позволяет создавать каталоги (создаст каталог tmp в текущем каталоге):

Стоит обратить внимание на поведение при создании нового каталога в текущей директории. После команды mkdir name ваше текущее расположение в терминале не изменится. Для того, чтобы работать внутри созданного каталога, в него требуется перейти командой cd name . Это справедливо и при клонировании удалённого репозитория с помощью команды git clone <repo_url> . Полностью склонированный репозиторий создаст каталог в текущей директории с именем проекта, в который нужно перейти командой cd repo_name .

Я только что выполнил следующие команды на моем Ruby на Rails:

где Git на самом деле магазин этот репозиторий? (Это на моем локальном компьютере, но где?)

он создаст ваш репозиторий в .git папка в текущем каталоге.

чтобы быть немного более полным, Git работает с:

the рабочее дерево (корень которого находится там, где вы сделали git init )
"путь к репозиторию Git" (где .git , в котором будут храниться ревизии всех ваших файлов)

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

если не определено, "путь к репозиторию git" по умолчанию находится в корневом каталоге вашего рабочего дерева (опять же, где вы сделали git init ).

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

но если вы выполняете их в одном из подкаталогов репозитория Git (без указанного пути GIT-DIR или рабочего дерева), Git просто посмотрит в текущий и родительский каталоги, пока не нашел .git , предположим, что это также корневой каталог вашего рабочего дерева и используйте это .git как единственный контейнер для всех ревизий ваших файлов.

Примечание: .git также скрыт в Windows (msysgit).
Вам придется сделать dir /AH чтобы увидеть его.
git 2.9 (июнь 2016) позволяет настроить это.

обратите внимание, что Git 2.18 (Q2 2018) начинает процесс эволюции, как Git сохраняет объекты путем рефакторинга внутренней глобальной структуры данных, чтобы сделать это возможным чтобы открыть несколько репозиториев, поработайте с ними, а затем закройте их.

repository : введите поле хранилища необработанных объектов

синтаксический анализатор необработанных объектов-это слой, который обеспечит доступ к содержимому необработанных объектов,
в то время как код анализатора объектов более высокого уровня будет анализировать необработанные объекты и отслеживает родительство и другие объектные отношения с помощью ' struct object '.
пока добавьте только нижний уровень в структуру репозитория.

если вы находитесь на английском компьютере Windows, путь хранения по умолчанию Git будет C:\Documents and Settings\< current_user>\ , потому что в Windows локальные настройки Git по умолчанию находятся в C:\Documents and Settings\< current_user>\.git и поэтому Git создает отдельную папку для каждого repo/clone at C:\Documents and Settings\< current_user>\ и есть все каталоги клонированного проекта.

например, если вы установите Symfony 2 с

каталог и файл Symfony будут в

в корневом каталоге проекта есть скрытый .git каталог, содержащий конфигурацию, репозиторий и т. д.

Я на Windows и нашел свое местоположение, щелкнув правой кнопкой мыши программу Git Bash в меню "Пуск" и выбрав "Свойства". На вкладке Ярлык отображается значение" Start in:". Для меня это было %HOMEDRIVE%%HOMEPATH% , поэтому я открыл приглашение CMD и набрал echo %HOMEDRIVE%%HOMEPATH% чтобы увидеть реальное расположение.

В a .каталог Git в корне проекта. В отличие от некоторых других систем управления версиями, в частности CVS, ни в одном из подкаталогов нет дополнительных каталогов.

Я также не смог найти свой репозиторий git. Я использую Windows 8 и создал свой репозиторий (по ошибке) под C:\Program Files (x86)\Git . Я мог видеть папку репозитория в bash, но не в cmd или Проводнике Windows.

затем я вспомнил о функции "виртуального магазина" Windows. Моя папка репозитория была фактически создана под C:\Users\<username>\AppData\Local\VirtualStore\Program Files (x86)\Git\<myrepo> и там был мой !

обычно он переходит в папку "Документы" в windows : C:\Users\\Documents\GitHub

GitHub — один из используемых сервисов размещения проектов для совместной разработки. Он поддерживает контроль версий, возможность отслеживания изменений кода, сравнение строк, а также он бесплатен.

В данной статье приведены примеры использования сервиса на компьютере под управлением операционных систем семейства Linux. Мы рассмотрим, как создать проект на локальном компьютере и залить его на сервис с помощью командной строки. Рассмотренные варианты использования git также можно применять на desktop системах, запустив окно терминала.

Установка git

Управление выполняется с помощью приложения git. Если его нет в системе, установку можно выполнить из репозитория.

Если используем CentOS / Red Hat:

yum install git-core

Если используем Ubuntu / Debian:

apt-get install git

Если мы хотим воспользоваться сервисом с компьютера Windows или Mac OS, необходимо скачать и установить desktop версию с официального сайта.

Синтаксис

Команды имеют следующий синтаксис:

* полный перечень опций, команд и аргументов можно получить командой man git.

Создание проекта на локальном компьютере

Инициализируем проект для git:

Мы получим ответ похожий на:

Initialized empty Git repository in /projects/.git/

Это означает, что репозиторий git создан.

Теперь добавим файлы в репозиторий:

* данной командой мы добавили папку и ее содержимое в репозиторий git.

Отправка данных на GitHub

Создание репозитория

Проходим процесс подтверждения, что мы не робот. Затем завершаем несколько шагов регистрации, нажимая Submit. В итоге мы получим письмо на адрес электронной почты, которую указали при регистрации. Необходимо будем подтвердить email, перейдя в письме по кнопке Verify email address.

Создаем репозиторий. Для этого кликаем по иконке профиля и переходим в раздел Your repositories:

И кликаем по кнопке New. В следующем окне даем название репозиторию и нажимаем Create repository:

Мы увидим страницу с путем к репозиторию:

Заливаем проект в репозиторий на GitHub

Добавляем комментарий к нашему проекту:

git commit -m "Очередное изменение проекта" -a

* где Очередное изменение проекта — произвольный комментарий; параметр -a указывает, что комментарий нужно применить ко всем измененным файлам.

Теперь подключаемся к созданному репозиторию:

* где dmosktest — логин, который был указан при регистрации на github, а project1 — название, которое мы задали, когда создавали репозиторий.
* удалить удаленный репозиторий можно командой git remote rm origin.

Закидываем проект на GitHub:

git push origin master

* где master — ветка проекта (веток может быть несколько).

В нашем проекте на GitHub должны появиться файлы проекта:

Получение файлов с GitHub

Для загрузки на компьютер файлов, создаем каталог с проектом и переходим в него:

Проводим начальную настройку локального репозитория:

Подключаемся к удаленному репозиторию:

Скачиваем проект командой:

Клонирование проекта

git clone <репозиторий на GitHub>

Например, использую наш репозиторий:

* данная команда создаст в текущей папке каталог project1 и инициализирует его как локальный репозиторий git. Также загрузит файлы проекта.

Возможные ошибки

* где dmosktest/project1.git — путь к нашему репозиторию.

Причина: проект ни разу не был зафиксирован (закоммичен).

Читайте также: