Confusion around repo commit & pull sequence for SCA dev

• 
  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

  Kendra_Little June 26, 2020 11:10

  - 0 +
• 
  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

  PeterDanielsCRB June 26, 2020 16:08

  - 0 +
• 
  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

  Kendra_Little June 26, 2020 16:12

  - 0 +
• 
  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.

  PeterDanielsCRB June 26, 2020 16:18

  - 0 +

Add comment

Please sign in to leave a comment.