Coding Workflow

Coding Workflow

EDIT1: Since we currently are working closely with the 2 programmers on the team, we'll use the centralized workflow where we work directly off master.

EDIT2: Since we are now working with up to 5 programmers on the team, we have relied on "Pull Requests" to merge our code. We only use the "OneFlow" workflow when we get into more complex issues where we have to merge code manually - normally with the Lead Coding mentor there for guidance.

---

Since we are working as a 2+ person team, we'll need to stick to a general workflow to allow us to contribute to the same codebase with minimal issues/problems. There are several possible workflows to pick from, some of which are discussed in this article: https://www.atlassian.com/git/tutorials/comparing-workflows.

After assessing various workflows, we will use the "OneFlow" branching model for complex merges. We'll primarily use Github's native "Pull Request" feature for code reviewing and merging our feature branches into master. This is especially useful for those working remotely!

Github's native "Pull Request" feature

Pull requests are used to allow you and others to:

• review side-by-side code changes between remote branches (typically the master branch is the base branch),
• review side-by-side code changes between individual commits on a remote branch,
• write in-line review comments,
• write overall commit review comments,
• approve/reject the pull request itself, and
• merge the "Pull Request" to base branch.

GitHub has built-in features to create, review, and close "Pull Requests" directly from the website! Below is a general summary of steps to start and complete a "Pull Request".

1. Create a local feature branch with your code changes (if you haven't made one already)

   If you worked off the master branch until now, run the following git command to create the local branch from your local master branch:

   $ git checkout -b feature-branch

   NOTE: Ensure that your feature branch is based off of the latest master branch. You may need to $ git pull on the master branch and then $ git pull --rebase on your feature branch.

2. Create a remote feature branch based off of our local feature branch. We need to do this so that the remote repository also has your feature branch.

   From your local branch, run the following to create the remote branch:

   $ git push origin feature-branch

3. In GitHub, create a "New Pull Request"

   1. Specify the "base" branch you want to merge your feature branch into (by default the master branch is used)
   2. Specify the "compare" branch, which should be your feature branch
   3. Update the title of the pull request to be similar to a git commit title (e.g, "Added feature")
   4. Update the body of the pull request to be similar to a git commit body (make sure to point out things you want people to know when reviewing)
   5. Add other misc info (your mentors and team-members as reviewers, yourself as the owner)
   6. Submit "Pull Request"

4. To add more code changes to pull request, make commits to your local branch like normal and push these commits to your remote branch (the compare branch in Step 2)

5. After at least 1 reviewer marks the pull request as "Approved", merge the pull request to the master branch by pressing the "Merge pull request" button.

6. Make sure to delete your merged feature branch from remote! The pull request should have a button available once you successfully merge the "compare" branch into the "base" branch.

Feature branch lifespan

To minimize merge conflicts, all feature branches should be very small in scope (<100 lines) and thus, should last no more than a few days. If it takes more than a few days to code and test a task fully, then the scope needs to be smaller to merge it quicker - even if it's not fully working (if possible).

Using the "OneFlow" Branching Model

The OneFlow branching model has many advantages to offer and are summarized below (here are more details).

• simplifies the versioning scheme and day-to-day operations that developers have to perform considerably.
• makes the project history cleaner and more readable, and thus more useful.

We will specifically focus mainly on the following 2 sections of this article: https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow#feature-branches. I expect everyone to read and understand these 2 sections (code-snippets copied below for convenience) to understand how it visually looks in our Git repo's history.

Starting a feature branch

To start a feature branch (called my-feature for example), simply create a new branch from master:

$ git checkout -b my-feature master                # Create a new branch that looks exactly master

Finishing a feature branch (Option #1 - rebase)

Once work on the given feature is done, it needs to be integrated back into master. There are several ways this can be accomplished.

This method uses Git's rebase command (with the -i, meaning interactive, switch) to integrate the feature branch with master:

$ git checkout my-feature                          # 1. Start in your feature branch
$ git rebase -i master                             # 2. Update your feature branch to look like the master
                                                   #    branch and interactively put your feature branch's
                                                   #    extra commits right on top
$ git checkout master                              # 3. Switch to the master branch
$ git merge --ff-only my-feature                   # 4. Merge your feature branches commits into master
                                                   #    (all at the HEAD of master)
$ git push origin master                           # 5. Push your changes to the remote (so others can grab it)
$ git branch -d my-feature                         # 6. Delete your feature branch (since it's now merged)