WCCI Course Materials

General Git Team Project Guidelines

In your team project repo main Github page, there is a link to "Projects". If you click on that, it takes you to a page where your scrum boards are listed. Click on your scrum board title and use your Github scrum board to organize your user stories ("As a user, I would like to do 'x' for reason 'y'.") Only put one user story feature per card.

User story cards start life in the leftmost column, in the "Product Backlog" column. The applicable ones are moved to the "Sprint Backlog" column. For each user story chosen to made a feature, a "Tasks" column card is made. The priorities for the sprint are moved to the "WIP" (Work-In-Progress).

"WIP" cards should be made into issues and assigned to certain team members for accountability.

Only 1 card per set of programmers should be in "WIP" at any time - we want to stay organized and time-boxed on the cards. A card shouldn't take more than a few hours to accomplish.

When a card is done, it can be moved to the PO Approval column. The PO (your instructor/s) will review and move it to the "Done" column.

Good Teaming Principles

  • Before any coding happens, always refer to and update your scrum board;
  • Keep your scrum board neat, updated, organized and focused;
  • Be accountable for your share of the work;
  • Functionality first - "Make it work, make it pretty";
  • EVERYONE takes turns driving;
  • Make small, well-named commits OFTEN;
  • Always work on a feature branch named for the feature you're building;
  • Always do a pull request in Github to merge a feature branch into dev;
  • Don't code alone on your team project - always work as a team.

GitHub Workflow

Before any coding begins, we will make a new branch called "dev" (short for "development") off of master. We will make feature branches off of the dev branch, and create pull requests to merge them to dev. Feature branches should be named for the feature that's being built on them. They should be merged to dev with a pull request in Github, and a different team mate should approve the merge. On Sprint demo day, each Friday, all working code should be on the dev branch. After a team's successful demo, that team can make a pull request to merge dev to master and tag their instructor/s. Only the instructor/s will approve the pull request from dev to master.

Always, always, always

  • Use git status frequently to see what you're tracking (or not tracking);
  • Do a git pull to get a teammates' changes before doing any new work;
  • Be developing on a feature branch.
  • Be using git bash and the command line.
  • Be making frequent commits. (Pass a test, make a commit)

  • Resolve merge conflicts in the feature branch.

    Never, never, never

  • Make a push directly to the dev branch.
  • Use Visual Studio's fancy pants Git integration tool. (It's like riding a bike with training wheels and an 800hp engine strapped onto it, it seems like a good idea until it's not.)
  • Go all day without a commit, lose internet and put your team behind because you can't push up the code on your machine that you spent 3 hours on.
  • Have to handle a merge conflict on the dev branch.
  • Make a new branch with the same name as a previously made branch.

Sample new feature workflow

Following this workflow should keep you out of trouble when working on a new feature branch.

  • The start of a new feature branch off of the dev branch:

    1. git checkout dev
    2. git pull
    3. git checkout -b newFeatureBranchName
    4. git push --set-upstream origin newFeatureBranchName - This prepares the GitHub repository to take future pushes into the new branch.

  • During development:

    1. git status - Check to ensure that a push needs made and that no 'funky' stuff is going on.
    2. git add .
    3. git commit -m "Enter your commit message here" - Use two new lines before the last quote to add comments to the commit message.
    4. git push

  • After last push and the feature is complete:

    1. Go to your Github project repo and open a pull request to merge your feature branch into dev.
    2. Have another team mate look at the pull request.
    3. If it's green and there are no conflicts, approve + confirm the pull request.

  • If any merge conflicts occur, resolve them with the following:

    1. Tell the team you have a merge conflict and use git status to find which files need resolved. Get a consensus with the developers that made the change that conflicts with your change as to how the code should look. If there is any doubt ask for help.
    2. If possible, open the merge conflict in Github and resolve the conflicts.

  • When merge conflicts have been resolved, open a pull request:

    1. Go to the GitHub repository page and open a pull request to the dev branch.
    2. Go to your team's Slack channel and ask for someone to approve your request and merge the code.
    3. git checkout dev
    4. git pull : EVERYONE MUST DO A "git pull" TO GET THE CHANGES.