Вторая часть серии «Единый вход и управление разрешениями», посвященная дизайну и разработке демо-проекта, займет некоторое время. За это время я поделюсь с вами знаниями, которые я усвоил, попрактиковал и причесал раньше, и надеюсь, что всем понравится.
Указатель первой части серии «Единый вход и управление разрешениями»:
- Общие сведения о сеансах и файлах cookie
- HTTP-перенаправление
- Введение в единый вход
- проблемы с безопасностью файлов cookie
- Введение в управление правами
Далее я поделюсь соответствующим содержанием "управление ветками git и спецификация рабочего процесса". Когда проект большой, будет много людей, которые будут разрабатывать его вместе. Если нет соответствующей спецификации, будет много конфликтов, когда код Версия кода и история коммитов также могут выглядеть беспорядочно. Эти две проблемы можно решить с помощью управления ветвями и спецификации рабочего процесса.
Создавайте разные ветки для разных сценариев и всегда поддерживайте надежность и чистоту основной ветки.Например, в таких сценариях, как добавление функций, исправление онлайн-проблем и исправление ошибок в тестовой среде, вам необходимо создать разные ветки. Кроме того, необходимо заранее планировать функции, которые будут запускаться в следующей версии, подразделять функции и назначать их каждому человеку для их выполнения.Функции зависят друг от друга в одной ветке.Если вы не уверены по поводу запускаемых функций нужно создавать отдельные ветки, что может уменьшить Конфликты при слиянии.
При отправке кода необходимо сохранять историю отправки ясной, а отправляемые комментарии должны быть стандартизированы.Относительно истории отправки можно резюмировать три основных момента:
- Очень важным навыком для пользователя git является возможность вести четкую историю семантических изменений;
- Просматривая историю изменений версий, можно отразить цель разработки команды и изменения функций;
- История изменений версий записывает разработку кода, а не действия разработчиков во время написания кода;
«Управление ветками git и спецификация рабочего процесса» будут разделены на 3 статьи:
- концепции, связанные с git
- Конкретные характеристики
- Доработка и представление различных сценариев
Эта статья в основном знакомит с родственными понятиями git.Я не буду знакомить с основными.Существует множество онлайн-материалов,в основном в том числе:
- статус файла
- концепция филиала
- слияние слияние
- перебазировать
- git рабочий процесс
статус файла
тип состояния
- Изменено: изменить файл, но еще не переданный в хранилище; (без добавления)
- Поэтапно: измененный файл помещается в манифест для сохранения при следующей фиксации; (добавлено, без фиксации)
- commit: файл был благополучно сохранен в локальной базе данных; (commit)
Рабочий каталог, промежуточный каталог, каталог git
Три каталога соответствуют состоянию файла, и разные состояния помещаются в разные каталоги.
git-объект
- Объекты включают фиксацию, дерево файлов, содержимое файла и другие объекты операции;
- Состоит из 40 шестнадцатеричных цифр;
- Информацию об объекте можно просмотреть с помощью команды git cat-file;
Основной рабочий процесс
- Измените некоторые файлы в рабочем каталоге;
- Сделайте снимок измененного файла и сохраните его в тестовой области;
- Подтвердите обновление, чтобы навсегда сохранить моментальный снимок файла, сохраненный в области подготовки, в каталог git;
Команды, связанные со статусом
- git status показывает, какие файлы были изменены, какие были подготовлены и не зафиксированы;
- git diff сравнивает файлы в разных состояниях
- Сравните разницу между рабочим каталогом и снимком временного файла по умолчанию; (после модификации неустановленный файл)
- --cached сравнивает разницу между промежуточным, последним зафиксированным моментальным снимком;
- git reset выполняет операцию отмены и сбрасывает текущую ветку до указанной фиксации
- --hard сбрасывает рабочий каталог и промежуточную область;
- --mixed По умолчанию сбрасывается только область временного хранения, а рабочая директория остается неизменной;
- --soft указывает только на HEAD, а коммит после коммита попадет во временное хранилище;
концепция филиала
По сути, ветки — это просто изменяемые указатели для фиксации объектов.
Как git узнает, над какой веткой вы сейчас работаете?
- Содержит специальный указатель защиты с именем HEAD;
- HEAD — это указатель на локальную ветку, над которой вы работаете;
При просмотре веток через git branch -a вы увидите все ветки, включая локальные ветки, удаленную ветку;
Есть 2 способа: MERGE и REBASE. MERGE — это в основном автоматическое слияние. Существуют разные стратегии слияния для разных сценариев. Rebase в основном сливается вручную, и для каждого коммита можно указать разные политики слияния, которые будут представлены отдельно.
слияние слияние
- --commit --no-commit После слияния следует ли автоматически генерировать узел фиксации объединенного результата;
- --edit --no-edit, принимать ли информацию об автоматическом слиянии;
- --ff --no-ff параметры
- По умолчанию git выполняет «быстрое слияние» без создания нового узла фиксации;
- --NO-FF, создаст новый коммит;
- --log --no-log
- При слиянии и отправке, в дополнение к имени ветки, следует ли включать информацию журнала узла фиксации.
- --squash
- Не сохранять историческую информацию об объединяемой ветке, не выполнять коммит, не перемещать HEAD, требуется дополнительная команда коммита;
- Самый фундаментальный критерий для принятия решения о том, следует ли использовать параметр --squash, заключается в том, имеет ли смысл история объединяемой ветки;
- -- abort
- Откажитесь от текущего процесса конфликта слияния и попытайтесь восстановить состояние до слияния;
перебазировать
$ git rebase -i [branch|]
Три рабочие команды: --continue, --absort и --skip, эти три команды означают «продолжить», «выйти» и «пропустить» соответственно.
Обязательно обратите внимание на:
- После того, как релиз целевой ветви представлен на публичный склад, он не должен передать работу филиала;
- При перемещении некоторые существующие объекты фиксации фактически отбрасываются и создаются новые объекты фиксации, которые похожи, но отличаются;
- Если вы публикуете объекты фиксации в исходной ветке, а другие люди работают над ней после обновления и загрузки, а позже вы используете git rebase, чтобы отбросить эти объекты фиксации и опубликовать новые воспроизведенные объекты фиксации, вашим соавторам придется повторно объединить свои работа, поэтому, когда вы снова получаете от них, история коммитов - беспорядок;
- Думайте о перебазировании как о средстве очистки истории коммитов перед отправкой и перебазируйте только те коммиты, которые не были опубликованы;
В интернете много конкретных примеров, поэтому я не буду их здесь объяснять.
git рабочий процесс
Совместная работа должна иметь стандартизированный рабочий процесс, позволяющий каждому эффективно сотрудничать и обеспечивать упорядоченное развитие проекта.
网上对这一部分的介绍也很多，介绍比较多的就是git flow规范，可以参考下面2篇文章： [1]Руан Ифэн: рабочий процесс git [2] инструмент git-flow
Наконец, прилагается краткая справочная таблица часто используемых команд: