Работа с распределенной системой контроля версий git на примере github

Введение¶

Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

git commit –a –m ”new comment here”

Коммитится только то, что проиндексировано. Индексирование происходит функцией (она и добавляет файлы и индексирует их).

Коммит идет не сразу: файлы, которые находятся под присмотром ГИТ необходимо проиндексировать (то есть если нам нужно сделать коммит для 1-файла, то мы помещаем его в индекс и закоммитится только он). С помощью ключа мы индексируем ВСЕ файлы и, соответственно, сразу выполняем коммит (например,

).

—amend

Эта команда берет область индексирования (add) и включает в коммит всю обнаруженную там информаци. Например,

Второй коммит заменит результат первого и в итоге останется 1 коммит

Работаем с GitHub

Зарегистрируйтесь на GitHub. Создайте репозиторий.

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

Эта команда принимает имя удаленного репозитория и его URL. В нашем случае это https://github.com/try-git/try_git.git

Выполняем команду с указанными аргументами:

Где — имя удаленного репозитория.

Плюсы и минусы bitbucket.org и GitHub

На bitbucket.org можно создавать неограниченное количество приватных репозиториев (плата взимается, если к репо привязываются более 5 пользователей). На GitHub большинство проектов open source, также для приватного репо уже приходится платить – даже для 1-го пользователя. Для своих проектов я рекомендую все же использовать bitbucket.org.

Процесс разработки:

Переходим на боевой сервере по SSH и стягиваем (PULL) с GitHub, при этом разработка идет на ПК разработчика (может быть более 1-го разработчика, с локального ПК делаем PUSH на GitHub).

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

Ключ показывает путь к удаленному репо.

Подробно о любой команде можно узнать:

Коммитим и пушим на GitHub (global настройки matching и simple)

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

То по команде произойдет следующее: если на боевом репо есть 2 ветки, которые соответствуют 2-м локальным веткам, то на удаленный репо протолкнутся эти 2 ветки.

В данном случае протолкнется лишь текущая ветка.

8 ответов

Лучший ответ

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

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

Или, может быть, даже назовите старую :

Затем, когда вы захотите получить изменения из , вы можете:

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

131

Community
23 Май 2017 в 11:54

GitHub: чужой репозиторий и ваш собственный репозиторий

Я буду называть чужой репозиторий другим репозиторием .

  1. Создайте новый репозиторий на github.com. (это ваш репозиторий )

    • Дайте ему то же имя, что и другой репозиторий .
    • Не инициализируйте его с помощью README, .gitignore или лицензии.
  2. Клонируйте другой репозиторий на свой локальный компьютер. (если вы еще этого не сделали)

    git clone https://github.com/other-account/other-repository.git

  3. Переименуйте текущий локальный репозиторий » origin » в » upstream «.

    git remote rename origin upstream

  4. Дайте локальному репозиторию » origin «, который указывает на ваш репозиторий .

    git remote add origin https://github.com/your-account/your-repository.git

  5. Переместите локальный репозиторий в ваш репозиторий на github.

Теперь ‘ origin ‘ указывает на ваш репозиторий , а ‘ upstream ‘ указывает на другой репозиторий .

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

64

Derek Soike
19 Мар 2018 в 16:52

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

  1. перейдите в свою клонированную папку репо rm -rf .git
  2. повторно инициализируйте его, а затем добавьте свой пульт и сделайте первое нажатие.

13

MAOXU
14 Дек 2017 в 04:32

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

Тогда вы можете позвонить:

Чтобы заменить установленный по умолчанию пульт «origin», вы можете запустить следующее:

8

bmorgan21
13 Авг 2013 в 03:50

Я думаю, что «самый вежливый способ» сделать это:

  1. Разветвите исходное репо в своей учетной записи GitHub
  2. Проверьте новую ветку для ваших изменений (на случай, если вы не сделали этого раньше)
  3. Добавьте новый пульт для вашего локального репозитория:
  4. Отправьте свою новую красивую ветку в репозиторий github:

Таким образом, у вас будет репо, разветвленное на исходное, а ваши изменения будут внесены в отдельную ветку. Это будет проще, если вы хотите отправить запрос на перенос в исходное репо.

7

llekn
3 Апр 2017 в 18:19

Взято из Git перемещает все в новое происхождение

В основном вам нужно связать новое репо с вашей папкой

1

Community
23 Май 2017 в 12:10

У меня была аналогичная ситуация, но в моем случае мне просто нужно было сделать, как предлагалось, но с https , например:

1

T J
25 Мар 2016 в 06:12

После клонирования скопируйте файлы из их папки в новую и начните заново с помощью git init,

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

Или вы можете удалить текущий источник репозитория с помощью команды git remote remove origin.

1

F. X. Blankson
16 Авг 2020 в 17:23

git diff, git diff HEAD

Команда показывает не все изменения, сделанные с момента последней фиксации состояния, а только те, которые еще не проиндексированы.

Команда покажет проиндексированные изменения

Ой! Похоже, кто-то еще вносил изменения в наш проект! Давайте посмотрим, что изменилось, с нашего последнего коммита, с помощью команды

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

Еще один полезный вариант использования — просмотр изменения, которые уже были помещены в промежуточную область. Запомните! В этой области находятся файлы, которые git готов(!) закоммитить.

Коммитим изменения

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

git commit -m "Мой первый коммит"

Указывайте сообщение, которое будет содержать полезную информацию, так как они помогают понять, что же именно было изменено в рамках данного коммита. Избегайте каких-то общих сообщений, типа “Правил баги”. Если у вас есть баг-трекер, вы можете указать сообщение типа “Поправлен баг #123”. Хорошая практика — указывать в сообщении имя ветки или улучшения. Например, “Управление активами — добавлена возможность генерировать PDF на основе актива” — понятное и доходчивое сообщение.

Git определяет коммит длинным шестнадцатеричным номером. Обычно, нет необходимости копировать всю строку, первых 5-6 символов достаточно для идентификации конкретного коммита. По скриншоту видно, что наш коммит идентифицируется числом .

Начальная конфигуация

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

mkdir my_git_project
cd my_git_project

Первым делом надо инициализировать Git-репозитарий в директории проекта. Сделать это можно командой , которая создает директорию со всей информацией о вашем проекте.

git init

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

git config --global user.name 'Shaumik'
git config --global user.email '[email protected]'
git config --global color.ui 'auto'

Стоит отметить, что если вы не укажете ваш адрес и имя, то вместо них будут использоваться значения по умолчанию. В нашем случае значениями по умолчанию будут donny и donny@ubuntu.

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

5 последних уроков рубрики «Разное»

  • Выбрать хороший хостинг для своего сайта достаточно сложная задача. Особенно сейчас, когда на рынке услуг хостинга действует несколько сотен игроков с очень привлекательными предложениями. Хорошим вариантом является лидер рейтинга Хостинг Ниндзя — Макхост.

  • Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

    Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.

  • Создание вебсайта — процесс трудоёмкий, требующий слаженного взаимодействия между заказчиком и исполнителем, а также между всеми членами коллектива, вовлечёнными в проект. И в этом очень хорошее подспорье окажет онлайн платформа Wrike.

  • Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Где должен находиться этот файл

Файл может находиться в корне проекта или любом подкаталоге.

Либо можно задать глобальный файл gitignore, таким образом:

$ git config --global core.excludesfile ~/.gitignore_global

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

Примеры содержимого файла

# строки начинающиеся на # - это комментарии, они не учитываются

# Исключить все файлы с расширение .a
*.a

# Но отслеживать файл lib.a даже если он подпадает под исключение выше
!lib.a

# Исключить файл TODO в корневом каталоге, но не файл в subdir/TODO
/TODO

# Игнорировать все файлы в каталоге build/
build/

# Игнорировать файл doc/notes.txt, но не файл doc/server/arch.txt
doc/*.txt

# Игнорировать все .txt файлы в каталоге doc/
doc/**/*.txt

Работаем с GitHub

Зарегистрируйтесь на GitHub. Создайте репозиторий.

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

Эта команда принимает имя удаленного репозитория и его URL. В нашем случае это https://github.com/try-git/try_git.git

Выполняем команду с указанными аргументами:

Где — имя удаленного репозитория.

Плюсы и минусы bitbucket.org и GitHub

На bitbucket.org можно создавать неограниченное количество приватных репозиториев (плата взимается, если к репо привязываются более 5 пользователей). На GitHub большинство проектов open source, также для приватного репо уже приходится платить – даже для 1-го пользователя. Для своих проектов я рекомендую все же использовать bitbucket.org.

Процесс разработки:

Переходим на боевой сервере по SSH и стягиваем (PULL) с GitHub, при этом разработка идет на ПК разработчика (может быть более 1-го разработчика, с локального ПК делаем PUSH на GitHub).

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

Ключ показывает путь к удаленному репо.

Подробно о любой команде можно узнать:

Коммитим и пушим на GitHub (global настройки matching и simple)

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

То по команде произойдет следующее: если на боевом репо есть 2 ветки, которые соответствуют 2-м локальным веткам, то на удаленный репо протолкнутся эти 2 ветки.

В данном случае протолкнется лишь текущая ветка.

git log (информация о последних коммитах)

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

покажет список последних коммитов и их хеши SHA1.

На самом верху мы видим самый последний коммит.
Функция очень богатая – позволяет смотреть, что было до и что было после, у git хорошая помощь (faq), чтобы просмотреть все возможности можно воспользоваться командой:

Например, мы можем выводить историю в более удобном формате:

– короткий код самого коммита; – автор; – когда был сделан; — комментарий.

Ограничиваем коммиты по времени:

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

используется для получения краткой статистики по каждому коммиту.

добавляет графику с историей ветвлений и слияний

Переименование файлов в репозитории Git

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

Будучи важной частью Git, мы должны научиться переименовывать файл в репозитории Git

Как переименовать файл с помощью Git

Поскольку у нас нет никакого файла в репозитории Git, создайте новый файл, например toolsqa.txt. После этого вы должны проверить состояние git. Подтвердите, что это чистый каталог, как мы уже делали выше. Как только все будет сделано, введите следующую команду и нажмите клавишу enter:

git mv <original_file_name> <new_file_name>

Проверьте состояние репозитория через git status.

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

 Как переименовать файл вне Git

В этом разделе мы рассмотрим, как Git реагирует, когда файл переименовывается, не сообщая об этом Git. Используйте ту же команду без “git”.

Введите следующую команду в Git Bash и нажмите клавишу enter:

mv <original_file_name> <new_file_name>

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

Здесь очень важно заметить реакцию Git. Git удалил файл под названием renaming.txt и добавил новый файл toolsqa.txt

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

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

Выделенная строка гласит: rename renaming.txt -> toolsqa.txt (100%)

Означает, что предыдущий файл и новый файл абсолютно одинаковы и нет никакой разницы. Это называется уровнем доверия. Если бы вы внесли какие-либо изменения в новый файл, а затем зафиксировали эти изменения, он показал бы менее 100%.

Для чего нужен .gitignore

Файл .gitignore используется для того, чтобы определить, какие файлы и папки не нужно добавлять в git репозиторий.

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

git add path/to/file

Однако это было бы очень трудоемко. Гораздо проще использовать команду:

git add .

Которая добавит все файлы в каталоге проекта.

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

Тут нам и нужен .gitignore. Вам нужно его самим создать и разместить в корне проекта либо нужной подпапке.

Команда git rm

Для удаления файлов в системе Git, как уже упоминалось выше, имеется специальная команда . Ее отличие от обычной консольной команды (в том же Linux) заключается в особенности самой системы Git.

Как хорошо известно, в системе Git файл может одновременно существовать в трех ипостасях: в области “Working Directory”, в области “Staging Area”, в области “Repository”. Удаление файла из области “Working Directory” не приведет к его удалению из областей “Staging Area” и “Repository”.

Поэтому, чтобы удалить файл, нужно (в идеале) выполнить три команды подряд для удаления файла из Рабочей области “Working Directory”, затем из области индекса “Staging Area” и потом из области репозитория “Repository”:

Команда является ни чем иным, как “вшитым” в Git сокращением двух первых команд:

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

Удалим его командой :

Видим, что файл был сразу удален из двух областей: рабочего каталога “Working Directory” и области индексации “Staging Area”. Но в репозитории файл все же остался, о чем говорит вывод команды .

Любой последующий commit зафиксирует удаление этого файла:

git diff, git diff HEAD

Команда показывает не все изменения, сделанные с момента последней фиксации состояния, а только те, которые еще не проиндексированы.

Команда покажет проиндексированные изменения

Ой! Похоже, кто-то еще вносил изменения в наш проект! Давайте посмотрим, что изменилось, с нашего последнего коммита, с помощью команды

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

Еще один полезный вариант использования — просмотр изменения, которые уже были помещены в промежуточную область. Запомните! В этой области находятся файлы, которые git готов(!) закоммитить.

Дальнейшие коммиты

Давайте изменим несколько файлов после того, как мы их закоммитили. После того, как мы их изменили, сообщит о том, что у нас есть измененные файлы.

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

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

git add -u

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

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

git commit

Git tools для продвинутых разработчиков

Git tools для продвинутых разработчиков

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

В этом руководстве объясняется, как изменить сообщение о самых последних или старых коммитах Git.

Не задний коммит

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

  1. Перейдите в каталог хранилища в вашем терминале.

    Выполните следующую команду, чтобы изменить (изменить) сообщение о последнем коммите:

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

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

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

Задний коммит

Измененный (измененный) коммит — это новый объект с другим SHA-1. Предыдущий коммит больше не будет существовать в текущей ветке.

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

  1. Перейдите в хранилище.

    Исправьте сообщение о последнем введенном коммите:

    Принудительно нажмите, чтобы обновить историю удаленного хранилища:

Изменение старого или нескольких коммитов

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

  1. Перейдите в хранилище, содержащее сообщение фиксации, которое вы хотите изменить.

    Введите , где — количество коммитов, на которых необходимо выполнить ребазинг. Например, если вы хотите изменить 4-й и 5-й последние коммиты, введите:

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

    Перейдите к строкам коммит-сообщения, которое вы хотите изменить, и замените на :

    Сохраните изменения и закройте редактор.

    Для каждого выбранного коммита открывается новое окно текстового редактора. Измените сообщение о коммите, сохраните файл и закройте редактор.

    Принудительно отправить изменения в удаленный репозиторий:

Вывод

Чтобы изменить самое последнее сообщение о , используйте команду а для изменения более старого или многократного сообщения о используйте

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

В этой статье будет показано, как стирать, настраивать, изменять или редактировать «Начать» название экрана запуска Windows 8 с помощью Resource Hacker.

Узнайте, как изменить размер или изменить размер миниатюр панели задач в Windows Vista / 7/8 через взлом реестра. Если вы обнаружите, что размер миниатюр слишком мал, легко увеличивайте его размер.

Git remotes — это указатели на версии репозитория, которые обычно хранятся на других серверах. В этом руководстве объясняется, как изменить URL-адрес пульта Git.

Добавляем файлы в Git

На этом этапе Git не следит ни за одним из наших файлов. Необходимо специально добавить файлы в Git, чтобы это происходило. Для этого воспользуемся командой add.

git add my_file

Проверив статус репозитария видим, что один из файлов уже добавлен в него.

Чтобы добавить несколько файлов, используем следующее (заметьте, что первый файл мы добавили ранее, так что добавляем только оставшиеся два).

git add myfile2 myfile3

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

Удаление файлов из git репозитория и из stage

Удаление файла из stage

Вначале разберемся со stage. Создадим ещё один файл.

> touch main.c

“Отправим” файл main.c в stage.

> git add main.c

Внесем изменения в README.md.

> echo "# README" > README.md

Информацию об этом также отправим в stage.

> git add README.md

Посмотрим на состояние stage.

> git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   README.md
        new file:   main.c

Если нам необходимо убрать из stage, какой-то из этих файлов (main.c или README.md), то для этого можно воспользоваться командой git –rm cashed <filename>, сделаем это для файла main.c.

> git rm --cached main.c
rm 'main.c'

Теперь посмотрим на состояние рабочей директории и stage.

> git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        main.c

Видно, что изменения в файле README.md готовы для коммита, а вот файл main.c перешел в состояние – неотслеживаемый. Отправим main.c в stage и, после этого, сделаем коммит в репозиторий.

> git add main.c
> git commit -m "add main.c and do some changes in README.md"
 add main.c and do some changes in README.md
 2 files changed, 1 insertion(+)
 create mode 100644 main.c

Удаление файлов из git репозитория

Удалить файл из репозитория можно двумя способами: первый – удалить его из рабочей директории и уведомить об этом git; второй – воспользоваться средствами git. Начнем с первого способа. Для начала посмотрим, какие файлы у нас хранятся в репозитории.

> git ls-tree master
100644 blob 7e59600739c96546163833214c36459e324bad0a    README.md
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    main.c

Удалим файл main.c из рабочей директории.

> rm main.c
> ls
README.md

Уведомим об этом систему git.

> git rm main.c
rm 'main.c'

Вместо команды git rm можно использовать git add, но само слово add в данном случае будет звучать несколько неоднозначно, поэтому лучше использовать rm. На данном этапе еще можно вернуть все назад с помощью команды git checkout — <filename>, в результате, в нашу рабочую директорию будет скопирован файл из репозитория. Создадим коммит, фиксирующий удаление файла.

> git commit -m "remove main.c"
 remove main.c
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 main.c

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

> git ls-tree master
100644 blob 7e59600739c96546163833214c36459e324bad0a    README.md

Второй способ – это сразу использовать команду git rm без предварительного удаления файла из директории. Вновь создадим файл main.c и добавим его в репозиторий.

> touch main.c
> git add main.c
> git commit -m "add main.c file"
 add main.c file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 main.c
> git ls-tree master
100644 blob 7e59600739c96546163833214c36459e324bad0a    README.md
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    main.c

Удалим файл из репозитория.

> git rm main.c
rm 'main.c'

> git commit -m "deleted: main.c file"
 deleted: main.c file
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 main.c

Файла main.c больше нет в репозитории.

> git ls-tree master
100644 blob 7e59600739c96546163833214c36459e324bad0a    README.md

Его также нет и в рабочем каталоге.

> ls
README.md

Удалите файл README.md из репозитория самостоятельно.

Как удалить локальный репозиторий Git и удалить репозиторий удаленного репозитория Git на GitHub

http-equiv=»Content-Type» content=»text/html;charset=UTF-8″>style=»clear:both;»>

1. Удалите локальный склад Git.

Основной принцип удаления локального хранилища Git заключается в удалении скрытой папки «.git» в корневом каталоге «локального хранилища Git».

(1) Метод 1. Вручную удалите скрытую папку «.git» в корневом каталоге в «Git Local Warehouse» (как показано на рисунке выше).

(2) Метод 2: вызовите командную строку в каталоге локального хранилища, чтобы удалить папку .git в корневом каталоге, введите

(3) Проверьте, успешно ли удален локальный склад: введите каталог хранилища в Gitbash, если в конце каталога нет «(мастер)», это означает, что локальный склад был успешно удален.

2. Удалите удаленный репозиторий Git на GitHub.

(1) Введите «rm -rf + адрес хранилища github» в командной строке, например

Значение команды: удалить удаленный склад Git «LearningGit» из «индивидуального пользователя jedlee6» в сообществе Github

Подробная команда: rm полное имя: rm — это команда remove, -rf — это параметр рекурсивно и принудительно

Команда remove: удалить один или несколько файлов или каталогов в каталоге

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

Принудительный вариант: игнорировать файлы, которые не существуют, никогда не выдавать подсказку «файл не существует» (удалить файл, если файл не существует, появится сообщение «файл не существует»)

Option-rf: при использовании нескольких параметров команды ввод можно упростить. Например, команда ls -r -f сокращенно обозначается ls -rf. Таким образом, опция -rf представляет собой комбинацию опции -r и опции -f. Опция -rf function: удалить все файлы в текущем каталоге, эта команда очень опасна, и ее следует избегать

(2) Зайдите в Настройки на соответствующем складе github, проведите пальцем вниз по странице настроек, найдите последний подпункт «Зона опасности», удалите библиотеку

Интеллектуальная рекомендация

1. Для реальных сигналов (для понимания): A (ω) является соотношением амплитуды выходного сигнала и амплитуды входного сигнала, называемого частотой амплитуды. Φ (ω) — это разница межд…

Один. вести Многие люди задавали некоторые вопросы о создании проекта Flex + LCDS (FDS) в сообщениях и группах. Из-за операции ее трудно четко объяснить, поэтому я написал простой учебник (я обещал эт…

package com.example.phonehttp; import android.os.Bundle; import android.os.Handler; import android.app.Activity; import android.widget.ScrollView; import android.widget.TextView; public class MainActi…

Он предназначен для реализации подкласса того же родительского класса с родительским классом. Полиморфизм Один и тот же ссылочный тип использует разные экземпляры для выполнения разных операций; Идея …

тема: Объедините два упорядоченных слоя в новый заказанный список и возврат. Новый список состоит из всех узлов двух связанных списков, данных сплавным. Пример: Анализ: два связанных списка состоит в …

Вам также может понравиться

D. Самая ценная строка Пример ввода 2 2 aa aaa 2 b c Образец вывода aaa c На самом деле, будучи задетым этим вопросом, вы должны быть осторожны. После инвертирования строки, если две строки имеют один…

Given a 2D integer matrix M representing the gray scale of an image, you need to design a smoother to make the gray scale of each cell becomes the average gray scale (rounding down) of all the 8 surro…

calc () может быть очень незнакомым для всех, и трудно поверить, что calc () является частью CSS. Поскольку он выглядит как функция, почему он появляется в CSS, поскольку это функция? Этот момент такж…

Основываясь на дереве регрессии, сформированном CART, а также на предварительной и последующей обрезке дерева, код выглядит следующим образом:…

Откат Обновление в режиме онлайн с версии Centos (CentOS Linux версии 7.3.1611 (Core) до CentOS Linux версии 7.5.1804 (Core)) # ошибка соединения yum-ssh после обновления yexpected key exchange group …

Основы работы с удаленным репозиторием¶

git clone — создание копии (удаленного) репозитория

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

Клонируем репозиторий, используя протокол http:

git clone http://user@somehost:port/~user/repository/project.git

Клонируем репозиторий с той же машины в директорию :

git clone /home/username/project myrepo

Клонируем репозиторий, используя безопасный протокол ssh:

git clone ssh://user@somehost:port/~user/repository

У git имеется и собственный протокол:

git clone git://user@somehost:port/~user/repository/project.git/

Импортируем svn репозиторий, используя протокол http:

git svn clone -s http://repo/location

-s

git fetch и git pull — забираем изменения из центрального репозитория

Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

git fetch /home/username/project — забрать изменения из определенного репозитория.

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

git remote add username-project /home/username/project

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

Естественно, что после оценки изменений, например, командой , надо создать коммит слияния с основной:

git merge username-project/master

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

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

git pull

Забрать изменения и метки из определенного репозитория:

git pull username-project --tags

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

git push — вносим изменения в удаленный репозиторий

После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.

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

git push

Отправить изменения из ветки master в ветку experimental удаленного репозитория:

git push ssh://yourserver.com/~you/proj.git master:experimental

В удаленном репозитории origin удалить ветку experimental:

git push origin :experimental

В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

git push origin master:master

Отправить метки в удаленную ветку master репозитория origin:

git push origin master --tags

Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

git push origin origin/develop:master

Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

git push origin origin/develop:refs/heads/test
Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Все про сервера
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: