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.
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
you basically replay your commits from the point where you branched from the timeline in
If there were commits in
master after that point,
and you made commits in your feature branch after that point,
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
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.