Your First Meeting

  1. Figure out your group. Sign into https://kgcoe-git.rit.edu and look at the number of your group, it will be something like db-group-x, and x is the group number.
  2. Find your partner. You can DM them in Slack, or call out in class to find them.
  3. Find a place to sit. You can sit in the classroom, or in the SE team rooms. Don’t go anywhere else because the instructor will want to stop by.
  4. As an icebreaker in your group, name something you enjoy about computers. Then name something you hate about computers.
  5. Go over DB0 with each other.
  • Did you get everything working?
  • What tripped you up along the way?
  • Help each other get DB0 done if it’s not done. It’s okay if you spend the rest of today on this.
  1. Once DB0 is done, let’s practice a merge request on GitLab. Take a look at our git resources page. You will be reading this material this week if you haven’t already.
  2. With your partner, research how to do the following things. You will each do this to your own repository simultaneously. Make a branch in each of your Git repositories called practice.
  3. Make sure you on are on your new branch. This involves git checkout.
  4. Add a useful comment to one of your Python files.
  5. Commit to your branch.
  6. Push your new commit to Gitlab.
  7. On GitLab, create a Merge Request to merge the practice branch into master
  8. Ask your group members to add some feedback to the merge request.
  9. Now, make another change to your local Python file. This time, intentionally introduce a syntax error that would break your build.
  10. Commit, then push - still on your practice branch.
  11. Take a look at what happens on GitLab. Your Merge Request will update to show both commits. And… your build will break. Check what the console output of your build breaking looks like on GitLab.
  12. Fix your code locally so it works again. Commit and push, and check that it builds again correctly on your merge request.
  13. Merge your practice branch in. You have two options for this:
  • Easiest. Merge in GitLab. We recommend using the Squash Commits option: what this does is combine all of the changes you made from the practice branch into one commit, instead of linking the two branches together. This makes your Git history a lot easier to read by making all of the work you did in one branch reduced to a singular change.
  • Harder. Merge locally, then push that change. GitLab will likely detect that the branch is merged and close the merge request. If you like, you can research how to squash commits in Git locally although that is not required.
  1. Congratulations! You’ve just finished a Git Topic Branch workflow with Continuous Integration!
  2. If you have any other time left, review with your group the DB Expectations.