Creating new git branch. What is the point of git remote add?

Question

I am following a guide called Create a new branch with git and manage branches to create a new branch.

So far I have:

git checkout -b [new_branch_name]
git push -u origin dev

but the next command seems pointless. Why is it needed?

git remote add [name_of_your_remote] [new_branch_name]

I have just created a new branch. I have made Git aware of it so I can pull code in to my new branch. Why do I now need to create a remote branch and give it a name? Surely the name should be the same as my local branch?

Can someone please explain the purpose of this command?

EDIT: The reason I am asking this is because I want to know the bare minimums to create a new branch, edit code on it, pull latest and commit/push my changes

Answer 1

Surely the name should be the same as my local branch?

Not necessarily, but these commands are severely garbled. git remote add <remote> <url> adds a new remote, but you already have one. It does not need or affect branches whatsoever.

For the record, you can set the upstream name for your branch through:

git push -u origin dev:<newname>

Answer 2

With git, a remote repository (or just remote for short) is a repository that is somewhere other than the repository you're in now, commonly referred to as your local repository. Remotes may be located on your current host, possibly even as close as in a sibling directory, or remotes can physically reside on a host elsewhere on your local network or across the Internet.

Given that you were successfully able to run

git checkout -b dev
git push -u origin dev

that means you must have cloned your local repository. As part of the clone process, git sets up a remote named origin that points to the repository that you cloned.

If that repository is the only one you want to push to and pull from, then you are done. There is no need to create the remote again.

A common situation where a third repository is involved is if you fork a repository on GitHub and want to keep your fork current with the upstream, which is the main repository that you are tracking. The reason you would do this is you cannot commit directly to a project's main repository but can commit to your own fork and then send pull requests.

Say you want to at least keep your fork up-to-date and maybe even contribute to Awesome Project. Your sequence of actions would be

1. On GitHub, fork the repository you would like to contribute to. This main repository will become your upstream .
2. Clone your fork: git clone git@github.com:user997112/awesome-project.git
3. Create the upstream remote: git remote add upstream https://github.com/awesome/awesome-project.git

With this setup in place, you are now interacting with three repositories: the local clone and then two remotes (from the perspective of your local clone), which are your GitHub fork and the original upstream Awesome Project main repository.

Keeping your all the master branches synchronized (that is, where both your fork's master and the master of your clone are the same as upstream ) involves running

git fetch upstream
git checkout master
git merge upstream/master
git push origin master

Using the commands above will allow you to have a “dirty master,” which means making changes on your local master branch and merging changes from upstream. For newer git users, I strongly recommend keeping a clean master instead. This means making all your changes in branches other than master . This will reduce confusion. Using this safer approach, change the merge command to require fast-forward merges.

git merge --ff-only upstream/master

This way, if you committed something to your local master by mistake, git will not create merge commits that you will later have to go back and untangle to get to a state that makes sense to you.

---

See Also

Configuring a remote for a fork

Syncing a fork