Search code examples
gitazure-devopsworkflowrebase

Git and backup local commits

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):

  1. We have a remote 'Development' branch
  2. A dev creates a new branch from remote/Development (e.g. remote/FeatureA)
  3. A local copy of FeatureA is created
  4. 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
  5. Once local/FeatureA is done, it is pushed to remote/FeatureA
  6. 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.

Solution

  • You indeed can backup your feature branches to the remote repo, and it is good practice to do so.

    So what happens if remote/Development is changed and you have to rebase your feature branch?

    You do as usual for the local part (pulling the new changes on Development then rebasing your feature on it), and yes, at this point, the remote backup is "outdated" by the rebase. But since you're not disrupting anyone else's work (or so I guessed from your description?) on this branch, you can then push --force the result of your rebased local feature branch.

    I think you slightly misunderstood the part about

    "But it appears that doing this would cause grief in rebasing should any changes be made to remote/Development by another developer"

    ...which is true for shared stable branches like your Development here, but not for unshared (until they're eventually merged via a PR, of course) feature branches.

    (Anecdotically, we happen to have a very similar workflow in the team I'm in at the moment.)