Как сохранить копию проекта в Git'е?

#git

Вот такая ситуация, работаю с Git.

В проекте имплементировал несколько классов которые обрабатывают нотификацию.

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

Как можно сохраниться, вырезать все что не нужно, но потом если нужно чтоб можно
было вернуться обратно?
    

Ответы

Ответ 1

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


на «бумажке»;
создав указатель на этот коммит (очень «лекговесная» операция — в хранилище будет
создан всего один файл размером 41 байт):


либо фиксированный — метку (tag):

$ git tag имя.метки коммит


кстати, пока вы явно не укажете отправить ваши метки в общее хранилище (например,
с помощью опций --tags или --all команды push), ваши коллеги и не узнают о их существовании:
они будут храниться только в вашей локальной копии хранилища;
либо «плавающий» — ветку (branch):

$ git branch имя.ветки коммит


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


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


с рабочим каталогом (т.е. со всеми файлами, история которых отслеживается):

$ git clone /путь/к/текущему/хранилищу /путь/к/копии

или без рабочего каталога (для экономии места):

$ git clone /путь/к/текущему/хранилищу /путь/к/копии --bare

или даже «пакет» (bundle):

$ git bundle create файл.с.пакетом набор.коммитов






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


Ответ 2

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

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

p.s.
В гите нужно привыкнуть к тому, что теги легковесны, ветки легковесны, что не нужно
бояться merge и не нужно бояться форков. Системы управления репозиториями вроде github,
gitlab, bitbucket рассчитаны на всё это, включая форки