Случайно выполнил git init и запушил на сервер

#git #git_init

Есть рабочий репозиторий с большой историей. Программист случайно выполнил в нем
git init и отправил на сервер. В итоге была дозаписана куча мусора, права на файлы
сменились + еще всякое. Коммит init нельзя просто так отменить(revert).
Как все таки его отменить и вернуть все назад?
    

Ответы

Ответ 1

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



Прочитать записи в рефлоге. git reflog
Сделать git reset --hard HEAD@{N} где N - нужный коммит
Проверить, что текущая точка именно та, которая нужно.
Если состояние устраивает -- то сделать git push -f (раз уж вы успели на сервер отправить)

Для чего нужен флаг bare

#git #git_clone #git_init

Для чего нужен флаг --bare при клонировании/создании репозитория?

Что он даёт при переносе репозитория?
    

Ответы

Ответ 1

совсем короткая формулировка

вот вам надо, допустим, скопировать архив с одного сервера на другой, и вам дают
инструкцию:


скопируйте архив с сервера1 на локальную машину
распакуйте архив
скопируйте архив на сервер2


а зачем, спрашивается, здесь нужен пункт 2, про распаковку архива??? не нужен. вот
и при копировании хранилища аналогичная ситуация — а зачем извлекать из хранилища содержимое
рабочего каталога? не нужно. для этого и пригодится опция --bare.

более обстоятельный ответ

начать надо, пожалуй, с иллюстрации того, что, собственно, представляет собой git-хранилище
(часто используется термин «git-репозиторий»).

вот оно, свежесозданное хранилище, не отслеживающее (пока) ни одного файла, но уже
содержащее 9 каталогов и 13 файлов (в разных версиях и сборках программы git конкретные
цифры могут, конечно, слегка отличаться), необходимый минимум, который позволит программе
git начать отслеживание файлов вашего проекта (ну, почти необходимый — без файлов с
примерами из каталога hooks можно было бы и обойтись):

$ tree -F
.
├── branches/
├── config*
├── description
├── HEAD
├── hooks/
│   ├── applypatch-msg.sample*
│   ├── commit-msg.sample*
│   ├── post-update.sample*
│   ├── pre-applypatch.sample*
│   ├── pre-commit.sample*
│   ├── prepare-commit-msg.sample*
│   ├── pre-push.sample*
│   ├── pre-rebase.sample*
│   └── update.sample*
├── info/
│   └── exclude
├── objects/
│   ├── info/
│   └── pack/
└── refs/
    ├── heads/
    └── tags/

9 directories, 13 files


эти файлы и каталоги появятся в текущем (изначально пустом) каталоге после выполнения
команды:

$ git init --bare


а если опустить опцию --bare, все они будут «спрятаны под капотом» — программа git
создаст их не в текущем каталоге, а в подкаталоге .git (точка в начале имени служит
для того, чтобы в unix-подобной операционной системе этот подкаталог по умолчанию не
показывался при получении листинга каталога).

«спрятаны» они будут не только «для эстетики» и не только потому, что эти «внутренние
потроха» для «обычного» пользователя программы git представляют мало интереса. основная
цель — «освободить» текущий каталог под собственно файлы (и каталоги) вашего проекта.
в этом случае он (текущий каталог) будет выполнять функции рабочего каталога (working
tree в оригинальной документации, другой нередко встречающийся перевод — рабочая копия).



если при хранилище имеется рабочий каталог, то такое хранилище называют «не-bare-хранилищем»,
или «хранилищем с рабочим каталогом», а чаще, для краткости — просто «хранилищем».
а если рабочего каталога нет, то такое хранилище называют «bare-хранилищем» (дословно
— «голым»).



а какая польза от такого «bare-хранилища»? какой практический смысл в нём? что с
ним можно сделать?

ну, с точки зрения «конечного» пользователя (чаще всего — программиста) пользы, действительно,
мало, ведь не видно же файлов/каталогов проекта. а вот с точки зрения программы git
— это полноценное хранилище, которое можно клонировать, делать из него pull-ы, а в
него — push-ы. именно в таком виде (без рабочего каталога) располагаются хранилища
на таких серверах, как github.com, bitbucket.org и тому подобных. программа git легко
может извлечь и отобразить любую информацию из такого хранилища: историю коммитов,
листинг файлов проекта, содержимое любого из файлов проекта в том состоянии, как он
выглядел после любого из коммитов, и так далее и тому подобное.



опцию --bare можно использовать и вместе с командой clone: в этом случае в текущем
(или указанном) каталоге будет сначала создан «костяк» хранилища (состоящий из вышеперечисленного
набора 13-ти файлов и 9-ти каталогов), который будет наполнен информацией из клонируемого
хранилища (в основном это коснётся каталога objects — именно в нём хранятся git-объекты:
коммиты, деревья и блобы).

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



стоит ещё отметить, что признак хранилища — «bare/не-bare» — хранится в файле config
внутри хранилища в виде строчки bare=true или bare=false в секции [core].



ах, да, совсем забыл:


  Что он (подразумевается опция --bare) даёт при переносе репозитория?


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

Как отменить git init в уже существующем репозитории?

#git #git_init

В папке с git-ом случайно нажал на git init , в итоге теперь когда делаю git status
у меня все файлы отображаются как измененные.

В git log последние коммиты остались. Как отменить действие команды git init?
    

Ответы

Ответ 1

Если просто случайно создали репозиторий, то нужно удалить папку .git в корне. Это
полностью уничтожит репозиторий и, разумеется, отменит то, что сделал git init. Через
*nix-консоль это делается так:

rm -r .git


Если же Вы сделали git init в уже существующем репозитории, то бояться нечего:


  Running git init in an existing repository is safe. It will not overwrite things
that are already there. The primary reason for rerunning git init is to pick up newly
added templates (or to move the repository to another place if --separate-git-dir is
given).


Ответ 2

Судя по описанию, команда git init была выполнена не в корневой директории проекта,
а в одной из вложенных. В таком случае всё, что внутри этой вложенной директории, изнутри
нее считается новым репозиторием (а снаружи — старым).

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

Предположим, у нас есть такая структура. В корневой директории проекта A инициализирован
репозиторий Git.

A
|-.git
|-A/B
|-A/C
    |-A/C/X
    |-A/C/Y
    |-A/C/Z
|-A/D  


Теперь мы инициализируем новый репозиторий в директории A/C:

$ cd C
$ git init

A
|-.git
|-A/B
|-A/C
    |-.git
    |-A/C/X
    |-A/C/Y
    |-A/C/Z
|-A/D 


Теперь наблюдаем следующую картину:

При выполнении любой команды Git из директорий A, A/B, A/D, обнаруживается репозиторий
в директории A.

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

Чтобы исправить ситуацию, достаточно удалить .git из директории A/C:

$ rm -rf A/C/.git


Ответ 3

если у вас не bare-репозиторий, то он состоит из собственно репозитория, хранящегося
в каталоге .git, и т.н. working tree, т.е. файлов и каталогов, историю изменений которых
вы и отслеживаете с помощью git.

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

поищите в глубинах working tree другие каталоги .git.

если обнаружите такой(-ие) каталог(-и), попробуйте переместить (не удаляя) его (их)
в какое-нибудь другое место за пределами working tree и проверьте, всё ли в порядке
с git log и git status.

Как отменить git init в уже существующем репозитории?

В папке с git-ом случайно нажал на git init , в итоге теперь когда делаю git status у меня все файлы отображаются как измененные.
В git log последние коммиты остались. Как отменить действие команды git init?

Ответ

Если просто случайно создали репозиторий, то нужно удалить папку .git в корне. Это полностью уничтожит репозиторий и, разумеется, отменит то, что сделал git init. Через *nix-консоль это делается так:
rm -r .git
Если же Вы сделали git init в уже существующем репозитории, то бояться нечего
Running git init in an existing repository is safe. It will not overwrite things that are already there. The primary reason for rerunning git init is to pick up newly added templates (or to move the repository to another place if --separate-git-dir is given).

Для чего нужен флаг bare

Для чего нужен флаг --bare при клонировании/создании репозитория?
Что он даёт при переносе репозитория?

Ответ

совсем короткая формулировка
вот вам надо, допустим, скопировать архив с одного сервера на другой, и вам дают инструкцию:
скопируйте архив с сервера1 на локальную машину распакуйте архив скопируйте архив на сервер2
а зачем, спрашивается, здесь нужен пункт 2, про распаковку архива??? не нужен. вот и при копировании хранилища аналогичная ситуация — а зачем извлекать из хранилища содержимое рабочего каталога? не нужно. для этого и пригодится опция --bare
более обстоятельный ответ
начать надо, пожалуй, с иллюстрации того, что, собственно, представляет собой git-хранилище (часто используется термин «git-репозиторий»).
вот оно, свежесозданное хранилище, не отслеживающее (пока) ни одного файла, но уже содержащее 9 каталогов и 13 файлов (в разных версиях и сборках программы git конкретные цифры могут, конечно, слегка отличаться), необходимый минимум, который позволит программе git начать отслеживание файлов вашего проекта (ну, почти необходимый — без файлов с примерами из каталога hooks можно было бы и обойтись):
$ tree -F . ├── branches/ ├── config* ├── description ├── HEAD ├── hooks/ │   ├── applypatch-msg.sample* │   ├── commit-msg.sample* │   ├── post-update.sample* │   ├── pre-applypatch.sample* │   ├── pre-commit.sample* │   ├── prepare-commit-msg.sample* │   ├── pre-push.sample* │   ├── pre-rebase.sample* │   └── update.sample* ├── info/ │   └── exclude ├── objects/ │   ├── info/ │   └── pack/ └── refs/ ├── heads/ └── tags/
9 directories, 13 files
эти файлы и каталоги появятся в текущем (изначально пустом) каталоге после выполнения команды:
$ git init --bare
а если опустить опцию --bare, все они будут «спрятаны под капотом» — программа git создаст их не в текущем каталоге, а в подкаталоге .git (точка в начале имени служит для того, чтобы в unix-подобной операционной системе этот подкаталог по умолчанию не показывался при получении листинга каталога).
«спрятаны» они будут не только «для эстетики» и не только потому, что эти «внутренние потроха» для «обычного» пользователя программы git представляют мало интереса. основная цель — «освободить» текущий каталог под собственно файлы (и каталоги) вашего проекта. в этом случае он (текущий каталог) будет выполнять функции рабочего каталога (working tree в оригинальной документации, другой нередко встречающийся перевод — рабочая копия).

если при хранилище имеется рабочий каталог, то такое хранилище называют «не-bare-хранилищем», или «хранилищем с рабочим каталогом», а чаще, для краткости — просто «хранилищем». а если рабочего каталога нет, то такое хранилище называют «bare-хранилищем» (дословно — «голым»).

а какая польза от такого «bare-хранилища»? какой практический смысл в нём? что с ним можно сделать?
ну, с точки зрения «конечного» пользователя (чаще всего — программиста) пользы, действительно, мало, ведь не видно же файлов/каталогов проекта. а вот с точки зрения программы git — это полноценное хранилище, которое можно клонировать, делать из него pull-ы, а в него — push-ы. именно в таком виде (без рабочего каталога) располагаются хранилища на таких серверах, как github.com, bitbucket.org и тому подобных. программа git легко может извлечь и отобразить любую информацию из такого хранилища: историю коммитов, листинг файлов проекта, содержимое любого из файлов проекта в том состоянии, как он выглядел после любого из коммитов, и так далее и тому подобное.

опцию --bare можно использовать и вместе с командой clone: в этом случае в текущем (или указанном) каталоге будет сначала создан «костяк» хранилища (состоящий из вышеперечисленного набора 13-ти файлов и 9-ти каталогов), который будет наполнен информацией из клонируемого хранилища (в основном это коснётся каталога objects — именно в нём хранятся git-объекты: коммиты, деревья и блобы).
а вот если выполнять команду clone без этой опции, то, во-первых, хранилище будет помещено в подкаталог .git, а не непосредственно в текущий каталог, а во-вторых, после наполнения хранилища будут дополнительно извлечены в текущий каталог все файлы и каталоги проекта.

стоит ещё отметить, что признак хранилища — «bare/не-bare» — хранится в файле config внутри хранилища в виде строчки bare=true или bare=false в секции [core]

ах, да, совсем забыл:
Что он (подразумевается опция --bare) даёт при переносе репозитория?
из вышеизложенного, надеюсь, стало понятно, что эта опция в случае переноса хранилища с одного сервера на другой позволяет не делать ненужную (в данном случае) работу: сэкономить такты процессора (на извлечение файлов/каталогов проекта), сэкономить ресурс винчестера на излишних операциях чтения/записи, сберечь немного электроэнергии, и, в конечном счёте, отдалить тепловую смерть вселенной. это же реальная цель существования человечества, верно?