I just realised that I’d not noticed a recommit following some suggestions in a pull-request. I would suggest using the ‘discussions’ section on pull-requests to make it clear that the something has changed (e.g. “I’ve just submitted a new commit which addresses the suggestions”)
If you’re working on something, please move it to ‘in progress’ just in case anyone else was about to pick it up.
If you’ve moved a task to the in-progress/done column please remember to check that the ‘assigned’ column is set. I consistently fail to do this myself! I believe that Visual Studio Online will automatically copy the assignee for the parent task by default so if you are the only person working on an item it’s easiest to set this here.
Visual Studio Online
All pull requests are gated on to the develop branch. There is a strict policy of review and assigned work item. These pull requests should be atomic in that they address a new feature or a bug fix.
You can either create a feature or bug branch and perform lots of commits on to it. This supports sharing the code changes with the rest of the team. When code changes are complete then a pull request is created on to develop branch.
If you want regular feed back/review then create a branch for each task and create pull request on to the feature or bug branch for that task branch. These won’t be gated or have the constraints that develop has and will be more “permissive” until the final pull request on to the develop branch.
They should not be so fine grained as creating a work item and then a pull request for it. This was he way that the SVN trunk was used.
Yes I know that this avoids having to merge changes but I think all of the Bugs and Features are fairly independent and should have little overlap.
–EOF (The Ultimate Computing & Technology Blog) —
loading...
Last Post: What I Like Most about Git and Code Review
Next Post: Case Study: Optimize Your Website and PageSpeed Insight now 100!
