Блог

Главная - Вопросы по программированию - Каково обоснование решения git не фиксировать текущее содержимое нового добавленного файла, а вместо этого содержимое того, когда оно было добавлено?

Каково обоснование решения git не фиксировать текущее содержимое нового добавленного файла, а вместо этого содержимое того, когда оно было добавлено?

#git #version-control

#git #контроль версий

Вопрос:

Итак, из того, что я прочитал в Pro Git,

Оказывается, что Git обрабатывает файл точно так, как он есть, когда вы запускаете add команду. Если вы фиксируете сейчас, в фиксацию войдет версия someFile , которая была при последнем запуске add команды, а не версия файла, которая выглядит в вашем рабочем каталоге при запуске commit . Если вы изменяете файл после запуска, add вам придется выполнить add повторный запуск, чтобы создать последнюю версию файла

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

Каково обоснование этого?

Ответ №1:

git отслеживает не файлы, а изменения. Итак, когда вы «добавляете файл», вы добавляете не файл, вы добавляете изменения в этот файл, который в случае нового файла представляет собой все его содержимое на момент его добавления. Итак, если вы вносите изменения после «добавления файла», но перед фиксацией, вы также должны добавить эти новые изменения, иначе они не будут зафиксированы.

Комментарии:

1. Означает ли это, что обычно я должен добавлять файлы только непосредственно перед фиксацией?

2. Вы должны делать то, что лучше всего подходит для вас. Лично я добавляю изменения только непосредственно перед фиксацией (и часто фиксирую быструю строку различных изменений, если они имеют смысл сами по себе), которая включает любые новые файлы. YMMV, но, похоже, вам будет удобнее (по крайней мере, на данный момент), если у вас войдет в привычку добавлять файлы только непосредственно перед фиксацией.

3. Это зависит от вас. Как сказал Кроми, он не добавляет файлы, он добавляет изменения. Также сначала оно добавляется на этап индексации. Это область, где изменения «остаются», пока они не будут зафиксированы. Если вы измените уже существующий файл, вы можете просто добавить его еще раз (помните: Вы добавляете новые изменения). Или вы также можете решить сделать второй коммит. Я также добавляю файлы незадолго до фиксации, но я фиксирую очень часто (иногда я «сжимаю» их вместе позже ;)).

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

5. @devoured: добавление непосредственно перед фиксацией, как правило, является хорошим подходом. Одна небольшая настройка — если вы работаете над изменением, затрагивающим много файлов, вы можете добавлять отдельные файлы по мере завершения работы с ними или даже сразу после завершения одного изменения, чтобы вы могли легко отслеживать, что сделано, а что нет.

Ответ №2:

Почти всегда имеет смысл фиксировать сразу после добавления, вот почему commit есть -a опция, и вот почему практически все другие VCS не позволяют разделить добавление и фиксацию, даже если внутри они являются отдельными этапами.

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

Ответ №3:

На самом деле это очень согласуется с тем, как git add работает для не новых файлов.

 $ git checkout master # assume there is some file called code.c
# hack hack hack
$ git add code.c
# hack hack hack
$ git commit

Это добавляет файл в том виде, в каком он выглядел на момент добавления git. Скажем, в svn вы бы даже не выполнили добавление, потому что svn add это только для новых файлов. Таким образом, это один дополнительный шаг (если вы не используете git commit -a , как сказал кто-то другой), но это дает вам гораздо больше гибкости, чтобы фиксировать только некоторые изменения и оставлять другие незафиксированными в том же файле. Как только вы освоитесь с git, вы можете влюбиться в git add -p команду именно по этой причине. 🙂