When using GitFlow in SourceTree, what is the best practice for rebasing features from develop?

[Seth]

Typically, I'm working with a small feature that only one developer is working on.  If a change to develop occurs, I would like to rebase with those changes.  The only part of this that bother me is that I also like to push my feature to remote (in case my computer goes down).  This now forces me to do a forced push if I rebase.  

What is the best practice for allowing rebases but also not storing your code locally only?

[Duane Murphy]

You have hit on a couple of ideas for how to approach the problem. I prefer rebasing to merging because rebasing gives you the opportunity to make a clean history. (A clean history is important to those of us who have to do software archaeology.)

However, as you're aware, pushing a rebased branch that has already been pushed can cause problems. 

Here are some choices:

1. If you are working alone on the branch, then a force push isn't horrible. I do this myself. 
2. Create a new branch. The general recommendation we make to the team, is that rebase is fine, but you are creating a new branch. We version the branch name. For example, feature/new-coolness becomes feature/new-coolness-v1. The rebase process really is creating a new branch.
3. Fork the repo. Do all of you work in another repo. You can mess around with history all you want in a private forked repository.  When you're ready, rebase across repos and push your lovely final product. 

Each solution has advantages and disadvantages. For example, will your automated build and test system still function on a forked repo?

These are some solutions that we have used. 

[Seth]

TLDR: Best practice is not to modify history that exists on remotes. Just merge development into your feature branch. 

Full explanation: It sounds like you want to rebase develop into a feature branch instead of merging it. This is a bad idea, as evidenced by the requirement that you do a forced push. Rebasing like this is changing the commit history. It is generally OK to change portions of the history that are only local, but you are changing the history of commits that another developer pushed to your shared remote.

If you force the push anyway, other developers are going to be unable to pull from the remote because the repositories don't match. I can tell you from experience, it is a major headache to fix, and is not something I'd ever inflict on other developers except in specific, rare, unavoidable circumstances.

[Seth]

Understood...my question is how to break that constraint and reap the benefits of my feature not only existing on my machine (for backup purposes) while also being able to rebase to have the latest develop code and for a clean merge to develop later.

I've been trying to think through a way this might be achieved...for example, pushing my "unshared" feature to another remote other than origin(for example: remote: seth) so it isn't only local, and periodically rebasing from origin until such time as I'm ready to close my feature and push to develop.  Not sure if I worded that clearly 

[Seth]

Fairly clear, but I don't understand why merging from develop without rebasing isn't sufficient, because that approach would avoid requiring a force push.

[Seth]

It definitely would still accomplish the end goal. I like rebase when local only for two reasons: 1) Keeps the tree cleaner and easier to follow 2) IMO it is easier to manage merge conflicts since you deal with each commit individually Just interested in other perspective in similar situations. Thanks!

[Seth]

Sure. Leave the question open for now, and maybe someone else will disagree with me and provide you with a more useful answer.