I've been searching around to find out what others do in this situation but I'm having trouble finding a definitive answer.
Our current workflow is as follows (btw, we use Azure DevOps for our GIT repository):
- We have a remote 'Development' branch
- A dev creates a new branch from remote/Development (e.g. remote/FeatureA)
- A local copy of FeatureA is created
- Work is done locally and committed to the local/FeatureA branch
- As a side note, if changes are merged into remote/Development ...
- We pull those changes into local/Development
- Perform a rebase of local/FeatureA onto local/Development
- As a side note, if changes are merged into remote/Development ...
- Once local/FeatureA is done, it is pushed to remote/FeatureA
- A pull request is raised to merge remote/FeatureA into remote/Development
However, any commits done locally (e.g. local/FeatureA) are not backed up in anyway and there is the potential to lose those changes if the workstation dies for whatever reason. I was thinking it might be possible to push those commits to the remote branch (remote/FeatureA) so they are always backed up in the cloud (similar to the requirements of this poster ... Git workflow and rebase vs merge questions). But it appears that doing this would cause grief in rebasing should any changes be made to remote/Development by another developer.
Does anyone have a good solution for this? That is, how can I ensure my code changes/commits are backed up while continuing to work on a Feature before it is ready to be merged into the remote/Development branch? I supposed I could look at a hardware solution ... e.g. connect a portable HDD to my workstation and have scheduled backups ... but I thought there might be a more elegant solution.