Работаем с репозиториями в Git

Одна из самых распространенных систем управления версиями – Git. Ее ядро добавляет в систему ряд консольных команд, предназначенных для управления репозиториями. В самих же репозиториях хранятся важные каталоги, конфигурационные файлы, журналы и прочие связанные элементы.

Далее я расскажу, как создать, клонировать и удалить эти репозитории.

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

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

Сначала рассмотрим создание репозитория. Представим, что у вас уже есть папка для хранения файлов, но она еще не находится под контролем Git.

Откройте «Командную строку‎» (Windows) или Терминал (Linux/macOS) и перейдите по пути данной папки.

В Linux выполните команду: ‎

В macOS :

В Windows:

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

Благодаря этой команде создается структура подкаталога со всеми необходимыми файлами. Кстати, все они расположены в подпапке с названием .git . Пока что проект не находится под контролем учета версий, поскольку в него добавлены только нужные элементы для работы Git. Для добавления файлов в репозиторий будем использовать git add. Команда git commit является заключительной:

Теперь у вас есть Git-репозиторий со всеми необходимыми составляющими и отслеживаемыми файлами.

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

Второй вариант создания директории для контроля версий – копирование существующего проекта с другого сервера. Это актуально, когда осуществляется доработка готового проекта или вы желаете внедрить его компоненты в свой. В этом поможет команда git clone , о которой и пойдет речь далее.

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

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

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

При использовании вышеуказанной команды репозиторий клонируется с текущим названием. Если же оно должно отличаться, используйте следующую вариацию команды:

Завершим этот раздел статьи описанием содержимого, которое появляется в консоли при выполнении команды. Данный вывод соответствует успешному клонированию:

Удаление локального Git-репозитория

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

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

Еще один вариант – удаление .gitignore и .gitmodules в случае их наличия. Тогда команда меняет свой вид на:

Остается только убедиться в отсутствии скрытой папки, которая может помешать инсталляции новой. Для этого существует простая команда ls -lah , выполнить которую необходимо с указанием того же каталога.

Только что мы разобрались с основами создания, клонирования и удаления Git-репозитория. Удачи!

Как удалить локальный репозиторий в Git? [дубликат]

этот вопрос уже есть ответ здесь:

Я не могу найти команду. Я попытался погуглить «git’ delete a repository'».

4 ответов:

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

Если вы хотите удалить все (git-данные, код и т. д.), просто удалите весь каталог.

.каталоги git скрыты по умолчанию, поэтому вам нужно будет просмотреть скрытые файлы, чтобы удалить их.

использовать ответ rkj, чтобы избежать бесконечных запросов (и заставить команду рекурсивно), введите в командной строке в папке проекта следующее:

или удалить .gitignore и .gitmodules if any (via @aragaer):

затем из той же папки ex-repository, чтобы увидеть, если скрытая папка .ГИТ все еще там:

если это не так, то поздравляю, вы удалили свое локальное РЕПО git, но не дистанционный, если он у вас есть. Вы можете удалить репозиторий GitHub на своем сайте (github.com).

для просмотра скрытых папок в Finder (Mac OS X) выполните следующие две команды в окне терминала:

в каталог удалить каталог с именем .ГИТ и это все :). На Un*x он скрыт, поэтому вы можете не видеть его из файлового браузера, но

следует сделать трюк.

правильно, если вы находитесь на mac(unix), вы не увидите .git в finder (файловый браузер). Вы можете следовать инструкциям выше, чтобы удалить, и есть команды git, которые позволяют вам также удалять файлы(с ними иногда трудно работать и учиться, например: при создании команды «git rm-r» вам может быть предложено с помощью a .мерзавец/ не нашли. Вот это команда, технические характеристики ГИТ:

использование: git rm [options] [ — ].

когда я должен был сделать это, удаление объекты и ссылки не имели значения. После того, как я удалил другие файлы .мерзавец, я инициализации репозитория Git с помощью Git инициализации и создается пустой РЕПО.

How do I delete a local repository in git? [duplicate]

I can’t find the command. I tried Googling «git ‘delete a repository'».

4 Answers 4

Delete the .git directory in the root-directory of your repository if you only want to delete the git-related information (branches, versions).

If you want to delete everything (git-data, code, etc), just delete the whole directory.

.git directories are hidden by default, so you’ll need to be able to view hidden files to delete it.

To piggyback on rkj’s answer, to avoid endless prompts (and force the command recursively), enter the following into the command line, within the project folder:

Or to delete .gitignore and .gitmodules if any (via @aragaer):

Then from the same ex-repository folder, to see if hidden folder .git is still there:

If it’s not, then congratulations, you’ve deleted your local git repo, but not a remote one if you had it. You can delete GitHub repo on their site (github.com).

To view hidden folders in Finder (Mac OS X) execute these two commands in your terminal window:

In the repository directory you remove the directory named .git and that’s all :). On Un*x it is hidden, so you might not see it from file browser, but

should do the trick.

That’s right, if you’re on a mac(unix) you won’t see .git in finder(the file browser). You can follow the directions above to delete and there are git commands that allow you to delete files as well(they are sometimes difficult to work with and learn, for example: on making a ‘git rm -r ‘ command you might be prompted with a .git/ not found. Here is the git command specs:

usage: git rm [options] [—] .

When I had to do this, deleting the objects and refs didn’t matter. After I deleted the other files in the .git, I initialized a git repo with ‘git init’ and it created an empty repo.

Гид по Git

Что такое 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, например:

Мы будем пользоваться программой GitHub Desktop, которую можно скачать отсюда. Если вы уже знакомы с Git, то вы можете выбрать любую программу или пользоваться командной строкой — это не принципиально. Стоит отметить, что пользоваться командной строкой гораздо сложнее чем графическим интерфейсом, поэтому она больше подходит продвинутым пользователям.

• Git — разновидность системы контроля версий (самая популярная). Его можно скачать и установить, далее использовать через командную строку.
• Можно использовать графический интерфейс для работы с Git. При этом скачивать и устанавливать сам Git отдельно не нужно, он обычно идет в комплекте с графическим интерфейсом (но не во всех GUI).
• Репозиторий — это место где мы храним наш код проекта и всю информацию по файлам, их изменения и т.д. Репозиторий должен где-то хранится, чтобы у всех был доступ к нему и они могли видеть изменения. Его можно хранить и на домашнем компьютере, но не всегда удобно держать компьютер включенным целыми сутками, поэтому используют хостинги для репозиториев. Одними из самых известных являются GitHub и GitLab.

GitHub

GitHub — крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки. Веб-сервис основан на системе контроля версий Git и разработан на Ruby on Rails и Erlang компанией GitHub, Inc. Так как мы будем хранить на нём наши репозитории, поэтому мы и выбрали GitHub Desktop, т.к. он разрабатывался специально для максимальной интеграции и упрощения работы с GitHub.

Для работы нам нужен аккаунт. Чтобы зарегистрироваться, идём сюда, выбираем имя пользователя и пароль, и готово! Теперь у вас есть собственная страничка: https://github.com/username, где username — имя пользователя, которое вы указали.

После регистрации вы попадете на приветственную страницу, где сначала нужно, ничего не меняя, нажать зеленую кнопку Continue, а потом Skip this step (но если не лень, можно заполнить опросник и нажать Submit).

Далее подтвердите свой аккаунт на указанной ранее почте и все, вы готовы к работе.

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

Создать репозиторий можно двумя способами:

Сначала создадим через сайт. Чтобы создать репозиторий, нажимаем кнопку Start a project и выбираем название. Оно может быть любым, но должно отражать суть того, что лежит внутри, например, “homeworks”. Впрочем, GitHub предлагает более креативные варианты. Также в специальном поле можно добавить описание. Для публичных репозиториев хорошей практикой является заполнение всех полей, чтобы другие пользователи (или люди, проходящие по ссылке из резюме) могли сразу понять, о чём конкретно данный репозиторий.

У нас есть выбор между Public и Private. Разница между ними в том, что публичные репозиторий видно в поиске, в вашем профиле, любой может просмотреть весь код и предложить свои исправления (pull request, пулл-реквест, ПР, пи-ар). Приватный репозиторий доступен только определённым пользователям, хозяин репозитория сам выбирает, кто видит репозиторий и кто может делать коммиты. На обычном (бесплатном) аккаунте возможность создавать приватные репозитории обычно ограничена несколькими.

Далее у нас есть возможность инициализировать репозиторий с файлом README. В нем может быть отображена информация о репозитории, о его использовании, установке файлов и т.д. Описание происходит в формате Markdown. Также за этой галочкой скрывается команда init, которая превращает пустую папку в Git-проект.

Также стоит упомянуть про файл .gitignore и LICENSE. Файл .gitignore нужен для того, чтобы в репозиторий не попадали разные временные файлы или сборки, например, при сборке проекта в Visual Studio создается множество временных бинарных файлов, которые при каждом изменении исходного кода программы, будут другими, поэтому для репозитория (хранилища исходного кода) это по факту мусор. Поэтому в этом файле прописано, что определенные папки и файлы не будут учитываться при подготовке коммитов и, следовательно, загрузке в удалённый репозиторий. При создании репозитория можно выбрать уже заранее созданные файлы под язык программирования или среду разработки. Также его можно прописать или дополнить и указать какие файлы включить или убрать из репозитория. Файл LICENSE указывает на то, по какой лицензии распространяется код. Про каждую лицензию можно почитать отдельно и в основном они отличаются тем, что можно делать с кодом: продавать, распространять, изменять и т.д. При создании нашего репозитория можно либо выбрать эти файлы, либо оставить их пустыми.

Популярные лицензии (в сторону уменьшения количества ограничений):

• GNU GPL;
• MIT;
• Unlicense;
• WTFPL (do whatever you want public license).

Текст лицензии понадобится скопировать в файл LICENSE.

Далее нажимаем на зеленую кнопку Create repository. Вы увидите список файлов в своем репозитории (пока это только автоматически сгенерированный файл README с описанием проекта) и содержание README, если он есть, а также файлы .gitignore и LICENSE, если они создавались. Ссылка на репозиторий будет выглядеть так: https://github.com/username/your_repo_name.git .

Клонируем репозиторий

Теперь нам нужно сделать локальную копию нашего удалённого репозитория. Мы снова воспользуемся кнопкой Clone or download, но теперь используем полную ссылку на репозиторий; эту ссылку нужно скопировать (Если у вас окошко выглядит не так как на картинке, то нажмите в окне на ссылку справа сверху Use HTTPS).

Для дальнеших шагов нам потребуется скачать и установить GitHub Desktop. После установки и первого запуска, возможно, потребуется войти в ваш аккаунт GitHub. Далее выбираем Clone repository или через File, а затем уже Clone repository.

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

Тут мы выбираем из списка репозиторий:

Тут мы вставляем ссылку на репозиторий:

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

Добавляем и изменяем файлы

Теперь давайте создадим в нашей папке новый текстовый документ с сообщением “Hello world!”.

Если мы откроем GitHub Desktop, мы увидим что наш файл увидела система и пометила как добавление новгго файла, отметив зеленым плюсом. Справа отобразив что именно сделали с файлом: зеленым выделены добавленные фрагменты.

Теперь мы готовы сделать свой первый коммит (commit). По факту это фраза означает внесения изменения в текущую ветку в локальном репозитории. Чтобы это сделать, нужно написать краткое сообщение, отражающее суть изменений, чтобы потом было проще в них ориентироваться. В данном случае мы добавили новый текстовый файл (сообщение может быть на любом языке, необязательно на английском). Github сам нам подсказал название коммита. Так же мы можем добавить описание изменений, чтобы другим пользователям было проще.

Когда мы готовы сделать коммит, нажимаем кнопку Commit to master. Это означает сделать коммит в локальную ветку master, про сами ветки расскажем чуть позже. Но мы сделали только коммит, теперь нужно чтобы изменились файлы в удаленном репозитории, то есть синхронизировать локальную и удалённую ветки master. Для этого нажимаем кнопку сверху Push origin.

Если все прошло успешно, и изменения запушились в удаленный репозиторий, то, обновив его страницу на GitHub, мы увидим новый файл hello world.txt.

Поверьте, адекватные описания коммитов — это очень важно!

Теперь давайте создадим файл на GitHub и скопируем его в локальный репозиторий. Нажимаем кнопку Create new file и называем его newfile.

Осталось “прописать” коммит и сделать его, нажав Commit new file:

Откроем GitHub Desktop и обнаружим, что система сама определила, что произошел внешний коммит и наши файлы нужно обновить. Если изменений не видно, нажмите F5 или перезапустите приложение. Нажмём на Pull origin и скачаем файлы в свой локальный репозиторий:

Верните всё назад!

Любой коммит можно отменить, щёлкнув по нему правой кнопкой мыши и выбрав Revert this commit. Так, если мы проведём эту процедуру с последним коммитом и запушим изменения на GitHub, то файл goose там исчезнет. В истории изменений данное действие будет видно, как ещё коммит, отменяющий изменения выбранного (анти-коммит). Чтобы посмотреть историю коммитов, нужно нажать на History.

Откатывать коммиты можно также через веб-интерфейс (на сайте GitHub).

Клонирование чужих репозиториев

Клонировать можно не только свои репозитории, но и чужие. Для этого найдите нужный репозиторий в поиске на github. И выбираем Clone or Download.

Далее делаем все как и при копировании своего репозитория, только в данном случае доступен вариант клонировать только по ссылке.

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

Fork репозитория

Fork (форк) репозитория это возможность скопировать чужой репозитория на свой аккаунт и вносить любые изменения в него, без изменения оригинального репозитория. Можно сделать форк любого доступного репозитория. При создании форка нас спросят в какой аккаунт мы хотим его добавить.

В чем же отличие от клонирования репозитория? При клонировании мы только используем файлы оригинального репозитория и при создании коммита с какими-то изменениями, GitHub Desktop скажет нам, что у нас нет доступа на запись и сам предложит сделать форк. (Если доступ к этому репозиторию у нас есть, то сделать коммит мы сможем.) А если мы сделали форк, то изменения уйдут в нашу копию в нашем аккаунте.

Fork может быть полезен при разработки открытого ПО, например, мы сделали форк алгоритма сжатия, в нем мы изменили функцию сжатия и теперь алгоримт сжимает в 10 раз лучше. Мы можем сделать Pull request, т.е. запросить у хозяина оригинального репозитория с алгоритмом сжатия, интегрировать наши изменения в его репозиторий.

Ветки

В git есть понятие branch (ветка). Ветка — это покоммитный “путь” до некоторого коммита, называемого “концом” (tip) ветки. Мы можем иметь несколько независимых веток при работе. Коммит делается в конкретную ветку, по умолчанию это ветка master. Создать новую ветку можно как на сайте, так и в приложении GitHub Desktop. Для этого нужно выбрать вкладку Current branch и нажать на New branch:

Выбираем имя и в эту ветку пойдет вся информация с ветки master (точнее, новая ветка будет “смотреть” на тот же коммит, что и master), в том числе и все файлы:

И теперь мы можем переключать ветки и вносить изменения в конкретную ветку, не затрагивая основную, в данном случае master. Например, мы удалим один файл, и изменим другой. Удалённый файл будет отмечен красным минусом, а изменённый — желтой точкой. При этом справа видно, что мы работаем в ветке Features.

Делаем коммит в новую ветку и смотрим, что произошло. Как мы видим, в ветке master всё осталось, как прежде. Она по прежнему указывает на тот же коммит, что и раньше.

А вот в ветке Features удалённого файла уже нет. Переключить ветку можно, нажав на кнопку Branch с названием ветки:

Ветки удобно использовать для добавления новых функция, что они не ломали рабочий код до новой функции. После разработки ветку можно объединить с master (merge, смёржить, слить) сделав так называемый Pull request.

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

Как говорилось ранее, новый репозиторий можно создать и из самого приложения. Для этого идем в File/New repository:

Указываем все данные аналогично тому как создавали на сайте и нажимаем Create repository:

Не забудьте нажать на Publish repository, чтобы он ушёл на сайт.

Далее еще раз укажите имя уже на сайте и всё.