After watching this video, you will be able to explain how the Git Feature Branch
Workflow supports social coding. Let's talk about guidelines for
your repositories and workflow. Create a repository for every
component whether it’s a microservice or something else you’re building. Don't put
multiple microservices in one repository. Those are called mono repos and are frowned upon.
People often create what we call a “mono repo” which is a single repo with multiple
microservices in it to make demonstrations easier, but this should not be done for production code.
You don't want someone to have to check out a lot of code that they don't care about just
to get to the code that they do care about. You want to have one component
or microservice per repo. This is very important.
Don't be afraid to have multiple repos. Create a new branch for every
issue that you’re working on. You don't want to have long-lived branches.
I don’t believe in having a "development" branch that all the work gets merged into and done.
That's the old way of thinking. Branches are very lightweight in Git.
There’s a master branch, and there are feature branches and that's all there is.
When you're done with the feature branch you delete it.
Don't get too attached to it, because you delete it and create a new
one for the next issue you’re working on. Use pull requests to merge
your code back to master. The only way code should get into the
master branch is through a pull request. A pull request gives an opportunity for other
people to look at your code and review it. Never merge your own pull request.
Don't do it! You always want to have someone else on
the team merge your pull request because every pull request is an
opportunity to have a code review. Have them look at the code, make sure it makes
sense to them, and then have them do the merge. This way you get two sets of eyes on all
the code that's going into the repository. We call this the Git Feature Branch
Workflow and here is how it works. Let’s begin with the GitHub Repo.
You create your new repository for your component or, if you’re contributing to someone
else’s component, you fork an existing repository. Next, you clone that down to your workstation
and it becomes your local repository. All of your changes will
be made in this repository. Next, you create a branch to work on your feature.
This can also be followed for bugs or other fixes. It is called a feature branch, but the
idea is that it’s the branch for the code that is associated with the GitHub
Issue that you’re working on. When you are ready to submit your code back
to the main project, or if you just want someone to review your changes to get feedback,
you push your code to a remote branch. Finally, you create a pull request to
request that your changes be reviewed. The pull request will be reviewed and if
the code is complete and meets the standards set out by the team, it will be merged
back into the master branch and become part of the original GitHub repository.
In this video, you learned that: In this video, you learned that creating a repository for every component,
following the Git Feature Branch workflow, then creating branches, and using
pull requests is a good practice.