Permalink
Browse files

Adding lesson notes

  • Loading branch information...
danman01 committed Jul 27, 2018
1 parent dcef2cf commit 79215419e16bbdf54e06d00f41d34870b89e6e79
Showing with 54 additions and 0 deletions.
  1. +54 −0 git-workflow-teams/README.md
@@ -0,0 +1,54 @@
## LESSON: [git-workflow-teams](https://git.generalassemb.ly/ga-wdi-boston/git-workflow-teams)

---

**2018-07-25**

### OBJECTIVES

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

### VOCABULARY

**Vocab Word**: Definition of word

### NOTES

- 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.
### Links
- [git practice and visualizations with D3](Explain Git with D3)

0 comments on commit 7921541

Please sign in to comment.