4

I know git pull origin master only pulls in and merges code to my current remote branch. Is it best practice to delete my branch with commits merged to master and then re clone updated master branch and git checkout -b [next branch name]? again?`

starknaked23
  • 43
  • 5

2 Answers2

2

ATTN: no re-cloning required.

If you know with relative certainty (like the master has already significantly since your last pull) that you will never need to use the branch again, by all means delete it. I often delete branches whenever I need to pick a specific one and run git branch, which shows a list of branches for most and for me reveals all the clutter from the last time I cleaned up the place.

Your next step should be to run git checkout master. Depending on the upstream's repo and if you are on a fork will determine your next step. By the way, there are many ways to accomplish what you seek, but I want to help you so I will suggest a beginner git flow to git started.

If you are on a fork:

  1. try git fetch upstream for now. It will pull in all the upstream branches.
  2. then you can run git merge upstream master, and that will get your local fork back in sync.
  3. To get back to the master branch run git checkout master which is probably a command you know already. It means, switch back to master branch.
  4. You can push up the contents of the master branch so that your remote fork is up-to-date.

If you are not on a fork, simply replace upstream with origin.

Of course, you can skip steps 1 and 2 with git pull master, but I want to emphasize what fetch gives you, a view into what everyone else has been working on in the remote repo. This visibility can be very helkpful to someone just starting out. I hope this helps!

Steve Smith's blog on why you should delete branches is great:

Nice-Guy
  • 1,457
  • 11
  • 20
  • This is what I was looking for. Much appreciated! – starknaked23 Apr 14 '20 at 05:59
  • After doing `git push origin --delete branchname` I then ran `git fetch origin` and `git merge origin master`. I tried `git pull master` but master repo could not be read. `git checkout master` got me back to the master branch and `git pull` got me all the updated commits from my merge to master. `git checkout -b branchname` has me on a new remote branch, right where I want to be. Next, finish this new code, pull request and do it all again until this app is ready. Right on for the info @Nice-Guy ! Hope this helps others. – starknaked23 Apr 14 '20 at 06:54
  • @starknaked23: I recommend *avoiding* `git pull`, but if you like it for some reason, remember that the syntax is: `git pull `, not `git pull `. That is, the `` part is *required* here. `master` is a ref-name, not a remote. Your first remote is almost always the simple name `origin`; your second one, if it exists, is the name you used when you used `git remote add`. In this example it's `upstream`. – torek Apr 14 '20 at 07:28
  • Note that `git checkout -b ` creates a *local* branch, not a remote branch. In a sense, there is no such thing as a *remote branch* at all. Branch names are local to *each Git repository*. They have *their* `master`; you have *your* `master`. This `-b` created *your* `branchname`. – torek Apr 14 '20 at 07:30
  • @torek thanks for catching that. So you're saying I should have ran `git pull origin master`? And then to create remote branch: `git remote add branchname`? – starknaked23 Apr 14 '20 at 07:38
  • oh, it's `git remote add origin https://github.com/user/repo.git` or actually, swap `origin` with `new-remote-branch-name`, right? – starknaked23 Apr 14 '20 at 07:45
  • You only need to use `git remote add` to add additional peer Git repositories. Each one has a URL (https://... or ssh://... etc); each one has a name (`origin`, `upstream`, ...); you choose both of these. That's then your argument to `git fetch`—`git fetch origin`, `git fetch upstream`, and so on—and your first of several arguments to `git push`. – torek Apr 14 '20 at 08:10
  • The fetch and push operations are the ones that call up another Git and talk with it. As I said above, I recommend *avoiding* `git pull` entirely. It just runs `git fetch` first, and then, once `git fetch` finishes, runs a second Git command of your choice to use what you just fetched. – torek Apr 14 '20 at 08:11
  • Alright, I got myself back to master branch. I'm trying to create a remote branch that will show up in the drop down of the repo I'm working with in GitHub? `git remote add new-name https://github.com/user/repo.git` created the remote repo, but did I need to `push` new changes for the branch to show up in GitHub? Do I need to `--set-upstream` ? I did this once and can't believe it's this complicated to do again to work on a new remote branch and see it show up for me. `sigh(patience)` – starknaked23 Apr 14 '20 at 08:18
  • `—set-upstream` won’t be needed until you push the beach up to upstream to make it exist there. Right now it’s only local. – Nice-Guy Apr 14 '20 at 08:38
  • ah, there it is. didn't need to add new remote branch. from master branch it's: `git checkout -b new-name` then `git push --set-upstream origin new-name`. ~whew :) – starknaked23 Apr 14 '20 at 08:56
1

If that branch is a feature branch, and that feature is completed, then yes, deleting the branch (both locally and on the remote) is a good practice to avoid an accumulation of old branches.

If the branch represent a long term development effort (like 'dev' for 'development'), then you can keep using it, even after a merge.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250