I am trying to understand Visual Studio's Team Explorer with GitHub. When I push my feature branch it is than available as a remote for other users to pull/use/edit. Then later when it is ready to be merged into one of the master branches which do I merge it to the remote or local branch? Most importantly, what is the need for having a local master and a remote master, I just don't understand why there is a need for two?
Thank you,
Josheir
The "local master" and the "remote master" are the same branch, conceptually. The "local" and "remote" just refers to where the physical storage for that branch is.
4 hours ago, Josheir said:Then later when it is ready to be merged into one of the master branches which do I merge it to the remote or local branch?
You merge your feature branch into the master branch. You do this locally. Then, you push the master branch somewhere. This causes the copy of the master branch at that "somewhere" location (the "remote" location) to be updated to reflect your local copy.
You don't, and for the most part cannot, directly affect a remote clone of a repository other than with the push.
4 hours ago, Josheir said:Most importantly, what is the need for having a local master and a remote master, I just don't understand why there is a need for two?
Git stores the entire repository with each clone (barring exception circumstances that are irrelevant here). So there's a copy of the master branch here (the local) and a copy of the master branch there (the remote). There will be as many copies of that branch as there are clones of the repository. Just like there as many copies of this post as there are people who read it: the copy stored on the forum's database, and the copy your machine downloads to display in your browser.
Very great.
Now I notice that the graph on the history of the local branches have two strands for the feature branch and three strands for the master branch using team explorer Visual Studio.
The grey dots I am thinking are the merges and the blue dots are other commits. I understand how this would work with the feature branch assuming that this is correct.
However, the master history I am not understanding. What are the 3 strands representing and how are they interacting?
Thank you so much,
Josheir
One other question, without getting to deep into it when I am done with a feature branch any time after I should go ahead and delete both the local and remote feature branch which is pretty much recommended?
Thanks,
Josheir
8 minutes ago, Josheir said:Now I notice that the graph on the history of the local branches have two strands for the feature branch and three strands for the master branch using team explorer Visual Studio.
The grey dots I am thinking are the merges and the blue dots are other commits. I understand how this would work with the feature branch assuming that this is correct.
However, the master history I am not understanding. What are the 3 strands representing and how are they interacting?
This is a visualization that is specific to your tool, so only somebody who uses that tool can give you a definitive answer. That said, these kinds of graphs are common for visualization of Git repositories and if you posted a screenshot somebody might be able to make a reasonable educated guess.
4 minutes ago, Josheir said:One other question, without getting to deep into it when I am done with a feature branch any time after I should go ahead and delete both the local and remote feature branch which is pretty much recommended?
If you want. You can also just avoid pushing the feature branch anywhere, which is usually what I do.
Each dot is a "commit" - they represent changes made to one or more files.
A single line between two commits means that the upper commit was created from the lower commit. In other words, the person who created the upper commit had the lower commit checked out when they committed their changes. The lower commit is called the "parent".
A commit which has more than one parent is a "merge". These happen because two people can begin their work at the same time on different computers from the same (or different) starting points, make commits separately which don't know about each other, then try to push later. When the second person tries to push, git will tell them that they need to pull first. When they pull, git will merge the other person's work into their branch (and possibly need to resolve conflicts). This 'merge' step creates the multi-parent merge commits. After that, the second person can push.
At any time, you or someone else can check out any commit in the history they want, and start making commits at that point. You can then merge those commits into any branch you want, if you feel like it, or leave them separated if you decide not to merge them (perhaps they are an experiment that you want to keep separate, for example).
Clarification about 'local' and 'remote' branches: The branch you see on your own computer called "origin/master" is sometimes called a "remote tracking branch", frequently shortened to just "remote branch" and represents where your computer last fetched/pulled that branch from the 'origin'. 'origin' is the default name of whatever host (github, bitbucket, visual studio team services, etc) you cloned from, and where you push/pull to by default.
The remote branch on your computer can differ from where the equivalent branch is on github/bitbucket/etc. It only updates when you fetch, pull, or push that branch. When you commit, you only update your local branch.
19 hours ago, jpetrie said:You merge your feature branch into the master branch. You do this locally. Then, you push the master branch somewhere. This causes the copy of the master branch at that "somewhere" location (the "remote" location) to be updated to reflect your local copy.
Now how does the Pull Request work with regards to all this? I was thinking it was some sort of communication area for before the merging of the feature branch to the master branch (local,) there's even a merge button on the UI.
So is it right that the Pull Request merges the local commits to the local master on it's closing Than I must push it to the "remote location" with my regular GUI?
There seems to be some mention of Pull Request and making rules that will prevent merging (unless overridden by a regular UI method?) until some criteria is met. For example, must be reviewed by some user/s?
As long as w'ere discussing this, I read somewhere that you can make changes and push commits and their would be immediate reflection in the Pull Request? I don't quite understand - but I'll believe this when I see it! 
And finally, am I correct in my understanding that the Pull Request is used as needed, and not all the time?
Thank you all for your help,
Josheir
10 minutes ago, Josheir said:Now how does the Pull Request work with regards to all this?
"Pull requests" are a feature of GitHub, not Git itself.
They're a project management mechanism, and as the name implies are simply a request by somebody for the owner of a GitHub project to pull some proposed changes from another branch (usually in another fork of the repository).
GitHub provides some infrastructure around supporting comments and peer review of pull requests, should you want to use that. Ultimately when a request is accepted it is merged into the target branch (usually master) exactly as you'd merge any other branch by hand. GitHub just provides some helpful buttons to do that for you.
You can use GitHub's Pull Request system however you like. Or not at all. It is purely a convenience mechanism.
