SquirtleSquad1988 / git-workflow-teams

Team Workflow with Git and GitHub

Objectives

• Create branches on a Git repository and make commits on those branches.

• Combine changes from one branch with another using git merge or git rebase.

• Combine changes from one branch with another using git rebase.

• Explain what "merge down, rebase up" means

• In squads, work through our recommended Git workflow to build a small project.

Prerequisites

• Basic Git workflow
• Git Branching and Merging

If you're feeling fuzzy on these topics, here's some reading to brush up.

1. Atlassian Tutorials: Using Branches

2. Atlassian Tutorials: Comparing Workflows

3. Atlassian Tutorials: Merging vs Rebasing ('Conceptual Overview' section only)

Git, Together

Although up until now we've been using Git only to manage our own projects, it was actually designed as a tool for teams to use, so that they could collaborate more effectively. Since you're much more likely to be working on a development team than working individually, it's important to know how to use Git in a team setting.

Specific Git workflows will vary from team to team, but most are built around feature branching, the practice of using separate Git branches to isolate different features of an application while they're under development. Though this is useful even in the context of working individually, since it allows you to easily switch which part of the application you're working on, where this approach really shines is in a team setting. By splitting up features over multiple different branches, team members can work in parallel on different parts of an application without stepping on each others' toes.

There are three core mechanics within Git that a feature branching strategy depends on. Two of them, branching and merging, you've already seen. Today, we'll introduce a third: rebasing.

Git Rebase, in Pictures

Suppose that (in addition to master) you have two branches in your project, dev and feature, and that the feature branch is currently checked out.

If you were to check out the dev branch and make a new commit, the feature branch would no longer point to the end of the dev branch.

How could we update our feature branch to incorporate the new change? One option might be to check out the feature branch and merge in dev. A merge applies commits from another branch on top of any commits you've made. However, this is a little weird - we're essentially creating a duplicate commit. What's more, the commit on dev might not be related to feature, so it may not make sense for it to be on the feature branch. .

Rebase essentially allows us to pluck off an entire branch and move it so that it points to a different commit. All we need to do is check out the feature branch (git checkout feature) and run the command git rebase development; now, the root of the feature branch points to the new end of the development branch

That's the end result of a rebase, but rebase doesn't just "move" commits - in making the move, Git actually destroys the old commits and replaces them with new commits (with new and different SHAs).

This is one of the things that can make git rebase dangerous, and it's the reason why you never rebase code that's already been published and shared - you run the risk of breaking other peoples' code.

However, as long as you're only rebasing your own code on top of things, git rebase is perfectly safe, and if master happens to change a lot, it's a great way of making sure that feature stays up to date. Remember: when you "rebase your code on top of things" the branch following git rebase is what you're rebasing your branch "on top of" — it will be the new "base" for your current branch if executed.

Lab: Identify the differences between rebase and merge.

• Open Explain Git with D3 in your browser.
• This is a very simple git model, and it assumes that every commit already has change that have been added and save. Using git checkout git commit (every git commit will place generate a new commit on the current branch) git merge and git rebase commands, and the provided examples for merging and rebasing, run the commands for both rebasing and merging and take note of the differences you find.
• Pay special attention to the following:
  • What does merge down, rebase up mean?
  • In plain English, what does git merge do to our history?
  • In plain English, what does git rebase do to our history?

Take five minutes to run through these exercises and discuss insights among your squads.

What's in a rebase, really?

Let's break down the following diagram together.

Git's rebase, step by step.

The GA Team Project Workflow

Though there are a lot of different potential Git workflows for teams, for your team project, we will require you to use the following workflow.

Setup (Do Once)

1. Create a GitHub Organization for your repos, and add collaborators as a 'team' within the organization. Any repos that you create as part of the project will go inside this organization.

2. Create two empty starting repos within the new GitHub organization. Clone those repos down to one team member's computer, add in any template files that the repo will be using, and then push the updated repos back up to GitHub. Additionally, create a new branch called development on each repo, and push those branches up to GitHub as well.

3. Have each member of the team clone both repos, so that they have their own copies of each.

Regular Workflow

On a day-to-day basis, your team will follow a feature branching workflow. Each time you want to create a new feature for your app, you'll go through the following stages.

Creating a New Feature Branch

1. Check out your development branch (git checkout development)

2. Ensure that development is up to date with the development branch on GitHub by running git pull origin development.

3. Create and check out a new feature branch using git checkout -b my-feature-branch

Integrating a Feature

1. After you're done working on the branch, check in with your team and let them know that you're ready to integrate your feature.

2. Because development may have been updated in the time since the feature branch was created, it's important to make sure that the new feature doesn't conflict with anything. Run git checkout development and git pull --rebase origin development to make sure that your development branch incorporates any updates that were made on the repo on GitHub. Then, run git checkout my-feature-branch and git rebase development to rebase your new feature on top of the (updated) development branch.