Извлеките git fetch;git rebase origin/master или git pull --rebase, оба соблюдают порядок коммитов в главном репозитории, потому что он перезагружается, помещая локальные коммиты сверху.В любом случае вас не заботит порядок местных коммитов в местных филиалах, потому что они есть только у вас.Попробуйте, но используйте с осторожностью, например, продублируйте ветку перед перебазированием, пока не привыкнете к ней.
В общем, вы говорите о рабочем процессе git, и я обнаружил, что есть два основныхрабочие процессы, с которыми вы должны ознакомиться.Помните, что из личного опыта я говорю о том, как минимизировать конфликты:
- Рабочий процесс с перебазированием в первую очередь (для самой чистой истории коммитов бремя конфликтов обычно переносится на незафиксированный код)
- Рабочий процесс слияния (иногда проще, когда есть много изменений, которые могут конфликтовать, я обычно использую это только как запасной вариант)
Пример Начальный рабочий процесс
git checkout master // For the sake of argument, let's say the latest commit in your local master is from august 1st or something old like that.
git branch temp_branch // copy of the master
git checkout temp_branch
git add changedFiles;git commit changedFiles; // A change from november 2nd.
git log // Now your dev branch has a new commit on top of an otherwise old branch.
git log origin/master // You get a listing of the commits from the origin repository, the master branch.
Обычно я используюorigin / master для разработки, с git-тегами, обозначающими коммиты, которые делаются живыми выпусками.
Теперь вот, где возникает проблема, и где вступает в действие выбор рабочего процесса: скажем, есть коммит, который пришелиз другого хранилища dev в master, например, коммит с 15 октября.Может быть, это было сделано другим разработчиком, может быть, вы сами.
Ваш выбор: объединить или перебазировать.
Объединить
Вводит дополнительный коммит, уважает вашу локальную (не выдвинутую) ветвьИстория dev по канонической (origin / master) истории, создает немного больший потенциал для конфликтов для других и других ветвей .По сути, вы говорите: «Мой порядок фиксации будет смешан с порядком фиксации главной ветви», а не переупорядочивает историю фиксации.
git merge origin/master // merge commit introduced
... // Resolve any conflicts, and finalize the merge commit.
git checkout master;git rebase temp_branch // Move the changes to master.
git push origin/master // Pushing changes, including merge commit, to origin/master
В конце история фиксации будет выглядеть примерно так: август-октябрь-November-MergeCommit
Rebase
Никаких дополнительных коммитов, хиты коммитов уже в каноническом репозитории (origin / master) по локальным коммитам, возникающие конфликты обычно возникают при коммитах, которых разработчик еще не сделалсовершено (и, следовательно, никто другой не может отчитаться).
git rebase origin/master //
... // Resolve any conflicts...
git rebase --continue or git rebase --abort
... // Resolve any conflicts...
git checkout master;git rebase temp_branch // Get the branch changes without a merge commit into master.
git push // Push all changes to the canonical repository.
Примечание. Если в конечном итоге вам придется выполнить более двух решений конфликтов, - то это хорошее время для git rebase --abort иотступите к выполнению слияния.
Попробуйте процесс, посмотрите, имеет ли он смысл для вас!Я полагаю, что прежде чем вы сможете получить тактику, которая хорошо работает для вашего развития в git, вам нужно будет поэкспериментировать, потому что после децентрализации появляется гораздо больше подходов.