ninetydegrees: Photo: octopus tentacles (tentacles)
ninetydegrees (90d)☕ ([personal profile] ninetydegrees) wrote in [site community profile] dw_dev_training2012-08-30 01:24 pm
Entry tags:

Git: more newbie questions: the sequel

Once your request has been pulled into develop and you've updated develop what do you do with your 'old' branch (local and remote)?

Edit: http://git-scm.com/book/en/Git-Branching-Remote-Branches says this:

Suppose you’re done with a remote branch — say, you and your collaborators are finished with a feature and have merged it into your remote’s master branch (or whatever branch your stable codeline is in). You can delete a remote branch using the rather obtuse syntax git push [remotename] :[branch].

Is that what needs to be done here? If so what about the local branch and should we wait until code is pushed live?

Answer 1: local can be deleted w/ git branch -d BRANCHNAME (not merge needed yay)

Answer 2: remote can be deleted using git push origin :BRANCHNAME
randomling: Chris Kirkpatrick of *nsync raises an eyebrow. (eyebrow)

[personal profile] randomling 2012-08-30 11:59 am (UTC)(link)
I don't know! I've just been keeping mine around in case I need them.

(sorry, that's unhelpful)
cesy: "Cesy" - An old-fashioned quill and ink (Default)

[personal profile] cesy 2012-08-31 04:09 pm (UTC)(link)
Once your code is merged into master in the main repository, then when you update your local code to match master, git branch -d branchname will work with no errors, and git push origin :branchname clears it from your fork on github. Doing it at any point before then means extra work in the (hopefully unlikely) event that a bug is found in your code before deployment and you want to update from there, so choose your risk level depending on how clean you like to keep your dev env. When it's merged into develop sounds like a good compromise to me.

I find this a useful check that I don't have code I forgot to pull request - if branch -d fails, it means I have code that's not merged. Sometimes that's because I made a mistake I don't want to keep, in which case branch -D solves it. But sometimes I've found a second half of the patch that I forgot to submit, and it's useful.