Team Wide Resources

Team Wide Resources

Communication

We have several channels setup on slack for the various groups.

• Udacity Alumni Slack
• Back End Team
• Front End Team
• Dev Ops Team
• Leadership

Project Management

We will be using Github primarily for our project management. Included in each of the respective repositories is a Projects section. By clicking on the Projects button, you will be shown a Kanban style project management tool, which we will be using to track our progress.

• About Github Projects
• Backend Projects Page
• Front end Projects Page

Git

Version control tools, such as Git, enable a team of distributed software engineers to collaborate effectively while minimizing the effort of maintaining the source code manually. The below guide acts as a resource to outline the best practices in using Git as our distributed source control tool of choice.

Recommended Workflow

We recommend to employ a workflow similar to the Feature Branch Workflow. Also, we ask that our contributors follow a Commit Message Style Guide to ensure that our work be well self-documented and appear to be organized. Finally, we suggest that our contributors read the following Git Style Guide as a suggestion to the best practices they can utilize.

We have established pre-commit hooks to prevent poor practices when committing to the main repositories for our projects. If you have any trouble submitting commits that follow the best practices, please let us know!

Feature Branching Overview

The above referenced guide to the feature branch and the centralized git workflows speak to the main goals and concepts of working successfully in a distributed software team.

To clarify about what this looks like in practice, generally each repository will have one Master branch that is always the source of truth for the most up-to-date version of the code. During a typical development session, a developer will work on an isolated feature or set of features. When doing so, the developer will start the session with a localized copy of the main repository and will create a branch to work from for the remainder of the development session.

Example Git Workflow

1. Pull the remote master branch down to your local computer. git pull origin master.

• One impediment to this would be if you have files that have not been staged or commit into a branch. This is one reason it's important to commit often and at regular intervals throughout the development session.

2. When your local branch has been updated from the remote master branch, it is then safe to branch into your feature branch. The following is an example of a command to create a branch: git checkout -b feat_rc_feature_name

• To clarify, the name of your branch has the following anatomy

feat - indicating that it is a feature branch (See below for other possible prefixes).
rc - your initials, to indicate that you were the primary developer working on the branch
feature_name - a snake case name of the feature(s) that is/are being implemented by the branch.

• Similarly, you may also want to prefix the branch name with any of the allowed commit message types as indicated in the Udacity Git Style Guide, i.e. fix, docs, chore are common for non feature branches. i.e. git checkout -b fix_rc_fix_name or chore_rc_add_foo_to_bar.

3. Throughout the development of said feature, commit often with descriptive messages that match the style guide.
4. When you feel that your feature has been significantly implemented, or it is a natural breaking point (say at the end of a day), you may submit a request to pull your code into the master repository.

Pull Request

The workflow for submitting a Pull Request is as follows:

1. First and foremost, in order to avoid the possibility of a merge conflict within the Master branch, you will be asked to fetch the remote master branch git fetch origin master

2. Next, merge the Master branch into your branch by running git merge master while being checked out on your local feature branch.

3. Fix any merge conflicts while still checked out in your feature branch.

• If you require help during this process the first few times, please contact your section leader / mentor.

4. Once the master branch is merged into your local branch, you can submit a Pull Request on github and both our automated git hooks and a QA team member will review your code to ensure it meets quality standards before we pull it into the Master branch.

It's understandable if this process is bewildering to you the first time around. Team leaders and mentors will be there to guide you through the process and if you need to, please review the Udacity How to Use Git and GitHub course.

Documentation

---

• Issue Tracker
• Wiki
• Readme
• Self documenting code