Первый вопрос: файл конфигурации нажимается на удаленный репозиторий, как удалить файлы конфигурации удаленного репозитория, но и использовать этот локальный файл.
Такого рода ошибки относительно распространены. Обычно решают так:
git rm --cached filename
echo filename >> .gitignore
Сначала объясните второй шаг, локальный нужен, удаленный склад не нужен, его надо записать в этот файл.gitignoreвнутри файла.
В противном случае он будет удален позже.
Первый шаг — удалить файл из промежуточной области git. Область временного хранения — это индексная область.
Знакомство с родственниками:
git три области,git rm filename, удалит файл из рабочего каталога рабочей области и промежуточной области. Если вам нужно использовать его локально, вы не можете этого сделать.
git rm --cached filename, то удалите файл из промежуточной области, и сохраните рабочую область, которую мы обычно видим при редактировании.
В этом случае коммит был зафиксирован, сгенерирован снимок, файл занесен в историю коммитов репозитория, а затем пропушен, удаленная библиотека синхронизируется с локальной библиотекой.
В настоящее время нажатие непосредственно на пульт недопустимо. Поскольку нет нового снимка, то есть нет нового идентификатора фиксации, локальные и удаленные исторические журналы согласованы. Измените файл, добавьте, а затем зафиксируйте, нажмите, чтобы отправить его, он вступит в силу.
Вопрос 2: Как git разрешает конфликты кода
Тройное разрешение конфликтов
git stash
git pull
git stash pop
Операция заключается в том, чтобы скрыть код, который вы изменили, затем извлечь код удаленного хранилища, а затем освободить измененный код, который вы скрываете, и позволить git автоматически объединить его. Затем найдите<<<<<<<, где конфликт, где менять.
Если вы хотите, чтобы файлы кодовой базы полностью перезаписывали локальную версию,
git reset --hard commit id
git pull
Первые два трюка весьма полезны.Сценарий такой, что на удаленном складе кооперации другие внесли какие-то изменения, я их не коммитил, а потом дернул чужие коммиты.
Когда я впервые пришел в компанию, я ничего не мог с собой поделать, и я часто так делаю.
На подходе расширенная версия
Сценарий таков, что на удалённом складе кооперации другие внесли какие-то изменения, а я тоже сделал какие-то коммиты локально, а потом тяну вниз коммиты других, а потом добавляю свои изменения. Затем найдите<<<<<<<, где конфликт, где менять.
В это время сначала проверьте недавний общий идентификатор фиксации моего локального репозитория и совместного удаленного репозитория.
git reset commit id
git stash
git pull
git stash pop
git reset commit idРоль состоит в том, чтобы отменить промежуточный файл. Наведите указатель HEAD на идентификатор коммита, измените Staging Area Staging Area и Commit History репозитория и сохраните рабочий каталог песочницы рабочей области как есть.
Родственники здесь, посмотрите на картинку для углубления понимания:
-
git reset commit idто естьgit reset -mixed commit id, переместите HEAD, обновите индекс, то есть обновите промежуточную область. Переместите указатель ветки HEAD, чтобы индекс стал похож на HEAD. По сути, после отмены идентификатора фиксации добавьте и зафиксируйте . -
git reset --soft commit id, который является мобильным HEAD. Перемещение точки в ветку HEAD фактически отменяет последнюю команду git commit.
Когда вы запускаете git commit, Git создает новый коммит и перемещает ветку, на которую указывает HEAD, чтобы она указывала на этот коммит.
Когда вы сбрасываете его обратно в HEAD~ (родительский HEAD), вы фактически перемещаете ветку обратно в исходное местоположение без изменения индекса и рабочего каталога.
-
git reset --hard commit id, переместить HEAD, обновить индекс, обновить рабочий каталог. Все три дела сделаны. О первых двух вещах уже сказано. Обновите рабочий каталог, чтобы он выглядел как индекс. С точки зрения эффекта это означает отмену всех изменений, а статус локального файла совпадает с идентификатором фиксации.
Вопрос 3: Когда объединять ветки сgit rebase, Не нужноgit merge ?
git rebaseа такжеgit mergeОба могут использоваться для слияния веток, получения новых коммитов из ветки функций, а затем применения их к ветке master (конечно, это также может быть применено к другим веткам).
Но путь другой
слияние это слияние, ребаз это ребаз
Как сменить базу?
Глядя на картинку, мы видим:git rebaseЕсть перемещение базы, операция, изменяющая базу слияния
Интуитивное понимание:git rebaseНужно сначала переместить указатель, а затем переместить узел.
- Сначала переместите указатель: идентификатор коммита функциональной ветки, разветвленной до того, как основная ветвь станет контрольной базой функциональной ветки.
в функциональной веткеgit rebase master, переместите базовую базу функциональной ветки на последний идентификатор фиксации основной ветки.
- Снова переместите узел: поместите новый идентификатор коммита в ветку функций за новым базовым узлом. Если быть более точным, это повторное применение вновь внесенных изменений в ветке feature к узлу HEAD ветки master.
Например:
Перед объединением веток:
A <- B <- C [master]
^
\
D <- E [branch]
Корневой узел - это A, изначально A, в состоянии A, ветвь ветви разветвляется
git mergeобъединяется так:
A <- B <- C
^ ^
\ \
D <- E <- F
Основная ветвь, отправленная C, и ветвь ветви, отправленная E, объединяются напрямую, обычно объединяются с master, и возникает конфликт для разрешения конфликта.
Глядя на картинку, мы видим, что:git merge, без изменения исходного идентификатора фиксации будет сгенерирован новый идентификатор фиксации.
Есть много сотрудников проекта, как правило, необходимо использоватьgit rebase, конечно жеgit merge, git merge --squash feeature
При использованииgit merge, наверное так,
Глядя на это таким образом, это очень неудобно. нужно принятьgit rebaseИстория модификации:
git rebaseобъединяется так:
A <- B <- C <- `D` <- `E`
Переместите коммиты из ветки функций (в данном случае ветки ветки) в начало ветки master.
С помощью rebase выглядит красивее и нагляднее.История — прямая линия, а веток и ответвлений нет.
Глядя на картинку, мы видим, что после использования rebase, после коммита ветки фичи, id коммита изменился. и идентификатор фиксации объединенного общедоступного узла не был создан
Некоторые команды используютgit rebaseРабочий процесс, некоторые используютgit mergeрабочий процесс,git rebaseРабочий процесс требует более глубокого понимания git, более коммерческого использования и хороших функций, использованияgit rebaseсливаться.
Как добавить фичу таким способом, понятнее посмотреть в логе. В противном случае посмотрите лог, предыдущая фича А, следующая фича Б, не очень профессиональный программист.
git rebaseРабочий процесс, вообще такой практичный,
в функциональной веткеgit rebase master,
После перехода на основную веткуgit merge featureВ это время слияние ничего не сделала, просто переместил головной узел главной ветви к главному узлу функции, а две ветви были в синхронизации в это время.
git mergeРабота в работе очень подходит, его дизайн очень соответствует интуиции, играя с открытым исходным кодом Github, более подходящим. Из-за написания несколькими людьми рабочий процесс gitflow не очень унифицирован.
если вы используетеgit rebaseРабочий процесс, другие люди в вашей команде не знают, вы делаете это, идентификатор коммита был изменен, он не совпадает с их локальной библиотекой, у вас может быть большее мнение о вас.
Ведь git использует ветки, а значит не обижать чужой код