Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.

Preview

Start a free Basic trial
to watch this video

Sign up for Treehouse

Introduction

3:42 with Nick Pettit and Jason Seifer

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:

  1. Create a branch for our feature. In this case, we call it design.
  2. Work on the design branch while keeping the master branch able to be deployed.
  3. Keep committing to our design branch until it is done.
  4. When we're happy with the design branch, we can merge that back to master. The master branch will then contain all of our code from the design 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