1

Ok, I have been using git on and off for years, and have read books, and have read hundreds if not thousands of posts, but I still don't know the "correct" way to create a branch and push it back, and have spend hours trying to fix git when it goes wrong.

So lets say on github is a master branch. I want to create a feature branch of master branch, then push my feature branch back to github, then do a pull request for someone to merge it. This should be easy, but every day we struggle and have no fool proof set of steps (a recipe)

Step one is to clone the repo. I always do this with tortoise git (windows). I have found that if I use https I can never push back (get 403), I have to use git@... as the repo URL. No idea why, but I have a working solution.

I can then create a branch in 1 of 3 ways.

  1. create the branch in visual studio code (just enter the name)
  2. create the branch using tortoise (there are lots of options, I leave them all default)
  3. create the branch in git bash: "git checkout -b mybranch"
  4. "git branch my_branch < remote-name >/mybranch" (assume remote is always "origin")

However, I have also seen the following recommended ways to create branches (with the corresponding checkout after)

  1. git branch --set-upstream my_branch origin/my_branch
  2. git branch --set-upstream-to origin my-branch

Do all of these do exactly the same thing? Are they all "safe"?

Next is where the problems come in, how to push the branch to github.

I have read posts which say each of these is the correct way:

  1. git push origin
  2. git push -u origin
  3. git push -u origin master
  4. git push -u origin/mybranch
  5. git push -u origin mybranch

Which is correct (i.e. least likely to result having to start all over again with a new clone)?

If I do the push with visual studio code or tortoise, which of the above is it actually doing?

I understand that -u = --set-upstream, but what does this actually mean? If I always need it, why does it not do it by default? there are lots of posts asking what this means, but I have not found an answer. Does upstream mean origin?

I admit the problem is my brain - I have been using and administering SVN, SCCS, CVS,Clear Case, VSS for 30 years and never had issues, but git is another beast.

The next step is how to we create a pull request? The tutorials only seem to cover doing this through the github UI. does this mean this is not a feature of git? I.e. we cant do it on the command line, it has to be done through the web?

If we create a pull request via github web interface, who gets notified, and how?

Lets say that we are told to merge the feature branch into the master ourselves (without doing a pull request), what is the safest recipe for doing this? Searching the web, this is one answer:

git checkout mybranch
git pull 
git checkout master
git pull
git merge --no-ff --no-commit mybranch
git status
git commit -m 'merge test branch'
git push

Is this this the most fool proof (safest) recipe we can follow?

John Little
  • 7,993
  • 14
  • 62
  • 108

2 Answers2

1

To complete this old answer about --upstream, you can also read mine about "Why do I need to explicitly push a new branch?"

You setup an upstream branch only if you intend to do a git push (without argument) and expects Git to know where to push (which repo) and where to (which remote branch)

That will set the config branch.<name>.remote and branch.<name>.merge, so if you want to check if a branch has an upstream one, you can do:

git config -l
# or
git branch -vv

The last command would show your local branches in relation with their upstream branch.

The next question is that I just "git push origin". Now I know this was wrong, I should have done: git push -u origin mybranch". how can I fix this?

At anytime, you can add an upstream branch to your current branch:

git branch -u upstream/abranch
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
0

You can stick to git checkout -b mybranch (or the GUI-assisted alternatives you are using).

As for the upstream thing, you have a choice to make:

  • Always provide the upstream when pushing your branch (ie. doing git push origin mybranch each time)
  • Set the upstream with the first git push (with git push -u origin mybranch), and then only git push for the next changes you want to push
  • Set the upstream with one of the solutions you provided, and push with just git push

You can find informations about upstream in this answer: Why do I need to do `--set-upstream` all the time?

As for pull requests, they are not a git feature but a github feature. It's just asking the maintainers if they can merge your branch (and providing an UI to do so). All maintainers (and people watching the repository) will get notified, and anyone going to the repository page can see your pull request.

For merging, there are some alternatives, depending on if you want or not a merge commit, and some other preferences. I'll update my answer if I find a good resource to link to.

kLabz
  • 1,717
  • 1
  • 12
  • 14
  • thanks@kLabz. I have read the "why do I need to" post 3 times, but am still none the wiser. It doesn't explain why (at least in a way I can grasp) you need to do it, or what it does. I have his same question: "Isn't it obvious that if I push my_branch into origin/my_branch, then I would want to pull origin/my_branch into my_branch? How can I make this the default behavior?" – John Little Jan 17 '18 at 22:33
  • The next question is that I just "git push origin". Now I know this was wrong, I should have done: git push -u origin mybranch". how can I fix this? – John Little Jan 17 '18 at 22:35
  • Is tthere any way I can find out if VS code does the "-u" or not? – John Little Jan 17 '18 at 22:36