There are a bunch of important things to keep in mind here. Here are the top two:
- Git is distributed, meaning, there are a lot of different computers involved. Each one can have its own idea of what's what.
- GitHub is not Git! GitHub is a hosting company that offers a Git service. They hide the actual Git implementation with a fancy interface. That fancy interface is not part of Git, and a lot of it barely uses Git at all.
Now, the image snippet you're showing is from GitHub. So it's showing you what GitHub says, which has, quite literally, nothing at all to do with anything you can set now in your own Git repository. It may have something to do with something you had set earlier—earlier today, or yesterday, or whenever—in your Git repository.
git config --list yields ...
These are settings you have set on your computer. You can change them at any time.
Note that there are two (or more) different places for your personal settings. Git calls these --global and --local. Git 2.20 and 2.21 added one new one, --worktree, which you are probably not using. Use git config --list --show-origin to see which place stores which setting.
....items related to remote branches
username.user=myUserName -> This is correct
username.email="myname@gmail.com" -> This is correct
These may be correct, but I cannot find anything that uses a username.user or username.email setting. (There might be something, but Git allows you to set anything to anything without complaint. If you were supposed to set, for instance, zaphod.beeblebrox=heads:2 for some piece of software, but accidentally ran git config hoopy.frood towel instead, Git would have no complaints about this—neither mean anything to Git.)
push.default=current
pull.default=current
The first one is meaningful, but in general, most people should leave the default push.default setting of simple in place. The second has no meaning.
user.email="myname@gmail.com"
This one is no doubt correct. The remaining one that's missing from the list you quoted, though, is user.name.
Now, it's important to realize that user.name and user.email are only used by your Git when you use your Git to create a new commit. At that time—at the time you make the commit—Git reads these two settings. Whatever is in them, goes into the new commit. The new commit, once made, is frozen for all time. You can make other commits that have different user-name and/or email settings, and if the commit you just made had the wrong settings, you probably should make another commit. But any commit that you did make that has the wrong stuff in it, has that wrong stuff in it forever.
That's not so bad! You don't have to keep using a wrong commit at all. If you made a wrong commit, you can, for instance, change things and run git commit --amend to throw out the wrong commit and replace it with a better one. The thrown-out one remains in your repository, but it's shoved out of the way, where you—and everyone else—can't see it, and it won't be sent on to some other Git when you run git push. And you can fix more than just the last commit, using git rebase -i --reset-author, for instance. Like --amend it doesn't change any commits; instead, it makes new-and-improved ones, and stops using the old-and-lousy ones.1
The user name and email you set in your configuration, that got copied into any commit you made already, show up when you run git log. Those two items—the user name and email—can be anything you want. Nobody and nothing can stop you from using other people's name(s) and email address(es) here. These commits are going into your repository, on your computer, and you can do whatever you want with your own computer.
But now that you have made some new commits, now you may want to have your Git send those new commits to some other Git repository. That other Git repository can be hosted anywhere, including, perhaps, on GitHub. If you do send a new commit to GitHub, they're not just going to believe that you are Barack Obama or whoever. So, now you have to authenticate yourself. This is where this setting may come into play:
credential.helper=osxkeychain
If you connect to GitHub via https, Git will need to use a credential helper, and this tells it which one to use. If you connect to GitHub via ssh, ssh has its own independent mechanisms; this credential.helper setting will be ignored.
I also cannot push any changes... What's wrong?
Probably, one or both of two things:
Your attempt to authenticate to GitHub is failing: they don't believe you are who you claim to be.
Or, they do believe you are who you claim to be, but that person does not have permission to push.
From what you've posted here, we cannot tell which of these is the case. But the error message that GitHub delivers back to your Git, and your Git passes on to you, will tell you which of these is the case (or whether it's some less-obvious possibility). So, find out how you're authenticating (or failing to authenticate), and if that's succeeding, whether you have permission to push. Correct whichever of these is a problem (perhaps both).
Once you get past all of these issues, the last stumbling block is this: Git pushes commits. Remember that we said, earlier, that all commits are frozen in time forever. When your Git goes to send their Git a commit, your Git hands over the hash ID—the unique name that goes with that commit, and only that commit; no other commit has that hash-ID-name—and, if they don't already have that commit, your Git hands over everything they need so that they can have that commit too.
So, after all of this crazy Rube-Goldberg-esque machinery has conveyed your commit(s) to the Git repository stored on GitHub, they will have some new set of commits—maybe just one commit, maybe a whole string of them—that they did not have before. Your Git will, in the end, ask their Git to set one of their branch names, or create a new branch name, to remember the last of those commits.2 GitHub then takes the email address stored in these frozen-forever commits, and looks them up in a giant database.
The database is how GitHub (not Git!) decides who made a commit. It's up to GitHub and their database to keep this translation working. They have a couple of different fancy schemes for this; see, e.g., https://help.github.com/en/articles/what-happens-when-i-change-my-username and related articles. They also have ways to control which email address(es) they will consider to be "you" when they see those email addresses in existing, frozen commits.
If you work with command-line Git, in your own repository on your own computer, you see what Git stored. If you work with the GitHub web interface, you see what GitHub translates to, from what Git stored. The actual storage is in the commits themselves, so until you have commits stored in a Git repository on GitHub, GitHub can't do any translating.
1If you already sent a wrong commit on to some other Git by running git push, then you have a problem. It's not necessarily a big problem, but it's good to be pretty sure you have the right commits before you run git push. It's much easier to throw away bad commits in favor of improved replacement commits before you've scattered those bad commits to millions of other Git clones all over the universe ... or even just one other Git clone hosted at GitHub, or whatever. The real point here, though, is that you can't change a commit, you can only replace it with a new-and-improved commit. If you do that before anyone else ever sees anything, they will never know that you had a wrong commit!
2The last commit remembers hash ID of the one before it, automatically. That's the parent of the last commit. The parent commit remembers its parent, which remembers another parent, and so on—so from the end, Git can work backwards to the beginning. This backwards-looking chain is the history in the repository! The act of starting at the end, showing a commit, and walking back to its parent, is how you, or anyone else, can view the history. The commits, with their relationships—parent, child, sibling, or unrelated at all—determine the history stored in the repository. The branch names just serve as a way to find the last commits.
