-
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 Overiew' 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 group 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 you have two branches in your project, master
and feature
,
and that the feature
branch is currently checked out.
If you were to check out the master branch and make a new commit,
the feature
branch would no longer point to the end of the master
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 master
.
However, this is a little weird - we're essentially creating a duplicate commit.
What's more, the commit on master
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 master
; now, the root of the feature
branch
points to the new end of the master
branch
Now, to be honest, that's not quite what happens - 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.
Though there are a lot of different potential Git workflows for teams, for your group 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 group 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
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. -
If any conflicts were introduced in the previous step, work through the code with your group and resolve each one; when you finish, make a commit.
-
Now that your branch has been rebased, and you're ready to integrate it, push your branch up to GitHub with
git push origin my-feature-branch
. and then create a pull request (within your GitHub repo) from your feature branch to thedevelopment
branch. -
As a group, review the pull request, confirm whether or not it can be merged in automatically, and decide whether or not to approve the pull request.
If there are merge conflicts preventing an automatic merge, a member of your team will need to resolve those conflicts manually on their machine, and then push the newly updated
development
branch back up to GitHub.
Once development
has been updated, other members of the group
will need to rebase their own feature branches on it (as described in Step 2)
before they push up those feature branches up to GitHub.
Work through the following steps as a group.
-
Have one member of the group check out
development
and pull down the latest version from GitHub. -
For this version, check and make sure that the application is working. If you have tests, run them.
-
When you're satisfied that the app is ready to deploy, check out the
master
branch and rungit merge development
. -
Push the finished version of your code up to GitHub (
git push origin master
). -
Deploy!
If this is your back-end repo, run
heroku create
to set up a new repo on Heroku, and push to it by runninggit push heroku master
. If this is your front-end repo, rungit checkout -b gh-pages
; then, removebundle.js
andvendor.js
from your .gitignore file, make a new commit, and push up yourgh-pages
branch to GitHub.
-
Always pull before a merge or rebase.
-
Never work directly on either
development
ormaster
. -
Never share feature branches; if you need two people to work on the same feature, they should pair program on the same machine.
-
Never ever rebase code that's been published. Remember, 'merge down, rebase up'!
To practice the workflow we've prescribed for you,
your team will now follow it to create a simple front-end app
that (in response to a button-click) uses AJAX
to GET data from this API endpoint,
and then renders the resultant data nicely in the page using Handlebars.
You may start by downloading the JS-Template as a ZIP
and dropping those files into your repo.
Your feature branches should be html-css
, ajax
, handlebars
,
and ui-behavior
.
Make commits regularly, in case you need to undo a mistake!
Source code distributed under the MIT license. Text and other assets copyright General Assembly, Inc., all rights reserved.