Здесь нужно учитывать несколько важных вещей. Вот два верхних:
- Git распространяется , то есть задействовано много разных компьютеров. У каждого может быть свое представление о том, что к чему.
- GitHub - это не Git! GitHub - хостинговая компания, которая предлагает Git-сервис. Они скрывают фактическую реализацию Git с причудливым интерфейсом. Этот необычный интерфейс не является частью Git, и многие из них практически не используют Git.
Теперь фрагмент изображения, который вы показываете, взят из GitHub. Таким образом, он показывает вам, что говорит GitHub , что в буквальном смысле не имеет ничего общего с тем, что вы можете установить сейчас в своем собственном репозитории Git. может иметь отношение к чему-то, что вы установили ранее - ранее сегодня, или вчера, или когда-либо - в своем хранилище Git.
git config --list урожайность ...
Это настройки, которые вы установили на вашем компьютере. Вы можете изменить их в любое время.
Обратите внимание, что есть два (или более) разных места для ваших личных настроек. Git называет это --global и --local. Git 2.20 и 2.21 добавили одну новую --worktree, которую вы, вероятно, не используете. Используйте git config --list --show-origin, чтобы увидеть, в каком месте хранится какой параметр.
.... элементы, связанные с удаленными филиалами
username.user=myUserName -> This is correct
username.email="myname@gmail.com" -> This is correct
Это может быть , правильно , но я не могу найти ничего, что использует настройку username.user или username.email. (Возможно, что-то и есть, но Git позволяет вам установить что-либо на что-либо без жалоб. Если бы вы должны были установить, например, zaphod.beeblebrox=heads:2 для некоторого программного обеспечения, но вместо этого случайно запустили git config hoopy.frood towel, у Git не было бы жалоб об этом - и ничего не значит для Git .)
push.default=current
pull.default=current
Первый имеет смысл, но, как правило, большинство людей должны оставить значение по умолчанию push.default на simple. Второе не имеет значения.
user.email="myname@gmail.com"
Это, без сомнения, правильно. Остальное, которое отсутствует из приведенного вами списка, это user.name.
Теперь важно понимать, что user.name и user.email используются вашим Git только когда вы используете Git для создания нового коммита . В то время, когда вы делаете коммит, Git читает эти две настройки. Все, что в них, входит в новый коммит. Новый коммит, когда-то сделанный, заморожен на все времена. Вы можете сделать другие коммиты с различными настройками имени пользователя и / или электронной почты, и если только что сделанный вами коммит имел неправильные настройки, вы, вероятно, должны сделать еще один коммит Но любой сделанный вами коммит, в котором есть неправильный материал, содержит этот неправильный материал forever .
Это не так плохо! Вы не должны продолжать использовать неправильный коммит вообще. Если вы сделали неправильный коммит, вы можете, например, изменить вещи и запустить git commit --amend, чтобы выбросить неправильный коммит и заменить его на лучший. Выброшенный остается в вашем репозитории, но он удален с пути, где вы - и все остальные - не можете его увидеть, и он не будет отправлен другому Git, когда вы запустите git push. И вы можете исправить больше, чем просто последний коммит, например, используя git rebase -i --reset-author. Как и --amend, он не не изменяет никаких коммитов; вместо этого он создает новые и улучшенные и перестает использовать старые и паршивые. 1
Имя пользователя и адрес электронной почты, заданные вами в вашей конфигурации, которые были скопированы в любой уже сделанный вами коммит, отображаются при запуске git log. Эти два элемента - имя пользователя и адрес электронной почты - могут быть все, что вы хотите . Никто и ничто не может помешать вам использовать имена других людей и адреса электронной почты здесь. Эти коммиты поступают в ваш репозиторий, на ваш компьютер, и вы можете делать все, что захотите со своим собственным компьютером.
Но теперь, когдавы сделали новые коммиты, теперь вы можете захотеть, чтобы ваш Git отправил эти новые коммиты в какой-то другой репозиторий Git. Этот другой Git-репозиторий можно разместить где угодно, в том числе, возможно, на GitHub. Если вы действительно отправляете новый коммит в GitHub, они не просто поверят, что вы - Барак Обама или кто-то еще. Итак, теперь вы должны аутентифицировать самостоятельно. Вот где эта настройка может войти в игру:
credential.helper=osxkeychain
Если вы подключаетесь к GitHub через https, Git нужно будет использовать помощник по учетным данным, и это скажет ему, какой из них использовать. Если вы подключаетесь к GitHub через ssh, у ssh есть свои независимые механизмы; эта credential.helper настройка будет игнорироваться.
Я тоже не могу вносить изменения ... Что не так?
Возможно, одна или обе из двух вещей:
Ваша попытка аутентификации на GitHub не удалась: они не верят, что вы являетесь тем, кем вы себя называете.
Или они делают считают, что вы являетесь тем, кем себя называете, но у этого человека нет разрешения на толчок.
Судя по тому, что вы разместили здесь, мы не можем сказать, какой из них имеет место. Но сообщение об ошибке, которое GitHub доставляет обратно в ваш Git, и ваш Git передает вам, будет сообщать вам, какой из этих случаев (или это какая-то менее очевидная возможность). Итак, выясните, как вы проходите проверку подлинности (или не можете выполнить проверку подлинности), и если это удается, есть ли у вас разрешение на отправку. Исправьте, что из этого является проблемой (возможно, оба).
Как только вы преодолеете все эти проблемы, последний камень преткновения таков: Git pushes commits . Помните, что мы говорили ранее, что все коммиты заморожены во времени навсегда. Когда ваш Git отправляет свой Git коммит, ваш Git передает хеш-идентификатор - уникальное имя, которое сопровождает , который коммит, и только , который фиксирует; ни у какого другого коммита нет такого хэш-идентификатора, и, если у него еще нет этого коммита, ваш Git передает все, что им нужно, чтобы он тоже мог иметь этот коммит.
Итак, после того, как весь этот сумасшедший механизм Rube-Goldberg-esque передал ваши коммиты в репозиторий Git, хранящийся на GitHub, у них будет новый набор коммитов - может быть, только один коммит, может быть, целая строка их, которых у них не было раньше. Ваш Git, в конце концов, попросит, чтобы его Git установил одно из их названий веток или создал новое имя ветки, чтобы запомнить последний из этих коммитов. 2 GitHub затем берет адрес электронной почты , хранящийся в этих фиксированных фиксациях, и ищет их в гигантской базе данных.
База данных о том, как GitHub (не Git!) Решает , кто совершил коммит. GitHub и его база данных должны поддерживать этот перевод в рабочем состоянии. У них есть пара разных причудливых схем для этого; см., например, https://help.github.com/en/articles/what-happens-when-i-change-my-username и соответствующие статьи. У них также есть способы управления тем, какие адреса электронной почты они будут считать «вами», когда они увидят эти адреса электронной почты в существующих замороженных коммитах.
Если вы работаете с Git из командной строки, в своем собственном хранилище на своем компьютере вы увидите, что хранит Git. Если вы работаете с веб-интерфейсом GitHub, вы увидите, что GitHub переводит в , из того, что хранится в Git. Фактическое хранилище находится в самих коммитах, поэтому до тех пор, пока вы не сохраните коммиты в Git-репозитории на GitHub, GitHub не может выполнять какой-либо перевод.
1 Если вы уже отправили неверный коммит на другой Git, запустив git push, , тогда возникла проблема. Это не обязательно большая проблема, но хорошо быть уверенным, что у вас есть правильные коммиты, прежде чем вы запустите git push. Гораздо проще отбрасывать плохие коммиты в пользу улучшенных коммитов замены до , когда вы разбрасывали эти плохие коммиты на миллионы других клонов Git по всей вселенной ... или даже на одного другого клона Git, размещенного на GitHub или что угодно. Однако реальная точка зрения в том, что вы не можете изменить коммит, вы можете заменить его только новым и улучшенным коммитом. Если вы сделаете это прежде, чем кто-либо еще что-нибудь увидит, они никогда не узнают, что вы совершили неправильный коммит!
2 Последний коммит автоматически запоминает хэш-идентификатор предыдущего. Это родитель последнего коммита. Родительский коммит запоминает его родительский элемент, который запоминает другого родителя и т. Д., Поэтому с end Git может работать обратно к началу. Эта оглядывающаяся назад цепь - это история в хранилище! Начать с конца, показать коммит и вернуться к его родителю - это то, как вы или кто-либо другой можете просмотреть историю. Коммиты с их отношениями - родитель, потомок, брат или сестра или вообще не связаны - определяют историю, хранящуюся в хранилище. имена ветвей просто служат для поиска последнего коммитов.