I'm wondering how people address one of the scenarios raised in the post, specifically this:
"It’s safest to keep private branches local. If you do need to push one, maybe to synchronize your work and home computers, tell your teammates that the branch you pushed is private so they don’t base work off of it.
You should never merge a private branch directly into a public branch with a vanilla merge. First, clean up your branch with tools like reset, rebase, squash merges, and commit amending."
I'm wonder how people address cleaning a private branch that has been pushed (when your goal is to get its changes into master cleanly). Rebasing the private branch is pretty much out of the picture since it has been pushed (unless you don't care about pushing it again). I can see some ways of doing this:
1) You could do a diff patch and apply it master, then commit.
2) You could checkout your private feature branch, do a git reset to master in such a way that your index is still from the private, then commit it. Ex:
currently on private branch
git reset --soft master
Now all the changes from the private branch are changes to be committed on master. This is easy, but it puts everything in one commit.
If you wanted to do a few commits for different, but stable points, but you already pushed the private branch and can't rebase it, you could instead do "git reset --soft" on successive points in the private branch commit chain, committing to master as you go.
If you wanted to reorder commits from the private branch, I guess you could rebase the private branch (which means you can't push again since you pushed it already), then do the tactic from the last paragraph, then ditch the private branch cause it's no longer pushable.
Does anyone have better ways of putting changes to master for private branches that have already been pushed?
Whether a branch is private and therefore can be rebased has nothing to do with whether there's a copy of it on the server. I push my work-in-progress to the server often for backup purposes anyway. If I want to rebase, I just push -f.
I can't think of why that would be a problem, but if someone objected to push -f on a private branch, I'd just make a new branch with a new name and push that. And if that were a problem, I'd just find another server to push -f to and only ever commit to master on the official server. But these are silly workarounds. Why make things harder than they need to be?
This is true. If the assumption is that it's a private branch, then other people shouldn't care if you push -f because no one else should be using it.
Sometimes there are cases where people want to pull a private branch because they are working on something that is in the same code path but will be deployed after the private branch is integrated and deployed. They want to work off the newest code and avoid a larger merge to their private branch later. Would rebasing that private branch make their life harder? If so, one could always stage changes in a feature branch at stable points for them. Thoughts?
Basically, my understanding is that push -f can be a hassle for others to pull if they made commits to the same branch already. You're totally right that if it's truly a private branch, though, this should be irrelevant.
If someone wants to work off my private stuff I would tell them "sure, but be careful cause I'm push -f'ing" (after all, it's usually pretty easy to fix) and give them a heads-up when I do. If that weren't acceptable, I'd add a tag like "stable" to my branch, tell them to use it only up to that tag, and move the tag forward as the work progresses. If that weren't acceptable I'd make a branch instead of a tag and tell them to use that.
"It’s safest to keep private branches local. If you do need to push one, maybe to synchronize your work and home computers, tell your teammates that the branch you pushed is private so they don’t base work off of it.
You should never merge a private branch directly into a public branch with a vanilla merge. First, clean up your branch with tools like reset, rebase, squash merges, and commit amending."
I'm wonder how people address cleaning a private branch that has been pushed (when your goal is to get its changes into master cleanly). Rebasing the private branch is pretty much out of the picture since it has been pushed (unless you don't care about pushing it again). I can see some ways of doing this:
1) You could do a diff patch and apply it master, then commit.
2) You could checkout your private feature branch, do a git reset to master in such a way that your index is still from the private, then commit it. Ex:
currently on private branch git reset --soft master
Now all the changes from the private branch are changes to be committed on master. This is easy, but it puts everything in one commit.
If you wanted to do a few commits for different, but stable points, but you already pushed the private branch and can't rebase it, you could instead do "git reset --soft" on successive points in the private branch commit chain, committing to master as you go.
If you wanted to reorder commits from the private branch, I guess you could rebase the private branch (which means you can't push again since you pushed it already), then do the tactic from the last paragraph, then ditch the private branch cause it's no longer pushable.
Does anyone have better ways of putting changes to master for private branches that have already been pushed?