Skip to content

Instantly share code, notes, and snippets.

@zachgoll
Last active March 14, 2020 16:13
Show Gist options
  • Save zachgoll/75606ebf8aa9a14e59a5ce57dc27d47a to your computer and use it in GitHub Desktop.
Save zachgoll/75606ebf8aa9a14e59a5ce57dc27d47a to your computer and use it in GitHub Desktop.

How would another contributor access these branches? To get started I suppose it's git clone, but can you git clone later too when you already have and old version of the repo? Or do you manually create branches locally and then pull those?

Think about this in terms of remote vs. local. Any branch that is local can only be accessed by the person who has created it. Once that person pushes it up to the remote repository, it is now accessible by all those who can see the remote repository.

The git clone command should only be done once, at the very beginning. If you want to grab updates later, you would use the git pull command, which is a combination of git fetch and git merge.

Why is it that you have to specify what branch you are pushing to? I mean it seems a lot safer to automatically push the current branch to the remote branch with the same name (is there any way to do that, so that when I push my feat1 branch it will be pushed to the remote feat1 branch, without risking pushing master to feat1?). The way this is designed in git seems to be to mess up.

We actually are specifying the remote branch we want to push to. The command, git push origin master is telling Git to push your local, committed changes to the remote repository on the master branch. In most cases, the remote repository is called origin, but it doesn't have to be called that. git remote -v will show you the name and the URL you have assigned. So when you want to push to feat1, you use git push origin feat1.

As I understood it feat1 would be a sub-branch to develop, but I didn't notice any way how to create a sub-branch opposed to just a branch.

There is not really a concept of "sub branches" in Git. What is important is to always be aware of what branch you are currently working from. The git checkout -b <branch-name> command will take all of the code that exists at this moment on the current branch and create a copy over on your new branch, and then update your "active" branch to the new branch that was just created. You can then do this ad-infinitum on your new branches.

Suppose you didn't delete the feat1 branch, you just merged for testers to try it out. Then you continue to work on feat1. Would the feat1 branch then be identical to the develop branch? Would it be safe to just checkout feat1 and continue on that feature, or could that mess things up?

Once you merge feat1 into develop, they are identical. But the second you make a change to feat1, they are no longer identical and you will need to do another merge operation to get them identical again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment