Confusion around repo commit & pull sequence for SCA dev

PeterDanielsCRB

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:

https://documentation.red-gate.com/sca/developing-databases/working-with-the-ssms-add-in/using-version-control-in-ssms/using-git-to-share-your-changes-in-ssms

Say:

"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,

-Peter

Kendra_Little

Hi Peter,

I suspect that documentation page intended that "uncommitted changes" include changes in the database which hadn't been imported yet, but I can see how that wording is unclear. I'll follow up on that (I'm out all next week so it may be a little while before I complete it).

I'll also chat with the team and propose that we move the "Create new branches" section at the bottom up to the top of the page and give a little more advice about how using feature branches makes it easier to work with Git.

My preferred methodology with Git is to have each developer working in a feature branch:

• Import changes from your database to your feature branch as you are ready. Push your feature branch up to the central repo as often as you like as a way to back up your changes from your local machine -- - optionally building these branches whenever they are pushed if you like
• If your feature branch needs to live longer than a day, do at minimum a daily pull from master and merge into your branch
• When your changes are ready to go into a main line, use a pull request to merge in
  

Effectively, most folks find it more straightforward to always merge changes into a branch when using Git, rather than to have shared branches where you have people pushing and pulling changes into the same active branch. 

I find that the Azure DevOps Release Flow model often work for people when they are getting started as it is not overly complex, but some people still prefer the older Git Flow model which maintains a separate develop branch. 

Hope this helps!
Kendra

PeterDanielsCRB

Thanks, @Kendra_Little .  I appreciate your thoughts here.  I think some additional clarity in the docs on "changes in local dev DB, but not yet in migration/programmable-obj src files would be helpful.  After we pulled the code from remote and looked at applying to local DB, it became pretty clear that we had done things in the wrong order.  devoops.

I'm still waffling on the branching strategy and even implementing PRs.  Trying to keep the learning curve for our team low angle.  They all come from a TFVC background.  It's a balancing act.  That said, I do want to steer them towards some form of branching flow and appreciate your ideas on different flow models.

Cheers,

-Peter

Kendra_Little

Thanks, Peter. Andrew on our dev team has recorded an item related to this on our status board which prevents us from forgetting about it, too  

We are continuing to think about how which source control elements are key to put in our tooling's UI, while not trying to completely recreate a Git client -- because there is so much functionality you can put in a Git client that it fairly quickly becomes overwhelming. It's definitely a balancing act. I'm sharing this post to our design team internally as well, as I think they'll find the info on this valuable for future product planning.

Thanks again for all your feedback, it is very valuable to us!

Kendra

PeterDanielsCRB

I totally understand the difficult balancing act in knowing what to expose for git in the SCA plugins.
Which reminds me - I (and my team) do find the SSMS plug-in's Version Control tab a bit non-intuitive.  Folks have regularly clicked the clearly highlighted "push" button w/o doing a commit and happily see "Success". I know the tool is evolving rapidly and appreciate the teams efforts.