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?
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.
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
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!
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:
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.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs