SCA - Correct order for pull, commit, etc

We've got some developers that made larger changes (schema and programmable objects) to their local DBs.  We got one dev's changes into source (git repo in Azure Devops), buildable, and pushed to the remote repo.  Then, the other dev, who had changes in his local DB, but NO migrations (or programmable objects) generated in the git working tree, pulled the changes down...and it was messy.  The docs here:


"If another member on your team has pushed their commits you will need to use the Pull button to get the changes locally. In order to pull, you should not have any uncommitted changes. If you have uncommitted changes you can:
  • Finish the changes you are working on and create a commit
  • Temporarily Stash your changes using the 'git stash' command in the command line (advanced)"
Since there were no changed files in the working dir, we thought it was safe to pull and apply first.  But it was not.

Should we have generated migrations (and added/committed them) for the 2nd dev's changes BEFORE pulling the 1st dev's work and trying to apply it?

Thank you,



  • Hi Peter,

    Perhaps I'm misunderstanding the scenario, but if Dev2 had some changes but there were no changed files in the working directory - doesn't that mean they had not committed those changes?  Or maybe a better question is, compared to what were the files not changed - the actual files, the local git repository, or the remote repository?

    From your last sentence question, it sounds like you may not have committed the changes to the actual files to the local git clone, which is what it says to do.

    Kind regards,
    Product Support Engineer | Redgate Software

    Have you visited our Help Center?
  • PeterDanielsCRBPeterDanielsCRB Denver, COPosts: 80 Bronze 2
    Thanks, @Alex B.  I think I'm looking for clarity in the language about changes in the dev sandbox DB vs actual migrations created and saved in eth working directory vs adding them to git staging vs committing to git.

    In our situation, there were changes in the dev's local sandbox DB, but no migrations created for them (and therfore no "uncommitted changes" from a src perepctive.  When we pulled the other dev's migrations from remote repo and applied to DB, things broke. :)  We ended up renaming his local dev DB, rebuilding from src, and then using SQL Compare to bring his changes back into the new local DB.
Sign In or Register to comment.