18

I have a long running local feature branch which I was periodically squashing and rebasing with master to keep it up to date locally.

When completed I want my feature in a single squashed commit on top of master.

However, I was worried about losing my work in case of hardware issues, so I pushed this to a new feature branch on github as a precaution. Since doing this I'm not really sure how to keep my feature branch up to date since it has already been pushed (I'd rather not merge changes from master creating merge commits).

I am the only developer using this feature branch. So I'm not worried about rewriting history on an already pushed branch. Is it fine to push additional commits to my remote feature branch, squash that branch when I'm completed with the feature, and then rebase this onto master? Or will git throw some error about the branches diverging since the branch was already public?

Alternatively, I was thinking that when my work was complete, I could simply untrack the remote feature branch (so my local branch no longer has an association to the remote branch), squash the commits in the local feature branch, and then rebase my feature branch locally on top of master.

nogridbag
  • 3,521
  • 4
  • 38
  • 51

1 Answers1

5

Is it fine to push additional commits to my remote feature branch, squash that branch when I'm completed with the feature, and then rebase this onto master?

Yes, yes, and yes. Since you said that you are not afraid to rewrite the history of this branch, you can do anything you want with it.

Or will git throw some error about the branches diverging since the branch was already public?

Git doesn't have a notion of public and private branches. You can use a branch publicly or privately, Git will not complain about that.

When you rebase your branch on top of master, you basically replay your commits from the point where you branched from the timeline in master. If there were commits in master after that point, and you made commits in your feature branch after that point, then master and your branch have diverged. When you rebase, there might be conflicts, depending on the changes in the two branches.

In summary, you can do anything you want in your undocumented feature branches, and then rebase on top of master. Of course, depending on what you do, rebasing may be easier (few or no conflicts) or harder (a lot of conflicts). It's probably good that you rebase often, that way you discover conflicts little by little, rather than a lot of conflicts all at once.

janos
  • 120,954
  • 29
  • 226
  • 236
  • 2
    I found this post which seemed to indicate using the "force" option is required: http://stackoverflow.com/questions/8939977/git-push-rejected-after-feature-branch-rebase – nogridbag Nov 26 '16 at 01:32
  • It looks like that post is referring to the feature branch - which is acceptable. I would imagine it's equivalent to my plan B of untracking the remote branch, squashing and rebasing locally, and then creating a new branch. Simply using -force on the feature branch seems easier. – nogridbag Nov 26 '16 at 01:43
  • 3
    When you rewrite the history of a remote branch, the `--force` is necessary (and you understand the consequences). If you want, you can keep many backups around, by pushing to new feature branches without rewriting or deleting old ones. The local tracking and untracking have no effect on squashing and rebasing. The purpose of local tracking is simply to reduce typing or improve display in certain operations, it's quite cosmetic, and doesn't interfere with version control operations. – janos Nov 26 '16 at 05:22
  • This seems like it would cause issues for all the other developers when they pull branches to their local repo. – Andrew T Finnell Jan 11 '19 at 16:06