Git MVP includes 4 main requirements:
You must use main as your primary branch, which is the default when creating a new repository.
Why?
- Branching from the branches other than the
mainbranch can create opportunities for merge conflicts.
Feature branches must be named: feature/<descriptive name>
For example, if you're working on a feature that allows users to change the email address in their profile, the branch should be named feature/change-email
More info on branches and how to create a branch can be found here.
Why?
- Without a good naming convention, it is very easy to lose track of the purpose of a branch.
After a branch has been merged to the main branch, it must be immediately deleted.
Why?
- Short-lived branches are a best-practice for minimizing merge conflicts. Leaving many branches active in a repository makes it difficult for team members to navigate the on-going work. Once a branch has been reviewed, approved, and merged into the
mainbranch, it should be immediately deleted. - A healthy Git repository has a minimum of active branches.
- This is easy to comply with using GitHub.
Following this workflow make it easier to collaborate with your teammates. It will also help prepare you for Labs, since it is very similar to the Git workflow you will use in Labs!
The idea is that each Trello card should be on its own pull request as a feature!
The Build Sprint Git Workflow is designed to prepare you for your Labs experience. You can learn more about Git & GitHub in Labs, check out the Engineering Standards and Labs Git Workflow.
You're ready to work on a new Trello card - let's get started!
WITHOUT FORKING, clone your team's repository. After that always make sure you start with a recent copy of the repo.
- To get started on your first task let’s make a branch. Making sure you are on the
mainbranch, start a new branch with a name that matches or correlates to the task you are about to begin. - The trick here is to think beyond yourself when naming the branch, stay aligned with your Trello board so you and others can easily make sense of it.
git checkout -b [*feature/<descriptive name>*]
Now you have a branch to make all your awesome commits to!
- Copying the description from the Trello card, which should summarize the actual work in the PR, create a Draft Pull Request using the
mainbranch as the base after you have made your first commit.
Github created pull request drafts so that notifications will be turned off by default until you decide you are ready for review.
Now we’re ready to make some awesome software. Committing and pushing our code regularly are habits worth having. Before we know it, we’ll be ready to take the PR out of draft mode.
Tip: do your best to be a great team member by making commit messages as clear as possible. They don’t have to be elaborate- keep it to the point.
When you feel you’ve completed the task you’ve been working on, it's time to:
- Update the description
- Take the PR out of Draft Mode
- Make it "ready for review".
Ask someone in your team's channel to review your work.
The team will then be notified of the PR and they can begin a review before merging it to the main branch.
Tip: Follow the team policy regarding the number of reviewers required before merging. It’s great practice to take the time and make comments in the code, even if just positive notes on good work your teammate did.
If there are no conflicts to be resolved in the code choose Rebase and merge or Squash and merge from the Merge button.
If you find yourself with a merge conflict, there are a number of ways to solve it. The Github tools are very handy. You can also do it locally. When going down the local path, there is a good set of instructions here.
Your code changes are now on the main branch, ready to wow! users with your updates.
Deploy your code (if not otherwise handled by Github Events) and be ready to support and address any issues that arise.
Humor Break!
-
Revision History
July 30, 2020: Created by @Christine Carpenter
August 8, 2020: Edited by: @Christine Carpenter (update branch to main)