Обзор наиболее распространенных проблем с Git и контрольные списки действий

Git

введение

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

1. Необходимые очки знаний

56352098-1d71d700-6201-11e9-9c1b-2d1242749a49

склад

  1. Remote:удаленный главный репозиторий;
  2. Репозиторий:местный склад;
  3. Показатель:Дерево отслеживания Git, промежуточная область;
  4. Рабочее пространство:локальное рабочее пространство (т.е. код вашего редактора)

2. git add отправляется в staging area, что делать, если есть ошибка

Общий процесс отправки кода выглядит следующим образом:Рабочее пространство -> git statusПосмотреть статус ->git add .добавить все изменениякеш хранения-> git commit -m "提交描述"Код будет отправлен наместный склад -> git pushОбновите код локального репозитория доудаленный склад

Сценарий 1: Рабочая область

Если вы испортили содержимое файла в рабочей области и хотите напрямую отменить изменения в рабочей области, используйте командуgit checkout -- file.

// 丢弃工作区的修改
git checkout -- <文件名>

Сценарий 2: плацдарм

При изменении не только нарушается содержимое файловой рабочей области, но иgit addКогда он добавляется в область временного хранения, если вы хотите отказаться от модификации, он делится на два шага.Первый шаг - использовать командуgit reset HEAD <file>, он возвращается к сцене 1, и второй шаг заключается в работе в соответствии со сценой 1.

// 把暂存区的修改撤销掉（unstage），重新放回工作区。
git reset HEAD <文件名>

3. git commit отправлен на локальный склад, что делать, если есть ошибка?

1. Ошибка при отправке информации

Изменить информацию о коммите

git commit --amend -m“新提交消息”

2. Отсутствующие коммиты

При фиксации есть два решения для отказа от отправки частичных обновлений:

  • Вариант 1: снова зафиксировать

    git commit -m“提交消息”

    На данный момент в git будет два коммита.

  • Вариант 2: отправить отсутствующий файл в предыдущую фиксацию

    git add missed-file // missed-file 为遗漏提交文件
git commit --amend --no-edit

    --no-editУказывает, что сообщение коммита не изменится, только один коммит на git

3. Отправьте неправильный файл, откатитесь к предыдущей версии фиксации и снова зафиксируйте

git reset

удалить указанный коммит

// 修改版本库，保留暂存区，保留工作区
// 将版本库软回退1个版本，软回退表示将本地版本库的头指针全部重置到指定版本，且将这次提交之后的所有变更都移动到暂存区。
git reset --soft HEAD~1

// 修改版本库，修改暂存区，修改工作区
//将版本库回退1个版本，不仅仅是将本地版本库的头指针全部重置到指定版本，也会重置暂存区，并且会将工作区代码也回退到这个版本
git reset --hard HEAD~1
// git版本回退，回退到特定的commit_id版本，可以通过git log查看提交历史，以便确定要回退到哪个版本(commit 之后的即为ID);
git reset --hard commit_id
git revert

Отменить операцию, фиксация и история до и после этой операции будут сохранены, и эта операция будет отменена.

как актуальная фиксация

// 撤销前一次 commit
git revert HEAD
// 撤销前前一次 commit
git revert HEAD^
// (比如：fa042ce57ebbe5bb9c8db709f719cec2c58ee7ff）撤销指定的版本，撤销也会作为一次提交进行保存。
git revert commit

git revertпредставить новую версию, которая потребуетrevertСодержание версии перевернуто и изменено обратно, Версия будет увеличена, не затрагивая предыдущие отправки

git revertа такжеgit resetразница
  • git revertИспользовать новую фиксацию для отката предыдущей фиксации,git resetзаключается в том, чтобы удалить указанный коммит напрямую.
  • С точки зрения отката эффект аналогичен. Но есть разница при продолжении слияния предыдущей старой версии в будущем. потому чтоgit revertОн использует обратную фиксацию, чтобы «нейтрализовать» предыдущую фиксацию, поэтому, когда старая ветка будет объединена в будущем, эта часть изменения не появится снова, ноgit resetНекоторые коммиты удаляются в ветке, поэтому при повторном слиянии со старой веткой эти откатные коммиты все равно должны быть введены.
  • git resetэто переместить ГОЛОВУ немного назад, иgit revertЭто HEAD продолжает двигаться вперед, но содержимое нового коммита является противоположным содержимому, подлежащему возврату, что может компенсировать содержимое, подлежащее возврату.

4. Общие команды

1. Начальный процесс разработки git

  • Клонировать последний код проекта основной веткиgit clone 地址
  • Создать локальную веткуgit branch 分支名
  • Посмотреть местный филиалgit branch
  • Просмотр удаленных ветокgit branch -a
  • переключить веткуgit checkout 分支名(Вообще, если модификация не отправлена, то ее нельзя переключить. Часто случаются проблемы, и ее можно принудительно переключить.git checkout 分支名 -fНе нужно использовать с осторожностью)
  • нажать локальную ветку на удаленную веткуgit push <远程仓库> <本地分支>:<远程分支>

2. git fetch

Возьмите обновление удаленного хоста, все / ветку обратно на локальный (репозиторий в это время обновляется) Код, который он извлекает, не влияет на ваш локальный код разработки. Если вам нужно полное обновление, вам нужно объединить или использоватьgit pull

3. git pull

Извлеките обновление ветки удаленного хоста, а затем объедините его с указанной локальной веткой (эквивалентно операции выборки плюс функция слияния веток)

4. git push

Отправьте обновление локальной ветки на удаленный хост, формат команды такой же, какgit pullсходство

5. Работа филиала

  • Команда для загрузки указанной ветки с помощью Git:git clone -b 分支名仓库地址
  • Вытащить удаленную новую веткуgit checkout -b serverfix origin/serverfix
  • Объединить локальную веткуgit merge hotfix: (слить ветку исправления в текущую ветку)
  • Объединить удаленные веткиgit merge origin/serverfix
  • удалить локальную веткуgit branch -d hotfix: (удалить локальную ветку исправлений)
  • удалить удаленную веткуgit push origin --delete serverfix
  • Загрузите новую локальную ветку:git push origin newName;
  • Создайте новую ветку:git branch branchName: (создает локальную ветку с именем branchName )
  • Переключитесь на новую ветку:git checkout branchName: (переключиться на ветку branchName)
  • Создавать и переключать ветки:git checkout -b branchName: (эквивалент комбинации двух вышеуказанных команд)
  • Загляните в местную ветку:git branch
  • Посмотреть все ветки удаленного репозитория:git branch -a
  • Переименование локальной ветки:git branch -m oldName newName
  • Переименуйте локальную ветку, соответствующую удаленной ветке:git branch -m oldName newName
  • Свяжите измененную локальную ветку с удаленной веткой:git branch --set-upstream-to origin/newName

В-пятых, оптимизировать работу

1. Вытащите код pull --rebase

Во время командной работы предполагается, что у вас и ваших коллег есть свои новые коммиты локально, и ваши коллеги предшествуют вам.pushкод в удаленную ветку, поэтому вы должны сначала выполнитьgit pullчтобы получить коммиты пира, прежде чем вы сможетеpushсобственные коммиты в удаленную ветку.

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

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

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

                 A---B---C  remotes/origin/master
                /
           D---E---F---G  master

Если он выполняетсяgit pullПосле отправки линейный график будет выглядеть так:

                 A---B---C remotes/origin/master
                /         \
           D---E---F---G---H master

больше результатовHЭта ненужная запись коммита. Если он выполняетсяgit pull --rebase, линейный график фиксации будет выглядеть так:

                       remotes/origin/master
                           |
           D---E---A---B---C---F'---G'  master

F GПройдено два коммитаrebaseспособ присоединиться кCПосле этого лишние вилки убираются, и цель достигается.

резюме

Чаще всего используйтеgit pull --rebaseЦель состоит в том, чтобы сделать линейный график фиксации лучше и облегчить проверку кода.

Однако, если вы не очень хорошо разбираетесь в git, я предлагаюgit pull --rebaseПотренируйтесь несколько раз, прежде чем использовать его, потому чтоRebase — это «опасное поведение» в git.

Кроме того, следует отметить, что использованиеgit pull --rebaseЛегче вызвать конфликты, чем напрямую тянуть.Если ожидается больше конфликтов, рекомендуется тянуть напрямую.

Уведомление:

git pull = git fetch + git merge

git pull --rebase = git fetch + git rebase

2. Объединить слияние кода --no-ff

вышеупомянутыйgit pull --rebaseЦель стратегии — обрезать линейный график коммита так, чтобы он образовывал прямую линию, а предстоящийgit merge --no-ff <branch-name>Стратегия состоит в том, чтобы пойти другим путем, заведомо разветвляя линейный график подчинения.

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

воплощать в жизньgit merge --no-ff <branch-name>Результат, вероятно, будет выглядеть так:

git merge --no-ff

Схема средней вилки ясно показывает, что эти коммиты предназначены для реализацииcomplete adjusting user domains and tags

Сделайте еще один шаг вперед

Часто моя привычка — проверять, не «частично ли отстает» функциональная ветвь перед объединением ветки (скажем, вы хотите локально объединить функциональную ветвь с ветвью разработки)Удаленная ветвь Dev.:

git checkout dev
git pull # 更新 dev 分支
git log feature..dev

Если информация о коммите не выводится, функция актуальна для ветки разработки. Если есть вывод, он будет выполнен немедленноgit merge --no-ff, линейный график фиксации будет выглядеть так:

git-merge

Итак, в это время перед слиянием я обычно выполняю:

git checkout feature
git rebase dev

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

Напоминание: как упоминалось ранее, rebase — это «опасное поведение», и рекомендуется делать это только тогда, когда вы достаточно знакомы с git, иначе это не будет стоить вреда.

Суммировать

использоватьgit pull --rebaseа такжеgit merge --no-ffФактически и прямое использованиеgit pull git mergeПолученный код должен быть таким же.

использоватьgit pull --rebaseОсновная цель состоит в том, чтобы сгладить линейный график представления, иgit merge --no-ffЭто преднамеренное создание форка.

6. SSH

1. Проверьте, сгенерирован ли открытый ключ SSH.

$ cd ~/.ssh
$ ls
id_rsa      id_rsa.pub      known_hosts

где id_rsa — закрытый ключ, а id_rsa.pub — открытый ключ.

2. Если нет, начните генерировать, установите глобальные user.name и user.email

git config --list // 查看是否设置了user.name与user.email，没有的话，去设置
// 设置全局的user.name与user.email
git config --global user.name "XX"
git config --global user.email "XX"

3. Введите ssh-keygen (илиssh-keygen -t rsa -C "email")

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/schacon/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/schacon/.ssh/id_rsa.
Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub.
The key fingerprint is:

4. Получите содержимое открытого ключа после генерации, введите cat ~/.ssh/id_rsa.pub, скопируйте ssh-rsa на все содержимое .local

$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== schacon@agadorlaptop.local

5. Откройте GitLab или GitHub, нажмите на аватарку и найдите страницу настроек

6. Найдите кнопку SSH-ключей слева и нажмите ее, введите открытый ключ, который вы только что скопировали.

7. Временное хранение

git stashЕго можно использовать для временного хранения текущей выполняемой работы.Например, если вы хотите получить последний код, но не хотите его фиксировать, или для того, чтобы изменить срочную ошибку, сначала спрячьте, чтобы вернуться к вашему последнему коммиту, и затем всплывайте после исправления ошибки и продолжайте исходную работу;

  • Добавить стек кеша:git stash ;
  • Просмотрите стек кеша:git stash list ;
  • Нажмите стек кеша:git stash pop ;
  • Получить определенное содержимое кеша:git stash apply stash@{1} ;

Восемь, имя файла слишком длинное, ошибка

Filename too long warning: Clone succeeded, but checkout failed.

git config --system core.longpaths true

9. Электронная почта и имя пользователя

Проверить

git config user.name

git config user.email

Исправлять

git config --global user.name "username"

git config --global user.email "email"

10. После обновления .gitignore вступит в силу:

git rm -r --cached .
git add .
git commit -m ".gitignore is now working”

11. Синхронизируйте ветку с форка Github

1. Настройте удаленный доступ так, чтобы он указывал на исходный склад.

git remote add upstream https://github.com/InterviewMap/InterviewMap.git

2. Верхний репозиторий получает ветку и соответствующую информацию об отправке, которая будет сохранена в локальной восходящей/главной ветке.

git fetch upstream
# remote: Counting objects: 75, done.
# remote: Compressing objects: 100% (53/53), done.
# remote: Total 62 (delta 27), reused 44 (delta 9)
# Unpacking objects: 100% (62/62), done.
# From https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY
# * [new branch] master -> upstream/master

3. Переключитесь на локальную основную ветку

git checkout master
# Switched to branch 'master'

4. Объедините вышестоящую/главную ветвь с локальной главной ветвью, и локальная главная ветвь будет синхронизирована с вышестоящим хранилищем, и никакие локальные модификации не будут потеряны.

git merge upstream/master
# Updating a422352..5fdff0f
# Fast-forward
# README | 9 -------
# README.md | 7 ++++++
# 2 files changed, 7 insertions(+), 9 deletions(-)
# delete mode 100644 README
# create mode 100644 README.md

5. Загрузить на свой удаленный склад

git push

Ссылаться на

Эта статья относится кGit для очистки: потяните --rebase и слейте --no-ff

серия статей

Хотите увидеть больше статей в серии,Нажмите, чтобы перейти на домашнюю страницу блога github.

Прогулка в конце, добро пожаловать, чтобы обратить внимание: джентльмен переднего конца бутылки, ежедневное обновление

前端瓶子君

Категории