1
00:00:07,464 --> 00:00:09,590
After watching this video, you will be able to

2
00:00:09,590 --> 00:00:12,880
explain how the Git Feature Branch
Workflow supports social coding.

3
00:00:14,400 --> 00:00:17,840
Let's talk about guidelines for
your repositories and workflow.

4
00:00:18,640 --> 00:00:22,480
Create a repository for every
component whether it’s a microservice

5
00:00:22,480 --> 00:00:27,760
or something else you’re building. Don't put
multiple microservices in one repository.

6
00:00:27,760 --> 00:00:32,880
Those are called mono repos and are frowned upon.
People often create what we call a “mono

7
00:00:32,880 --> 00:00:38,560
repo” which is a single repo with multiple
microservices in it to make demonstrations easier,

8
00:00:38,560 --> 00:00:43,200
but this should not be done for production code.
You don't want someone to have to check out a

9
00:00:43,200 --> 00:00:47,760
lot of code that they don't care about just
to get to the code that they do care about.

10
00:00:47,760 --> 00:00:51,520
You want to have one component
or microservice per repo.

11
00:00:51,520 --> 00:00:54,720
This is very important.
Don't be afraid to have multiple repos.

12
00:00:55,600 --> 00:00:58,560
Create a new branch for every
issue that you’re working on.

13
00:00:58,560 --> 00:01:02,000
You don't want to have long-lived branches.
I don’t believe in having a "development" branch

14
00:01:02,000 --> 00:01:06,800
that all the work gets merged into and done.
That's the old way of thinking.

15
00:01:06,800 --> 00:01:10,320
Branches are very lightweight in Git.
There’s a master branch, and there are

16
00:01:10,320 --> 00:01:13,360
feature branches and that's all there is.
When you're done with the feature

17
00:01:13,360 --> 00:01:15,760
branch you delete it.
Don't get too attached to it,

18
00:01:15,760 --> 00:01:18,960
because you delete it and create a new
one for the next issue you’re working on.

19
00:01:20,480 --> 00:01:24,160
Use pull requests to merge
your code back to master.

20
00:01:24,160 --> 00:01:27,840
The only way code should get into the
master branch is through a pull request.

21
00:01:27,840 --> 00:01:32,560
A pull request gives an opportunity for other
people to look at your code and review it.

22
00:01:32,560 --> 00:01:35,440
Never merge your own pull request.
Don't do it!

23
00:01:35,440 --> 00:01:39,120
You always want to have someone else on
the team merge your pull request because

24
00:01:39,120 --> 00:01:42,640
every pull request is an
opportunity to have a code review.

25
00:01:42,640 --> 00:01:47,120
Have them look at the code, make sure it makes
sense to them, and then have them do the merge.

26
00:01:47,120 --> 00:01:51,760
This way you get two sets of eyes on all
the code that's going into the repository.

27
00:01:52,880 --> 00:01:57,040
We call this the Git Feature Branch
Workflow and here is how it works.

28
00:01:57,760 --> 00:02:01,600
Let’s begin with the GitHub Repo.
You create your new repository for your

29
00:02:01,600 --> 00:02:07,920
component or, if you’re contributing to someone
else’s component, you fork an existing repository.

30
00:02:07,920 --> 00:02:12,880
Next, you clone that down to your workstation
and it becomes your local repository.

31
00:02:12,880 --> 00:02:15,600
All of your changes will
be made in this repository.

32
00:02:16,720 --> 00:02:22,080
Next, you create a branch to work on your feature.
This can also be followed for bugs or other fixes.

33
00:02:22,080 --> 00:02:26,560
It is called a feature branch, but the
idea is that it’s the branch for the code

34
00:02:26,560 --> 00:02:29,280
that is associated with the GitHub
Issue that you’re working on.

35
00:02:30,320 --> 00:02:33,680
When you are ready to submit your code back
to the main project, or if you just want

36
00:02:33,680 --> 00:02:38,240
someone to review your changes to get feedback,
you push your code to a remote branch.

37
00:02:39,280 --> 00:02:43,200
Finally, you create a pull request to
request that your changes be reviewed.

38
00:02:43,200 --> 00:02:47,120
The pull request will be reviewed and if
the code is complete and meets the standards

39
00:02:47,120 --> 00:02:51,520
set out by the team, it will be merged
back into the master branch and become

40
00:02:51,520 --> 00:02:55,484
part of the original GitHub repository.
In this video, you learned that:

41
00:02:55,484 --> 00:02:57,465
In this video, you learned that

42
00:02:57,465 --> 00:03:02,080
creating a repository for every component,
following the Git Feature Branch workflow,

43
00:03:02,080 --> 00:03:06,052
then creating branches, and using
pull requests is a good practice.