Использовать git stash save или git commit для локальных изменений?

Я изменил некоторые файлы в своем РЕПО, но не хочу, чтобы они были опубликованы или создали какую-либо временную ветку для их хранения. Я просто хочу сохранить эти изменения где-нибудь. Итак, какая команда лучше:

git stash save "save message"

или 

git commit -am "save message"

?

если я использую git commit, правда ли, что все мои локальные коммиты будут публично толкаться одним ? Что, если я просто хочу нажать одну конкретную фиксацию среди них?

15
git git-commit git-stash github

4 ответов

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

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

другими словами, Да, можно использовать фиксацию для временного, частного хранения. Тем не менее, гораздо проще использовать функцию stash. На самом деле, функция составила для этого очень вариант использования.

13

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

  • это их собственные обязательства. За исключением метки, нет принципиальной разницы между фиксацией" stash " и фиксацией, привязанной к метке ветви или тега. (Метка тега имеет форму refs/tags/tag-foo; ветвь имеет вид refs/tags/branch-foo; и фиксация-single-labeled stash помечена как refs/stash. Конечно, ярлыки ветви также имеют функция "автоматически перемещается при добавлении коммитов", но если вы никогда не добавляете больше коммитов, они никогда не перемещаются, поэтому они работают так же хорошо, чтобы сохранить один коммит.)
  • тайник "стек"1 реализовано с использованием reflogs. Reflogs можете истекает-по умолчанию большинство (через 30 или 90 дней), и те, в refs/stash нет, но вы можете изменить это с помощью конфигурационных записей-поэтому фиксации stacked stash также могут "истекать" (в то же время запись reflog истекает). (Точнее, они "становятся коллекционными", но это различие не помогает, если они исчезли. : -))

цель с тайниками-сохранить что-то краткосрочное. Если вы когда-либо возвращались к РЕПО поздно и находили кучу тайников, все с именем "WIP on branch", неинтересно пытаться понять их.

другие функции / ошибки : -)stash предоставляем:

  • git stash branch позволяет передумать после того, как факт и превратить заначку в отделение. Итак, если "короткий срок" оказывается проблемой (вы собирались исправить это сегодня днем, но теперь это было отложено по крайней мере на месяц), вы можете просто превратить тайник в ветку.
  • git stash apply [--index] сделает все возможное, чтобы" повторно сделать " примененное изменение в текущей ветви. С --index он попытается восстановить как поэтапные, так и неустановленные изменения независимо. (Однако бывают случаи, когда это невозможно.)
  • git stash pop автоматически отбрасывает ссылка на тайник для вас. К сожалению, он делает это даже если вы хотели использовать git stash pop --index и выехал в --index часть. Легко потерять часть своего состояния (staged vs unstaged), если вы используете pop. Если вы используете apply, а потом drop как только вы уверены, что у вас есть все, как вы хотели, вы можете избежать этой проблемы.

отметим, что git stash branch подразумевает --index: вновь созданная ветка будет иметь поэтапные и неустановленные изменения, восстановленные так, как они были, когда ты git stash. (Ветка будет ветвиться от фиксации, на которой Вы были, когда вы сделали git stash тоже.) Внести изменения (git add-при желании больше, или как два отдельных коммита, или что угодно) и действуйте так, как будто вы сделали частную ветвь в первую очередь.

1истекающая часть стека состоит из всех тайников, кроме stash@{0}, в git stash list выход.

3

Я предлагаю вам использовать инструмент для хранения. Вот почему он здесь. Вы можете спрятать свои chnges и позже добавить их в свой код. Есть много больше функций, которые вы можете использовать с git stash. Вот ссылка http://git-scm.com/book/en/Git-Tools-Stashing

Я бы предложил вам один раз пройти через документацию git здесь. Также читайте об инструменте. После этого вы точно станете мастером git.

0

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

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

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

затем я создаю новую ветвь для этих "новых" изменений, и я могу либо зафиксировать их все сразу, либо разбить ее на части в несколько коммитов, если это имеет смысл (например, один для back-end, другой для front-end, другой для ресурсов и т. д.)

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

Итак, резюмируем...

  1. создать рабочую бранч
  2. сделайте столько коммитов / вложенных ветвей, сколько вам нужно, чтобы выполнить свою работу
  3. когда вы будете готовы к слиянию без сохранения этой истории, git-reset вернется к исходной фиксации, где вы разветвились. Все ваши изменения теперь локальные изменения.
  4. повторная фиксация и слияние, как вы считаете нужным

еще одно преимущество - я могу фактически толкать временные ветви к удаленному репо, чтобы я мог работать из нескольких мест, которые вы не можете сделать с помощью припрятывать. Просто помните, когда вы закончите, очистите резервные копии с сервера, чтобы сохранить чистый просмотр РЕПО. (Некоторые могут утверждать, что технически коммиты все еще существуют, просто отделены, что верно, но ветви имеют легкий вес в GIT, и в некотором смысле это становится еще одной страховочной сеткой для не потери работы, поскольку вы можете вернуть отделенный коммит, если это действительно необходимо.)

0