This course will be retired on April 30, 2018. We recommend "Ruby on Rails 5 Basics" for up-to-date content.
Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Start a free Basic trial
to watch this video
In this video, Nick and Jason discuss different branching strategies when developing application features and how to work together.
Links
Git Concepts
Branching: A branch contains a separate fork of code from a common ancestor in git. When a new git repository is created, there is a master
branch by default.
Feature Branch: A feature branch can contain code that isn't on a production site or development branch and contains a work in progress for a feature, such as design.
Merging: Merging a branch of code will copy that code
Deployable Branch: A git branch that is ready to go out to a given environment.
Staging Environment: A testing ground for features that may not be ready to go.
Smoke Testing Environment: The smoke testing environment contains a copy of the production database and new code that could be deployed to production.
Production Environment: The live, public facing code.
Git Workflow
A popular git workflow that we're using in this project is based on creating a feature for the code we're about to write. Here's how it can work:
- Create a branch for our feature. In this case, we call it design.
- Work on the
design
branch while keeping themaster
branch able to be deployed. - Keep committing to our design branch until it is done.
- When we're happy with the
design
branch, we can merge that back tomaster
. Themaster
branch will then contain all of our code from thedesign
branch.
-
0:00
[MUSIC]
-
0:04
When working with teammates on a Rails project it's important to have a system
-
0:08
that allows people to work independently of one another and
-
0:11
also integrate their changes.
-
0:14
In this project we're using the Git source control system to work together.
-
0:19
Git allows us to keep track of our changes to the code base as we add features to it.
-
0:24
If you're not familiar with Git, try taking a look at our
-
0:27
Git foundations course which is linked below the video here.
-
0:30
For the purposes of this project,
-
0:32
we're going to assume that you're familiar with some Git terms and have it installed.
-
0:38
If you're using the Treehouse VM.
-
0:40
It is already installed, and
-
0:41
just needs to be configured with your name and email address.
-
0:45
>> I've heard designers are hesitant to use GIT and especially the command line.
-
0:51
You might even be tempted to have your developer just do all of the work here.
-
0:55
>> And personally I refuse to do that for Nick.
-
0:58
>> Git is actually pretty easy.
-
1:00
You just need to get the hang of it.
-
1:03
>> As Nick and I are working together on this project,
-
1:05
we're going to be using a feature of Git called branching.
-
1:08
By default, when a Git depository is created the branch is called master.
-
1:14
The ODOT application was developed and currently exists on the master branch.
-
1:19
We can consider this the production ready branch of code
-
1:23
that is ready to be deployed at any time.
-
1:25
When we do big features such as adding design,
-
1:28
we can create a separate branch and work on that feature
-
1:32
in order to not impact any other changes happening at the same time.
-
1:37
>> We're going to call the branch that we're developing on, design.
-
1:41
This is where I'll be adding style sheets, JavaScript, as well as layouts, and
-
1:46
making everything look good.
-
1:48
Jason and
-
1:49
I can work together on this branch without affecting anything on the master branch.
-
1:54
If we want to add more features, we can always branch again.
-
1:58
Teams can work different ways when it comes to a Git branching workflow.
-
2:02
In some companies,
-
2:03
all development will be done on the master branch, which will always be ready to go.
-
2:08
>> And by ready to go, he means be able to be deployed out to production and
-
2:14
ready for users to take a look at.
-
2:16
This is the path that we'll be taking as we work through the features on this app.
-
2:21
It's worth it to be familiar with some
-
2:24
other workflows that are popular in software development.
-
2:28
Other popular workflows for teams are to have a production branch that is always
-
2:33
deployable, as well as branches for staging, smoke testing and more.
-
2:40
These are typically always deployable to their respective environments.
-
2:44
For example, a staging environment maybe a testing ground for
-
2:48
new features that aren't necessarily ready to go.
-
2:51
You can have your internal team,
-
2:53
test a new features in a staging environment and give them feedback.
-
2:58
>> The term smoketesting is a similar idea, but it's for later in the process.
-
3:03
A smoketesting environment, will typically connect with a live copy of production
-
3:07
data and will contain the code that is just about to be deployed.
-
3:11
This allows one to test the actual code against
-
3:14
actual data before it goes live to your millions of users.
-
3:18
>> Once we're comfortable with the feature development on our code and
-
3:22
ready to deploy it, we'll tag it with a name so
-
3:25
that we can always get back to it at a later time.
-
3:29
This is a lot to take in and we don't need to worry about all of this right now.
-
3:33
But these concepts are good to know for the future.
-
3:36
Now, with all of that in mind, let's get the apps set up and running and
-
3:40
get into our first branches.
You need to sign up for Treehouse in order to download course files.
Sign up