First I'll start with my workflow:
- Created change in my local repository ( using Notepad )
- Try to push changes to the remote repository - standard Git flow:
2.1. git add README.md
2.2. git commit --m "xxx"
2.3. git push
After that Git created on my GitHub new branch "master" and I need to create a pull request and after that, I can merge changes...
$ git push
Enumerating objects: 32, done.
Counting objects: 100% (32/32), done.
Delta compression using up to 12 threads
Compressing objects: 100% (27/27), done.
Writing objects: 100% (32/32), 6.42 KiB | 2.14 MiB/s, done.
Total 32 (delta 8), reused 22 (delta 5), pack-reused 0
remote: Resolving deltas: 100% (8/8), done.
remote:
remote: Create a pull request for 'master' on GitHub by visiting:
remote: https://github.com/Mikma03/Python_Bill_Lubanovic_BookCodes/pull/new/master
remote:
To https://github.com/Mikma03/Python_Bill_Lubanovic_BookCodes.git
* [new branch] master -> master
I strongly believe that there is a way to fix this. Do you have any suggestions?
I expect to see just a new commit on my GitHub repository without need to merge.
CodePudding user response：
You've been calling your local branch master for some time now.
You ran git push, which—because you're calling your local branch master—meant git push origin master:master. That is, you had your Git send your new commit, which you made on your master, to the other Git repository over on GitHub in https://github.com/Mikma03/Python_Bill_Lubanovic_BookCodes.git, and then ask them (GitHub) to create or update, in their repository, a branch named master.
If you wish to use some other branch name on your end, rename your branch:
git branch -m new-branch-name
for instance. (The -m option stands for move, which is a funny way to spell rename: this dates back to the Linux mv command for renaming files, which in turn dates back to the Unix mv command.)
If you wish to use the name master on your end, but the name roxible on GitHub, use:
git push origin master:roxible
(in general this is a bad idea as humans find this kind of name-mapping confusing, plus you have to keep repeating the colon syntax every time, which is annoying—there are some workarounds for that but that gets pretty far afield).
Note that when you create a new, totally-empty repository on your own computer:
mkdir new-repo
cd new-repo
git init
for instance (on a Linux system), your Git repository has no branch names in it, and yet you're on your master branch. You're just on a branch that does not exist. You have two options at this point: rename the branch that doesn't exist, with, e.g.:
git checkout --orphan main
which is a really weird way to spell "rename a branch that doesn't exist", or go ahead and create the first commit, and then use git branch -m to rename master.
In the latest versions of Git, git init has a flag, -b, to set the branch name:
git init -b main
which creates the repository such that the branch that doesn't exist, that you're on anyway, is named main instead of master. This avoids having to rename the branch, but requires a pretty new version of Git. There's also a new init.defaultBranch configuration variable, but this one has the drawback that if your Git is too old to know this configuration variable, git init silently ignores it. The -b flag has the advantage that it either works, or git init complains that it has no idea what -b means.