2012-06-20 6 views
2

Я понимаю, что история хранения является то, что лучше сохранить для VCS, и я знаю, что мерзавец позволяет клонировать не полный журнал истории, но:Каков самый разумный метод хранения истории хранилища?

  • Я боюсь GitHub пространство ограничено (основная причина)
  • это авто-коммитов обработка сценария
  • я интересен только в последние 10 или 5 коммитов в истории
  • сервер пространство может быть ограничено

Но я полностью не могу сформируйте идею, почему я хочу ее, но я использую shell: я хочу разветвить этот (автоматизированный) репозиторий и использовать git merge (да, как инструмент), чтобы работать над ним и поддерживать обновление с помощью восходящего потока. Поэтому в этом случае я буду использовать git правильно. в идеале я должен сделать то, что делает «git merge», без этого автоматизированного репозитория upstream, но это еще одна задача.

Пока я нашел только что хитрый способ очистить все истории с помощью мерзавец перебазироваться

git checkout --orphan temp $1 
git commit -m "Truncated history" 
git rebase --onto temp $1 origin/master 
git checkout master 
git branch -D temp 

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

+1

«автоматическая обработка транзакций по сценарию»? «только в последних 10 или 5 фиксациях в истории»? Вы уверены, что git - правильный инструмент для вас? Вы, кажется, не используете его как [vcs] (http://en.wikipedia.org/wiki/Revision_control). –

+0

Нет, я не уверен. но это другой вопрос. Я понимаю, что мне нужно подумать об альтернативах. – Cynede

+0

Что-то сложное не делает его бесполезным. Часто это наоборот. Если вы обнаружили, что команды нужны вам, создайте скрипт, который выполняет эту задачу для вас. Абракадабра, сложность ушла. – tripleee

ответ

3

Что вы делаете, это очень неправильно.

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

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

И ваши аргументы недействительны. Если вы храните только свой код (и параметризацию и небольшие ресурсы) в git, вы не рискуете взломать пространство хранения github и любое пространство на сервере. У меня много проектов на git, у многих кодеров, а занятое пространство пренебрежимо мало. Вы не должны пытаться стереть историю, чтобы сэкономить место.

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

+0

Тем не менее, я не могу полностью сформировать идею, почему я хочу ее, но я использую оболочку: я хочу развернуть этот (автоматический) репозиторий и использовать git merge (да, как инструмент), чтобы работать над ним и поддерживать обновление с помощью восходящего потока , Поэтому в этом случае я буду использовать git правильно. в идеале я должен сделать то, что делает «git merge», без этого автоматизированного репозитория upstream, но это еще одна задача. – Cynede

+0

Я не уверен, что до тебя добрался. Но комментарий: вам не нужно использовать слияние, если вы единственный кодер и не делаете ветви. Чтобы отправить на сервер, клонируйте свой репозиторий, поместите клонированный репозиторий на свой сервер (или github), а после этого используйте push, чтобы отправить вашу локальную работу в этот отдаленный репозиторий. –

+0

I fork git repository от rsync, чтобы развить его для себя и держать себя в курсе событий. – Cynede