Git: more newbie questions: the sequel

[ninetydegrees]

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

Comments

[randomling]

I don't know! I've just been keeping mine around in case I need them.

(sorry, that's unhelpful)

[ninetydegrees]

:) I wonder if if you can delete it locally but leave it on GH.

[kareila]

I'm pretty sure you can do exactly that, using branch -d (or branch -D if -d complains).

[ninetydegrees]

So I don't have to merge it, right? It would cause conflicts in this particular case and I don't wanna resolve them.

[kareila]

Correct. I never merge my branches locally, I either rebase them or delete them.

[ninetydegrees]

Ok cool thanks. That's one part solved!

[cesy]

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.

[ninetydegrees]

(I'm impressed I managed to find the right bit in the guide book :)

Thank you for your detailed answer and precious advice, cesy! It's very clear and helpful.

[ninetydegrees]

It seems that if the commit is merged but not the whole branch -d won't work, whereas if the branch is pulled it will. Do you know if this depends on the way you request a pull (the interface on GH is slightly confusing in this respect)? It seems like it could be.

[cesy]

It depends what you've got on the branch, yeah - the ideal is that you pull request the branch, and then it merges smoothly. If you've got branch A, then you branch B off it, then C off that, and C gets merged, then A and B will go smoothly. But if you did an extra thing on A that's not on C, then it won't go, which is the whole aim.

Can you point me at an example branch? It's easier to explain with diagrams and commits to refer to.

I'm not quite sure how to explain about pull requests, because I got so familiar with them that it's hard to break it back down. Which ways are you looking at? It doesn't matter so much which button you press as what you're requesting from and to - there are several ways to achieve the same thing.

[ninetydegrees]

https://github.com/ninetyd/dw-free/tree/bug4606/moderated_entry was merged today but if I try to do -d it tells me the branch isn't fully merged. OTOH I could delete another branch with -d which was merged a few days earlier. I'm not sure how to link to it since I also deleted the remote branch (here's the link to the request: https://github.com/dreamwidth/dw-free/pull/40).

As for the pull request button... There's one at the top near Watch/Unwatch which is there when you select a branch in the drop-down menu and when you view a commit, and one below the branch menu (not always there maybe because I can't see it right now).

[cesy]

That pull request just merges one commit, the one for 4072. https://github.com/dreamwidth/dw-free/pull/35 merges 4606.

https://github.com/ninetyd/dw-free/compare/develop...bug4606/moderated_entry shows that there's nothing in 4606 that's not in develop at the moment. Can you try making sure you've pushed the latest version of both to your fork?

One other thing I sometimes end up having to do is rebasing, if everything's got too mixed up, e.g. if you built on other pull requests that then got merged in a different order from how you built on them. So if you rebase 4606 onto develop, then try to -d, sometimes that solves it. And if it doesn't, it'll show up much more clearly what's missing.

[ninetydegrees]

https://github.com/ninetyd/dw-free/compare/develop...bug4606/moderated_entry shows that there's nothing in 4606 that's not in develop at the moment. Can you try making sure you've pushed the latest version of both to your fork?

Note quite sure how to do this. If I do git status it tells me there is nothing to commit.

if you built on other pull requests that then got merged in a different order from how you built on them.

I don't think I've done that because it's clearly isolated on my graph but who knows?

So if you rebase 4606 onto develop, then try to -d, sometimes that solves it. And if it doesn't, it'll show up much more clearly what's missing.

Can you explain how to do this and what this does? I've read about rebasing but it mentioned it wasn't a good idea to do rebasing when working with a public repo or something like that.

[cesy]

It's sometimes possible that you've committed something that's not on the website yet. If you're on that branch, and do git push origin bug4606/moderated_entry, that will send it there, or tell you if there's a misalignment.

The thing with rebasing is that it rewrites history by changing around the order of things. This is a bad idea if someone else has built code off yours, or is otherwise relying on yours, so the central repo must never do it. But opinions vary on when it's useful for an individual developer, and I really like it for keeping things clean so you can see exactly what changed. Some repos will also insist on it to make sure your pull requests merge cleanly and don't clash with anything that's been done in the meantime.

If develop is up to date, you go on your bug branch, and do git rebase develop, and that will essentially move your stuff so that it looks as if you branched off develop's current status and then did your coding, instead of you having branched off a month ago and then taking several days to do your coding and develop moving on in the meantime. If there's anything conflicting with what's been done on develop in the meantime, it will tell you and highlight it and walk you through fixing it.

If it's a branch you've already pushed to github, you then have to force it up there, because github will complain that you're rewriting history, so you have to do git push origin bugnumber -f. But if you've got a pull request open, that will automatically update and clean up the pull request as well.

[ninetydegrees]

I deleted the branch with -D in the end but I did do push origin before that and everything was up-to-date. This was my first branch and I messed things up (pushed it then renamed it locally then deleted the original on remote then maybe created a new branch on top of that which I deleted again) so it must be why it wouldn't work.

So it's like it pushes your branch forward in time?

[cesy]

Yes, essentially.

[ninetydegrees]

Hey Cesy!

I had to rebase today because I messed up* and I totally see how it can useful and what you meant now. Thanks again!

* It was a case of 'if you built on other pull requests that then got merged'. :)

[cesy]

The pull request button below the branch menu is Github's shiny new thing trying to be super intuitive, and sometimes guesses wrong. That's why it keeps disappearing, when it doesn't think you have anything that needs pull requesting. The one up the top does less guessing, but that means it's easier to learn what it's going to do.

The easiest way to learn them is to look closely at what you're requesting from and to, then change it, and view the commits without actually submitting the pull request. That lets you play with it enough until it starts to make sense, without bothering anyone else.

The URL is also quite a helpful hint. So something like https://github.com/ninetyd/dw-free/pull/new/dreamwidth:develop...ninetyd:bug4591/database_themes will have the same stuff as https://github.com/ninetyd/dw-free/compare/develop...bug4591/database_themes, provided your develop branch is up-to-date.

If you want to get confused you can do weird things like pull requesting to yourself or to another developer, which is useful for pair programming or working in teams. But it was only once I'd done that a few times that it actually made sense to me, because that's the way I learn.

[ninetydegrees]

I actually like the new button better. I think it makes more sense to have it there although it disappearing instead of saying 'hey! you already requested that to be pulled!' isn't ideal.

*nods* yeah I pay more attention to the drop-downs now.

I'll experiment when I have more time. Thanks for the suggestion. It does sound like it could help.