Что делать после git pull?

Я использую SVN в течение некоторого времени и теперь использую Git в проекте. Я точно не знаю, что делать после того, как разрешил конфликты после выполнения git pull. Кстати, я использую черепаховый GIT.

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

Теперь многие из этих локальных изменений никогда не должны быть зафиксированы... но я прочитал этот блог git: http://randyfay.com/node/89 , а точнее:

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

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

РЕДАКТИРОВАТЬ: Это хорошо подводит итог, что-то, что произошло со мной, мы исправили, но нам нужно понять, как предотвратить в будущем.

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

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


person KaiserJohaan    schedule 07.08.2012    source источник
comment
Если у вас есть большое количество локально измененных файлов, которые вы не хотите отправлять в ветку, из которой вы отправляете, это обычно признак того, что вы делаете что-то странное.   -  person Wooble    schedule 07.08.2012
comment
Есть ли причина, по которой то, что вы фиксируете, потенциально будет собираться локально, но не из репозитория после того, как вы сделаете коммит? Или вы говорите, что если ваш код изменится function foo(x), вы беспокоитесь о том, что везде foo(x) называется, не зная об изменении? Или что разработчик может просто merge ошибиться? Теперь это происходит постоянно. я знаю свой код; Я не знаю вашего кода. все равно сливаю. Слить боркед. Добро пожаловать [пользователи, использующие] git. ;^)   -  person ruffin    schedule 07.08.2012
comment
Можете ли вы объяснить, что многие из этих изменений являются локальными и никогда не должны быть зафиксированы, если эти изменения [?] связаны с исправлением кода?   -  person ruffin    schedule 07.08.2012


Ответы (2)


EDIT2: кажется, я понял. Похоже, что люди push вносят свои изменения без локального регрессионного тестирования или регрессионного тестирования и помещают только файл, который изначально имел конфликты. Это плохо. git commit -a?

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

Второй вариант продвигается или предполагается Github и широко используется в проекте Linux Core (откуда Git появился). В этом сценарии вы не позволяете более чем одному сопровождающему отправлять важные ветки в полномочный репозиторий.

Так что, возможно, я что-то упускаю.

Эта статья о ветвящихся рабочих процессах может быть полезной для чтения.

РЕДАКТИРОВАНИЕ: Ах, с правкой, возможно, вы выступаете за рабочий процесс, основанный на fetching, а не первый человек, с которым столкнулся комментатор статьи, на которую вы ссылаетесь.

В чем разница между "git pull" и "git fetch" ?

Если вы говорите, что иногда плохо информированное слияние может привести к непреднамеренному неправильному слиянию хорошего кода, вы правы. Слияние иногда является изящным искусством, и часто требуется напрямую прослушивать других разработчиков, чтобы совместить изменения слияния. (Мне нравится сначала просматривать git вина .)

person ruffin    schedule 07.08.2012
comment
извините, мое редактирование недостаточно объясняло ситуацию, я отредактировал свое редактирование: p - person KaiserJohaan; 07.08.2012

Я полагаю, что сначала вы должны зафиксировать только те файлы, которые вы редактировали, вы, вероятно, должны знать, что они из себя представляют.

Вы можете понять, какие файлы были изменены в последних коммитах, хотя я не знаю TortoiseGit, вероятно, есть функция истории.

В будущем я рекомендую вам создать файл .gitignore на основе вашей локальной копии репозитория и перечислить все файлы, которые, как вы знаете, вы никогда не будете фиксировать (например, .project, .settings и тому подобное, включая файлы . гитигнор). Действительно, Git сканирует вашу файловую систему, чтобы узнать, какой файл был изменен, и иногда это бесполезно.

Если вам нужна дополнительная информация: http://www.kernel.org/pub/software/scm/git/docs/gitignore.html

person Vince    schedule 07.08.2012
comment
Ах, если это специфические вещи/накладные расходы IDE (или любой файл, который не является частью кода), который появляется, то это лучший ответ. Я не могу сказать, означает ли каждый измененный файл в проекте файлы, которые никогда не должны попадать в репо или нет. - person ruffin; 07.08.2012
comment
Хорошо, я вижу вашу проблему. Итак, сначала разберитесь, что вы сделали, а что пришло из IDE или других внешних инструментов. Затем, вероятно, в TortoiseGit есть функции, позволяющие понять, что произошло. Я использовал только командную строку, поэтому я не могу сказать, но вы, вероятно, хотите перечислить файлы, измененные при извлечении из репо. Затем вы захотите запустить diff для файлов, которые вы фактически объединили (те, которые вы, вероятно, редактировали). Однако вам нужно набраться терпения. Примечание: вы можете коммитить столько, сколько хотите. Только push будет раздражать ваших коллег - person Vince; 07.08.2012
comment
(Обратите внимание, что, хотя я разместил здесь первый комментарий, я не ОП - просто пытался понять его вопрос) - person ruffin; 07.08.2012