-
Create branches on a Git repository and make commits on those branches.
-
Combine changes from one branch with another using
git merge
orgit 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.
- Basic Git workflow
- Git Branching and Merging
If you're feeling fuzzy on these topics, here's some reading to brush up.
-
Atlassian Tutorials: Merging vs Rebasing ('Conceptual Overview' section only)
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.
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.
- 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
andgit 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?
- What does
Take five minutes to run through these exercises and discuss insights among your squads.
Let's break down the following diagram together.
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.
-
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.
-
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. -
Have each member of the team clone both repos, so that they have their own copies of each.
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.
-
Check out your
development
branch (git checkout development
) -
Ensure that
development
is up to date with thedevelopment
branch on GitHub by runninggit pull origin development
. -
Create and check out a new feature branch using
git checkout -b my-feature-branch
-
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.
-
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. Rungit checkout development
andgit pull --rebase origin development
to make sure that yourdevelopment
branch incorporates any updates that were made on the repo on GitHub. Then, rungit checkout my-feature-branch
andgit rebase development
to rebase your new feature on top of the (updated)development
branch.