После прочтения «Линии метания» книга «Подробное и практическое руководство по принципу Git» чувствует себя хорошо, поэтому я хочу написать что-нибудь, чтобы сделать резюме, то есть углубить свое впечатление, я надеюсь помочь сообществу маленький партнер, напишите, если вы не правы, подскажите. Как новичок в первой половине года, я знаю только то, что Git — это всего лишь инструмент для размещения кода, чтобы постепенно понять принцип и разницу между центральной системой контроля версий и распределенной системой контроля версий (GIT); от предыдущего только основные операции добавления, фиксации, извлечения, PUSH для использования Stash, Merge, RESET просты, благодаря глубокому пониманию принципов Git и вынуждены говорить меньше, просто войдите в тему. Длинное предупреждение впереди...
Начните с понимания систем контроля версий
Так называемый контроль версий предназначен для сохранения истории изменений в процессе изменения файла, которую можно легко отменить (точно так же, как операцию отмены редактирования текста, но контроль версий будет намного сложнее). Три основных компонента системы контроля версий: контроль версий (самая основная функция), активная фиксация (история коммитов) и удаленный репозиторий (совместная разработка).
Централизованная система контроля версий (VCS)
рабочая модель
Главный инженер устанавливает структуру проекта
Создайте удаленный склад на сервере компании и отправьте код
Другие тянут код, разрабатывают параллельно
Каждый человек самостоятельно отвечает за функцию, и разработка завершена, и код представлен
Другие могут получить код в любое время для синхронизации
Распределенная система контроля версий (DVCS)
Основное различие между распределенным и централизованным заключается в том, что, помимо удаленного хранилища, каждый член команды имеет локальное хранилище на своей машине, и каждый может отправлять код, просматривать версии, переключать ветки и т. д. на своих машинах. полностью не полагаясь на сетевое окружение. рабочая модель
Главный инженер настраивает структуру проекта и отправляет код на местный склад.
Создайте удаленный репозиторий на сервере компании и отправьте фиксацию 1 в удаленный репозиторий.
Другие клонировали все содержимое удаленного склада на локальный, имеют свой локальный склад и начинают параллельную разработку
Каждый человек отвечает за функцию независимо и может отправлять каждое небольшое изменение локальному (поскольку локальное представление не требует немедленной загрузки на удаленный склад, каждый шаг представления не обязательно должен быть завершенной функцией, но может быть шагом или блоком в функции)
После разработки функции переместите все коммиты, связанные с этой функцией, с локального на удаленный склад.
Каждый раз, когда кто-то отправляет новые коммиты в удаленный репозиторий, у других есть возможность синхронизировать эти коммиты на своем компьютере и объединить их со своим локальным кодом.
Преимущества и недостатки распределенной системы управления версиями:
преимущество
Большинство операций выполняются локально, в несколько раз быстрее, не ограничены сетевой и физическим местоположением, вы можете отправить код, истории просмотра, переключателей ветвей и т. Д.
Распространяйте и отправляйте код, а также отправляйте более подробный обзор для проверки
недостаток
Первый клон занимает много времени
Локальная занятость хранилища выше, чем у централизованных систем
Рабочая область: это каталог, который вы можете видеть на своем компьютере.
Репозиторий: в рабочей области есть скрытый каталог .git, который является не рабочей областью, а локальным репозиторием Git, где будет храниться вся информация о вашей версии.
Зона временного хранения: по-английски называется stage, или index. Обычно хранится в индексном файле (.git/index) в «каталоге .git», поэтому мы иногда называем область временного хранения индексом (index).
рабочая модель 1. Сначала создайте файл Test.txt и измените его.Вы можете просмотреть текущее состояние рабочего каталога через Статус.В настоящее время Test.txt не существует в git (Untracked)
2. Затем поместите модификацию в staging area через команду add (git начинает ее отслеживать)
Как вы можете видеть, текст test.txt стал зеленым, с отметкой «новый файл:» перед ним, а его описание изменилось с «Неотслеживаемые файлы» на «Изменения для фиксации». Все это иллюстрирует один момент: статус файла test.txt изменился с "untracked" (неотслеживаемый) на "staged" (постановочный), что означает, что измененная часть файла (то есть весь файл) записана .Вошел в зону подготовки (зона временного хранения)
Слово «стадия» в Git означает «коллективный сбор изменений для отправки», а промежуточная область — «место для сбора изменений в файлах для отправки». Называется «временное хранилище» и «зона временного хранения». Что касается поэтапного, то это означает «временно сохраненный», так что мне не нужно больше объяснять, верно?
3. Теперь, когда файл помещен в промежуточную область, вы можете отправить его с помощью команды фиксации:
Здесь вы также можете напрямую зафиксировать отправку и войти на страницу редактирования информации о фиксации, а добавление параметра -m может быстро ввести краткую информацию о примечании к отправке, чтобы вы завершили отправку (вы можете передатьgit logПосмотреть историю коммитов)
Затем снова измените файл, введитеgit statusКак видите, файл снова стал красным, но на этот раз текст слева от него не «Новый файл:», а «изменен:», а статус, отображаемый выше, не «Не отслеживается», а «не подготовлено для commit", смысл понятен: Git уже знает этот файл, это не новый файл, но в нем есть некоторые изменения. Таким образом, хотя отображение статуса немного отличается, обработка остается прежней:Затем снова добавьте и зафиксируйте файл и проверьте журнал, чтобы увидеть, что уже есть две записи фиксации.
4. Наконец, загрузите все локальные коммиты на удаленное хранилище через push:
Базовая модель работы в команде
рабочая модель 1. На основе вышеуказанных базовых операций коллега фиксирует код на своем локальном и отправляет его на удаленный склад 2. Вы вытягиваете новую фиксацию из удаленного репозитория в свой локальный с помощью команды pull.
Благодаря этому процессу вы и ваши коллеги можете просто сотрудничать: вы пишете код, фиксируете, отправляете в удаленный репозиторий, затем он извлекает в свой локальный; он пишет код, фиксирует, отправляет в удаленный репозиторий, а затем вы извлекаете в ваш местный. Вы приходите и уходите, а сотрудничать одно удовольствие. (но иногда push не удается)
Почему это не удалось? Поскольку Git push фактически использует запись фиксации локального хранилища для перезаписи записи фиксации удаленного хранилища (Примечание: это упрощенная концепция, суть push немного отличается от этой инструкции), и если удаленное хранилище содержит файлы, которые недоступны локально. При фиксации нажатие (в случае успеха) приведет к удалению удаленной фиксации. Такой результат, конечно, недостижим, поэтому Git проверит при отправке, и если это произойдет, отправка завершится ошибкой.
Тогда вам просто нужно пройтиgit pull(фактически комбинация выборки и слияния) Объедините представление локального хранилища с представлением удаленного хранилища, а затем нажмите его.
Ветвление функций: самый популярный рабочий процесс
основной: (1) Любые новые функции или исправления ошибок пишутся в новой ветке; (2) После того, как ветка написана, объедините ее с мастером, а затем удалите ветку (вы можете использоватьgit origin -d 分支名удалить ветку удаленного репозитория).
Преимущество: (1) Совместное использование кода: после написания вы можете объединиться с основной веткой после просмотра ветки разработки. (2) Многозадачность одним человеком: когда вы разрабатываете и получаете более важные новые задачи, вам нужно только ненадолго завершить незавершенный в данный момент код, а затем сделать коммит с отметкой «незавершенный» (например, в сообщении о коммите. Отметьте в нем «TODO»), затем вернитесь к мастеру, чтобы создать новую ветку для разработки.
Характер HEAD, ветки, цитирования и характер push
HEAD: ссылка на текущий коммит
Где текущий коммит, там и HEAD Это ссылка, которая всегда автоматически указывает на текущий коммит, поэтому вы всегда можете использовать HEAD для управления текущим коммитом.
ветвь:
HEAD — это уникальная ссылка в Git, она уникальна. В дополнение к HEAD в Git также есть ссылка, называемая веткой. Помимо указания на коммит, HEAD также может указывать на ветку.При указании на ветку HEAD будет косвенно указывать на текущий коммит через ветку, а перемещение HEAD будет двигаться вместе с веткой:
ветка содержит все пути от начального коммита до него, а не только один путь. Кроме того, эти пути равны друг другу.
Как показано выше, у мастера есть два пути от начальной фиксации к мастеру после слияния ветки 1. На данный момент основная строка содержит два пути: 1 2 3 4 7 и 1 2 5 6 7. Кроме того, эти два пути равны, путь 1 2 3 4 7 не имеет ничего особенного, потому что это «собственный путь».
Создать ветку:git branch 名称 Переключить ветки:git checkout 名称(указать ГОЛОВОЙ на ветку) Создать + переключатель:git checkout -b 名称 После переключения на новую ветку при повторном коммите HEAD переместится вместе с новой веткой:В это время, если вы снова переключитесь на master для коммита, появится настоящий форк:Удалить ветку:git branch -d 名称 Уведомление: (1) Ветвь, на которую указывает HEAD, не может быть удалена. Если вы хотите удалить ветку, на которую указывает HEAD, вам нужно использовать checkout, чтобы указать HEAD в другом месте. (2) Поскольку ветка в Git является просто ссылкой, операция удаления ветки удалит только эту ссылку и не удалит никаких коммитов. (Однако, если фиксация не находится на «пути» какой-либо ветки, или, другими словами, если ни одна ветвь не может вернуться к фиксации (может быть, назвать это дикой фиксацией?), то через определенное время она будет механизм рециркуляции Git удален) (3) Из соображений безопасности ветки, которые не были объединены в основную, не могут быть удалены (из-за опасения случайного удаления и неполной ветки).Замена -d на -D может привести к принудительному удалению
Суть цитирования
Так называемая ссылка на самом деле является строкой. Эта строка может быть кодом SHA-1 коммита (например, c08de9a4d8771144cd23986f9f76c4ed729e69b0) или ветки (например, ref: refs/heads/feature3).
HEAD и каждая ветка и другие ссылки в Git хранятся в локальном репозитории.
Суть push: загрузить ветку на удаленный склад
(1) Загрузите текущее местоположение ветки на удаленный склад и вместе загрузите коммиты по его пути. (2) В git (версия 2.0 и выше),git pushБез параметров его можно только залить в ветку с удаленного склада клонировать или тянуть.Если вы хотите запушить созданную локально ветку, вам нужно использоватьgit push origin 分支名Команда (3) ГЛАВА удалённого склада не согласуется с локальным при пуше.ГЛАВА удалённого склада всегда указывает на ветку по умолчанию (мастер) и перемещается вместе с ней (можно использоватьgit br -rПосмотрите, на что указывает HEAD удаленной ветки).
Начните путешествие по работе с git
сливаться: сливаться
Значение: из разветвленной позиции целевого коммита и текущего коммита (то есть коммита, на который указывает HEAD) применить содержимое всех коммитов на пути целевого коммита к текущему коммиту, а затем автоматически сгенерировать новый совершить.
при исполненииgit merge branch1В операции Git применит содержимое двух коммитов 5 и 6 к 4 вместе, а затем сгенерирует новый коммит 7 . Частный случай слияния: (1) Конфликт слияния: две ваши ветки изменили один и тот же контент, и Git не знает, какой из них должен превалировать. Если это произойдет во время слияния, Git оставит эту проблему на ваше усмотрение. В частности, он сообщит вам об ошибке слияния и причине сбоя; в настоящее время вам нужно только вручную разрешить конфликт, а также повторно добавить и зафиксировать (изменение разных файлов или разных строк одного и того же файла не вызовет конфликтов). ; или используйтеgit merge --abortОтказаться от разрешения конфликта, отменить слияние (2) HEAD ведет целевую фиксацию: слияние не выполняется:Merge не будет отвечать в этот момент. (3) HEAD находится за целевым коммитом, и ветки нет (ускоренная перемотка вперед): git напрямую переместит HEAD и ветку, на которую он указывает (если есть), в целевой коммит.
rebase: сбросить базовую точку для последовательности фиксации
Некоторым людям не нравится слияние, потому что после слияния история коммитов будет разветвляться, и эта структура разветвления и повторного слияния заставит некоторых людей чувствовать себя хаотичными и трудными для управления. Если вы не хотите, чтобы история коммитов разветвлялась, вы можете использовать rebase вместо слияния.
Видно, что через rebase 5 и 6 коммит изменили базовую точку с 2 на 4. Таким образом, история разветвленных коммитов возвращается к строке. Эта операция «сброса базовой точки» и есть смысл перебазирования. Кроме того, после перебазирования не забудьте вернуться к мастеру и снова выполнить слияние, а также переместить мастер на последний коммит.
Почему так сложно перебазировать из ветки 1, затем вернуться к мастеру и снова слить вместо того, чтобы выполнять перебазирование непосредственно на мастере?
Как видно из рисунка, хотя содержимое каждого коммита после ребейза такое же, как и до ребейза, это уже разные коммиты (каждый коммит имеет уникальный признак). Если rebase выполняется непосредственно из мастера, это будет выглядеть так:
Это приводит к тому, что два предыдущих последних коммита (3 и 4) на мастере отбраковываются. Если эти два коммита уже существовали в удаленном репозитории ранее, это сделает невозможным отправку:Поэтому во избежание конфликтов с удаленными хранилищами вообще не выполняйте операции перебазирования с master на другие ветки. И если это перебазирование между ветвями, отличными от master (например, между ветками1 и ветвями2), нет необходимости предпринимать так много шагов, просто выполняйте перебазирование напрямую.
Следует отметить, что rebase работает с фиксацией, которую необходимо перебазировать, что отличается от слияния.
тайник: временное хранилище изменений в рабочем каталоге
Команда stash может помочь вам поместить все содержимое рабочего каталога в отдельное место в вашей локальной области. Оно не будет отправлено или удалено. После того, как вы уберете вещи, вы можете заняться своей временной работой. Делайте, когда закончите , возьмите его снова, и вы можете продолжить работу. Шаги: (1)git stashВы можете добавить примечания после параметра сохранения (git stash save '备注信息') (2) На данный момент рабочий каталог пуст, и вы можете переключиться на другие ветки, чтобы заняться другими делами. (3)git stash popоткрыть первый тайник (который удален из исторического тайника); или использоватьgit stash applyЧтобы добиться того же эффекта (тайник все еще существует в списке тайников), вы можете использоватьgit stash listПросмотрите историю тайника и вернитесь к этому тайнику, добавив указанный тайник после применения. Примечание. Файлы, которые не отслеживаются, будут игнорироваться git, а не храниться.Если вы хотите хранить их вместе, добавьте параметр -u.
reflog: журнал ссылочной записи
Вы можете просмотреть эталонную запись git, без указания параметров, по умолчанию отображается эталонная запись HEAD; если ветка случайно удалена, вы можете использовать эту команду для просмотра эталонной записи, а затем использовать checkout для обрезки до записи и восстановить ветку.
Примечание. Коммиты, на которые больше не ссылаются прямо или косвенно, будут возвращены Git через определенный период времени, поэтому операция использования reflog для извлечения удаленной ветки должна быть своевременной, иначе она может не быть найдена снова, потому что фиксация восстановлена. вернуть.
посмотри что я изменил
log: Просмотр отправленного контента
git log -pМожет просматривать сведения об изменении каждой фиксации (каждой строки измененного файла) git log --statПосмотреть краткую статистику (какие файлы изменились) git show 指定commit 指定文件名Просмотр сведений об изменении указанного файла для указанной фиксации
diff: просмотреть незафиксированный контент
git diff --stagedМожет показать разницу между промежуточной областью и последним коммитом. Другими словами, эта команда позволяет вам увидеть, «что бы вы зафиксировали, если бы немедленно набрали git commit». git diffМожно отобразить разницу между рабочим каталогом и промежуточной областью. Другими словами, эта команда позволяет вам увидеть, «если вы добавите все файлы сейчас, что вы добавите в промежуточную область». git diff HEADМожно отобразить разницу между рабочим каталогом и предыдущим коммитом, которая представляет собой сумму содержимого двух вышеуказанных. Другими словами, эта команда позволяет вам увидеть, «если вы добавите все файлы сейчас, а затем зафиксируете git, что вы зафиксируете» (хотя обратите внимание, что файлы, которые не задокументированы Git (т.е. никогда не добавлялись). Если вы измените HEAD на другой коммит, вы также можете отобразить разницу между текущим рабочим каталогом и этим коммитом.
Что делать, если код, который я только что отправил, окажется неверным?
Еще один коммит, исправляющий ошибку? Можно, но есть более элегантное и простое решение: commit --amend. специальные методы: (1) Устраните проблему (2) Добавьте модификацию в область временного хранения (3) использоватьgit commit --amendОтправьте модификацию, результат будет следующим:
Уменьшено количество ненужных коммитов.
Баг не последний коммит, а предпоследний?
Используйте rebase -i (интерактивная перебазировка): Так называемая «интерактивная перебазировка» означает, что перед выполнением операции перебазирования вы можете указать, нужно ли дополнительно модифицировать каждую фиксацию в цепочке коммитов, подлежащих перебазированию, а затем вы можете использовать эту функцию для выполнения «перебазирования на месте». ".
Процесс работы: (1)git rebase -i HEAD^^
Примечание. В Git есть два «символа смещения»: ^ и ~. Использование ^: добавьте один или несколько знаков ^ после коммита, чтобы сместить коммит назад, а количество смещений равно количеству ^. Например: master^ означает фиксацию перед фиксацией, на которую указывает master; HEAD^^ означает, что фиксация, на которую указывает HEAD, находится на две фиксации раньше. Использование ~: добавьте знак ~ и число после коммита, чтобы сместить коммит обратно.Число смещений — это число после знака ~. Например: HEAD~5 означает, что фиксация, на которую указывает HEAD, опережает 5 коммитов.
Приведенная выше строка кода означает перебазирование текущего коммита (коммита, на который указывает HEAD) на коммиты, предшествующие HEAD:
(2) Войдите на страницу редактирования, выберите операцию, соответствующую фиксации, фиксация в положительном порядке, старая вверху, новая внизу, желтая впереди - как управлять фиксацией , выбор по умолчанию (коммит применяется напрямую без каких-либо изменений), Измените первый коммит для редактирования (примените этот коммит, затем остановитесь и дождитесь исправления), а затем :wq для выхода со страницы редактирования, в это время ребазирование останавливается в позиции второго коммита, и в это время содержимое может быть изменено:(3) Используйте добавить после модификации, commit --amend изменит отправку (4)git rebase --continueПродолжите процесс перебазирования и примените следующие коммиты напрямую.Интерактивный процесс перебазирования завершен идеально, и ваш предпоследний неправильно написанный коммит также исправлен:
Хотите просто отказаться от коммита?
reset --hard отказаться от последней фиксации
git reset --hard HEAD^
HEAD^ означает, что HEAD отсчитывает коммиты на одну позицию назад, как только что упоминалось в предыдущем разделе, помните?
Отмена исторических коммитов с помощью интерактивной перебазировки
Этапы операции аналогичны отправке истории изменений, на втором этапе коммит, который необходимо отозвать, заменяется на удаляемый, а остальные шаги повторяться не будут.
Отменить коммит с помощью rebase --onto
git rebase --onto HEAD^^ HEAD^ branch1 Вышеупомянутая строка кода означает: начиная с предпоследнего коммита (начальная точка не включена в последовательность перебазирования), ветвь 1 в качестве конечной точки и перебазировать до предпоследнего коммита.
Код ошибки был отправлен?
Иногда код отправляется на удаленное хранилище только для того, чтобы обнаружить, что фиксация написана неправильно. Есть два способа справиться с этой проблемой:
Содержание ошибки находится в отдельной ветке
Если ветка, которую вы самостоятельно разработали, пойдет не так и не повлияет на другие, то вы можете использовать методы, описанные в предыдущих разделах, чтобы изменить или удалить неправильно написанный коммит, а затем отправить его вверх. Но в это время будет сообщено об ошибке push, потому что удаленный репозиторий содержит коммиты, которые недоступны локально (были заменены или удалены локально), поэтому используйте его непосредственно в это время.git push origin 分支名 -fСиловой толчок.
Содержимое задачи было объединено с основной
(1) Добавьте новую отправку, чтобы покрыть предыдущий контент (2) использоватьgit revert 指定commitЕго использование очень простое, вы хотите отменить коммит, просто заполните его сзади. Такие как:git revert HEAD^ Вышеупомянутая строка кода добавит новую фиксацию, содержимое которой противоположно содержанию предпоследней фиксации, тем самым сместив предпоследнюю фиксацию для достижения эффекта отзыва. После завершения возврата снова нажмите новую фиксацию, и содержимое фиксации будет отозвано. По сравнению с методом отзыва, описанным выше, основное отличие состоит в том, что это изменение является только «обратным» и не исчезло в истории.В вашей истории будет две фиксации: исходная фиксация, обратная фиксация к ней.
reset: больше, чем просто отмена коммитов
git reset --hard 指定commitСодержимое вашего рабочего каталога будет полностью сброшено до того же содержимого, что и указанное место фиксации. Другими словами, ваши незафиксированные изменения будут стерты. git reset --soft 指定commitПри сбросе HEAD и ветки содержимое рабочего каталога и промежуточной области будет сохранено, а новые различия, вызванные сбросом HEAD, будут помещены в промежуточную область. В чем "новое отличие от сброса HEAD"? Прямо здесь:
git reset --mixed（或者不加参数） 指定commitСохраните рабочий каталог и очистите промежуточную область. То есть изменения в рабочем каталоге, содержимое промежуточной области и новые различия в файлах, вызванные сбросом, будут помещены в рабочую область. Короче говоря, «смешайте все различия в рабочей области».
checkout: проверить указанную фиксацию
Суть checkout заключается в проверке указанного коммита.Можно не только переключать ветки, но и указывать коммит в качестве параметра для перемещения HEAD на указанный коммит, отличие от reset в том, что только перемещение HEAD не меняет привязку ветвь;git checkout --detachВы можете отсоединить HEAD от ветки и указать прямо на текущий коммит.
наконец
Я надеюсь, что мое резюме может помочь вам, и я надеюсь применить то, что вы узнали, и расти вместе. Наконец, я хотел бы поблагодарить буклет учителя метания, Amway «Подробное объяснение и практическое руководство по принципам Git» и найти линию метания.