Это 9-й день моего участия в августовском испытании обновлений, подробности о событии:Испытание августовского обновления

1. Контроль версий

1.1, что такое контроль версий

Контроль версий — это система, которая записывает изменения в содержимом одного или нескольких файлов для дальнейшего использования при ревизии конкретной версии. В компании разработка проекта обычно осуществляется в форме команды. В команде каждому члену команды нужна копия одного и того же кода, и все разрабатывают разные функции на основе этого кода, и проблем в процессе будет довольно много.Для этих проблем мы можем использовать версию Поэтому многие версии родились инструменты управления, такие как cvs/svn/git, которые более распространены на рынке.

1.2 Зачем нужен контроль версий?

С его помощью вы можете перемотать файл в предыдущее состояние или даже перемотать весь проект в определенное прошлое состояние. состояние в определенный момент времени. Даже если вы возитесь с изменениями и удалениями файлов во всем проекте, вы все равно можете легко восстановить их в исходное состояние. Но дополнительная работа минимальна. Вы можете сравнить детали изменений в файлах, чтобы узнать, кто изменил какие места в конце, чтобы выяснить, что вызвало странность. Причина проблемы, кто и когда сообщил о дефекте функции и т. д. Контроль версий глубоко вовлечен в командную работу программистов.Если в вашем проекте нет контроля версий:

1. Управление кодом беспорядочное.
2. Сложность разрешения конфликтов кода.
3. Во время интеграции кода возникла ошибка.
4. Нет контроля доступа к владельцу кода.
5. Сложно выпускать разные версии проекта.

1.3 Классификация средств контроля версий

В настоящее время на рынке существует два основных типа инструментов контроля версий:

1. Централизованная система контроля версий
2. Распределенная система контроля версий

1.3.1 Централизованная система контроля версий

Централизованные системы управления версиями, такие как CVS, svn и Perforce, имеют единый централизованно управляемый сервер, на котором хранятся версии всех файлов, и люди, работающие вместе, подключаются к этому серверу через клиентов, чтобы получить последние файлы или отправить обновление. Это стандартная практика для систем контроля версий уже много лет.

Этот подход имеет много преимуществ, теперь каждый может в какой-то степени видеть, что делают другие люди в проекте. А администраторы могут легко контролировать права каждого разработчика и управлять централизованной системой контроля версий, что намного проще, чем поддерживать локальную базу данных на каждом клиенте. У вещей есть две стороны, хорошая и плохая. Наиболее очевидным недостатком этого является единая точка отказа центрального сервера. Если сервер не работает в течение часа, никто не сможет отправлять обновления и работать вместе в течение этого часа. В то же время он должен быть подключен к Интернету для работы.Если он находится в локальной сети, пропускная способность достаточно велика и скорость достаточно высока, но если скорость сети низкая в Интернете, это может занять 5 минут на отправку файла размером 10M.

1.3.2 Распределенная система контроля версий

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

Когда распределенная система контроля версий управляет проектом, она не хранит различия между версией проекта и версией, а хранит индекс (требует очень мало места на диске, поэтому каждый клиент может проставить историю всего проекта) По сравнению с централизованными системами контроля версий,Распределенные системы контроля версий намного надежнее., поскольку у каждого компьютера есть полная библиотека версий, не имеет значения, сломан ли компьютер человека, просто скопируйте одну из других. А если выйдет из строя центральный сервер централизованной системы контроля версий, все не смогут работать. При фактическом использовании распределенной системы контроля версий фактическиРедко передавайте изменения репозитория между двумя компьютерами, потому что, возможно, вы двое не находитесь в одной локальной сети, и два компьютера не могут получить доступ друг к другу, или, может быть, ваш коллега сегодня болен, и его компьютер вообще не включен. Поэтому распределенные системы контроля версий обычноТакже есть компьютер, который действует как «центральный сервер»., но роль этого сервера заключается только вУдобно "обменять" все модификации, без него все работают одинаково, но неудобно обменивать и модифицировать.

1.4 Краткая история Git

Git — самая продвинутая распределенная система контроля версий в мире. Как и многие великие вещи в жизни, Git родился во времена великих споров и инноваций. Проект с открытым исходным кодом ядра Linux имеет большое количество участников. Подавляющая часть обслуживания ядра Linux была потрачена на утомительную работу по отправке исправлений и хранению архивов (между 1991 и 2002 годами). К 2002 году вся проектная группа начала использовать распределенную систему контроля версий BitKeeper для управления кодом и его поддержки. К 2005 году было заключено партнерство между коммерческой компанией, разрабатывающей BitKeeper, и сообществом открытого исходного кода ядра Linux. комплект, они вернули себе право бесплатного использования BitKeeper. Это вынуждает сообщество Linux с открытым исходным кодом (особенно создателя Linux Линуса Торвальдса) усвоить урок, и только разработав собственную систему контроля версий, оно может не повторять тех же ошибок. С момента своего создания в 2005 году Git совершенствовался день ото дня, поддерживая свои первоначальные цели, но при этом будучи очень удобным в использовании. Он быстрый, отлично подходит для управления крупными проектами и имеет невероятную нелинейную систему управления филиалами, которая может удовлетворить различные потребности в разработке сложных проектов.

Во-вторых, установка Git

2.1 Установка в Windows

    Windows-версия официального сайта Git, после загрузки установочного пакета дважды щелкните установочный пакет exe, чтобы установить его.

После завершения установки вы можете использовать инструмент командной строки git (уже поставляется с ssh-клиентом). Щелкните правой кнопкой мыши пустое место на рабочем столе или любую папку, и появится строка меню, показанная на следующем рисунке, что означает, что установка прошла успешно.

Когда вы щелкаете меню git bash Here, вы можете увидеть окно терминала, и вы можете просмотреть информацию о версии, введя команды в терминале.

git --version

2.2. Установка на Mac

    Mac-версия официального сайта Git, после загрузки вы можете увидеть файл dmg, дважды щелкните, чтобы открыть сжатый файл, вы можете увидеть, что в нем есть файл, снова дважды щелкните файл pkg, вы можете установить его, а затем следуйте инструкциям и нажмите кнопку «Продолжить», чтобы завершить установку.

3. Инициализация Git

3.1, Конфигурация инициализации Git

потому чтоGitявляется распределенной системой контроля версий, поэтомуКаждая машина должна сообщать о себе: твойназваниеа такжеАдрес электронной почты. Эти две конфигурации очень важны.Каждый раз, когда Git фиксирует, на эти две части информации ссылаются, указывая, кто отправил обновление, поэтому оно будет постоянно включено в историю вместе с содержимым обновления. Мы можем ввести две команды в командной строке Git для настройки:

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

Чтобы проверить существующую информацию о конфигурации, вы можете использовать следующую команду:

git config --list 

3.2. Инициализировать склад

Чтобы начать управлять существующим проектом с помощью Git, просто перейдите в каталог, в котором находится проект, и выполните:

git init

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

3.3 Подробная директория .git

1. Каталог hooks содержит клиентские или серверные скрипты ловушек;
2. info содержит глобальный файл исключения
3. журналы сохранить информацию журнала
4. Каталог объектов хранит все содержимое данных;
5. В каталоге refs хранятся указатели (ветви) для фиксации объектов для данных.
6. config содержит параметры конфигурации для конкретного проекта.
7. description используется для отображения описания склада
8. Файл HEAD указывает ветку, которая в настоящее время извлечена.
9. Индексный файл сохраняет информацию о промежуточной области.

В-четвертых, использование Git

4.1 Используйте команды git для добавления текста в репозиторий

Выполните операцию отметки перед добавлением. Фактически файл сначала добавляется в кеш, а потом добавляется в репозиторий. Сначала используйте команду, чтобы сообщить Git: передайте файл Git для управления

git add

тогда расскажиGit, зафиксируйте файл в локальном репозитории

git commit -m "wrote a readme file"

    -mСледующим вводом является описание этого представления, вы можете ввести любой контент, конечножелательно иметь смысл, так что вы можете легко найти изменения из истории.git commitПосле успешного выполнения команды она сообщит вам, что 1 файл был изменен (наш недавно добавленный файл readme.txt) и были вставлены две строки содержимого (readme.txt имеет две строки содержимого).

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

4.2. Рабочая зона и зона подготовки

При выполнении операции crud в git вам необходимо выполнить операцию git add file. Базовая операция добавит файл операции в область кеша, называемую областью кеша. После завершения операции используйте операцию git commit для выполнения унифицированного представление и синхронизировать отредактированный файл равномерно.

[Не удалось передать изображение по внешней ссылке, исходный сайт может иметь механизм защиты от пиявки, рекомендуется сохранить изображение и загрузить его напрямую (img-igqUf3nC-1620290751987) (G:\Kiaodinglang\Advanced Framework\4, Git\Data \изображения\git\image35.png)]

4.3 Просмотр статуса репозитория

Как проверить текущий статус проекта? Некоторое время я писал код перед компьютером, управлял им с помощью Git, ходил в туалет посередине, затем ел яблоко и возвращался к работе.Не могу вспомнить, что я делал с Git раньше?

# 查看当前git版本库的状态(查看缓存区中的文件内容)
git status 

4.4. Просмотр журналов

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

git log

    git logКоманда отображает журнал коммитов от самого последнего к самому дальнему.Если вы считаете, что выходной информации слишком много, вы можете попробовать добавить--pretty=onelineпараметр:

git log --pretty=oneline

Мы можем видеть, что идентификатор коммита представляет собой длинную строку символов, а не число, потому что, когда два человека одновременно работают над одним и тем же кодом и делают коммит в своем соответствующем локальном репозитории, один и тот же номер коммита соответствует разным модификациям, если с использованием1,2,3Уникальность таких номеров не гарантируется, поэтомуGitиспользоватьSHA-1Генерация алгоритмаУникальный идентификатор, гарантированно уникальный в глобальном масштабе. Например, программисты A и B несут ответственность за совместную разработку программного обеспечения для чата, используяGitк контролю версий.GitЕсть распределенный контроль версий, у каждого есть репозиторий. еслиGitДля контроля версий1,2,3Если такой номер используется для генерации номера версии, возникнут проблемы при слиянии кода программиста А и Б. Кто, черт возьми, версия 1?  SVNцентрализованный контроль версий, есть только один репозиторий, поэтому номер версии можно изменить с1,2,3Начинать.Gitявляется распределенным контролем версий, у всех есть репозиторий, поэтому его нельзя скачать с1,2,3Начинать.

4.5, посмотри разницу

Если файл знает, что он был изменен, но если вы видите, что было изменено, это, естественно, лучше. Например, если вы вернулись из чужой страны в отпуск на две недели, придя на работу в первый день, вы не можете вспомнить, как меняли ее в прошлый раз.readme.txt, поэтому вам нужно использоватьgit diffВзгляните на эту команду:

# 查看不同版本之间的文件差异
git diff 

4.6, откат версии

Всякий раз, когда вы чувствуете, что файл был изменен в определенной степени, вы можете **"сохранить снимок"**, этот снимок находится вGitизвестный какcommit. Как только вы испортите файл или удалите его по ошибке, вы также можетеcommitВосстанавливайтесь и продолжайте работать вместо того, чтобы терять месяцы работы.

    GitНеобходимо знать, какой версии является текущая версия, вGitв, сHEADУказывает текущую версию, предыдущая версияHEAD^, предыдущая версия былаHEAD^^, конечно, проще написать 100^ для 100 версии выше, поэтому пишется какHEAD~100.

Если мы хотим откатить текущую версию к предыдущей версии, мы можем использоватьgit resetЗаказ:

git reset --hard HEAD^

Вернуться к указанной версии

git reset --hard <commit id>

4.7 Отмена изменений

    git checkout -- filenameИзменения рабочей области можно отменить:-- с последующим пробелом,Например:

git checkout -- readme.txt

Эта команда означает, чтоreadme.txtВсе изменения файла в рабочей области отменяются. Возможны две ситуации:

1. readme.txtОн не помещался в промежуточную зону с момента модификации (git add), теперь при отмене изменений вы вернетесь в то же состояние, что и репозиторий;
2. readme.txtПосле того, как он был добавлен в область временного хранения, он снова был изменен, теперь отмените изменение и вернитесь в состояние после добавления его в область временного хранения.

Вообще говоря, это должно вернуть этот файл к самому последнему времени.git commitилиgit addсостояние в то время.

    git checkout -- fileв команде--важно, нет--, это становится командой «переключиться на другую ветку».

4.8, удалить файлы

В обычных условиях вы обычно удаляете ненужные файлы прямо в файловом менеджере или используетеrmКоманда удалена:

git rm test.txt

4.9, управление филиалом

Git имеет мощную систему управления ветками, и в процессе разработки проекта рекомендуется использовать большое количество веток для решения проблем в различных проектах.

4.9.1 Просмотр ветки

Мы можем использовать команду для просмотра текущей ветки.

git  branch

4.9.2, создать ветку

Мы можем использовать команды для создания веток.

git  branch 分支名字

4.9.3, ветвь переключения

git checkout 分支名字

4.9.4, создать + переключить ветку

git checkout -b 分支名字

4.9.5, слить в текущую ветку

git merge 分支名

4.9.6, удалить ветку

git branch -d 分支名

Пять, нажмите команду удаленного склада

1. Инициализировать локальный репозиторий

git init

2. Установите имя пользователя облака кода и зарегистрированный адрес электронной почты облака кода.

git config --global user.name "码云里面用户名"
git config --global user.email "码云里面注册邮箱/手机"

3. Настройте игнорирование зафиксированных файлов.

4. Добавьте проект в локальный репозиторий

git add .
git commit -m "项目初始化"

5. Настройте путь запроса к удаленному репозиторию.

git remote add origin 自己在码云创建仓库路径

6. Перенесите проект crm с локального склада на удаленный склад.

git push -u origin master

7. Появится окно, введите код облачной учетной записи и пароль

Шесть, соображения по развитию команды

1. Каждый раз, когда член команды разрабатывает, он сначала отправляет в свою удаленную ветку.
2. Резервное копирование кода перед каждым слиянием или отправкой в ​​главную ветку
3. Убедившись, что в коде вашей собственной ветки и ветки master нет ошибок, протолкните локальный master на удаленный
4. Перед разработкой сначала переключитесь на основную ветку, обновите код и убедитесь, что это последняя версия.Если есть обновленный контент, также сначала сделайте резервную копию всего проекта, затем переключитесь на свою собственную ветку, а затем объедините мастер своя ветка.
5. Помимо фиксации кода в собственной ветке, вы должны слить свой собственный код в master.
6. Опять же, перед каждым мержем или пушем проект нужно делать резервную копию, чтобы избежать потери кода из-за неквалифицированных операций.

✨Прошлый отзыв

• ❤RESTful не будет, как получить 20к? ❤
• Самые полные заметки SpringBoot, вы уверены, что хотите взглянуть на основные технологии предприятия?
• Все еще думаете, что Широ сложный (ниже)?

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