Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
55 lines (32 sloc) 3.13 KB

LESSON: git-workflow-teams



  • Combine changes from one branch with another using git merge.
  • Combine changes from one branch with another using git rebase.
  • In squads, work through our recommended Git workflow to build a small project.


Vocab Word: Definition of word


  • A git merge applies commits from another branch on top of any commits you've made.

    • history is not rewritten.
    • Safe to do on deployed and shared code bases
  • A git rebase essentially allows us to pluck off an entire branch and move it so that it points to a different commit in history.

    • 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). History is rewritten

    • 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.

    • 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.

    • perfectly safe to do on your own code

    • good to use if master (or dev, or the common branch that people are branching off of) changes a lot.

    • In a group project, if you start on a common branch dev and make a feature branch, during the day you might git rebase dev from your feature branch to incorporate new changes and ensure there are less merge conflicts when you are finally ready to merge your branch back into `dev

    More on rebase and merge

    You should always use git pull --rebase when your changes do not deserve a separate branch. Make this distinction known: Your local branch, into which you pull changes, and remote branch, are actually different branches, and git pull is about merging them (through a fetch and merge). When it would be better for any two branches in question to be one branch is where git pull rebase comes into play. You no longer merge, you actually commit one branch on top of the other for unified history.

merge -- applies commits from another branch on top of any commits you've made.

rebase -- adds commits onto a shared commit in both branches history and then reapplies your commits on top of those. After a rebase, pushing to the branch will require --force-with-lease since the history has been rewritten

Group project guidelines

  • Always branch by feature. Each branch should have a feature in mind, i.e. auth, book-single, book-collection, etc..., and that feature should be completed fully before it's merged into development.

  • Always pull before a merge or rebase.

  • Never work directly on either development or master.

  • 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.


  • [git practice and visualizations with D3](Explain Git with D3)