A branch is essentially another copy of your repo that will allow you to isolate changes and leave the original copy untouched. 

BRANCHING

You can later choose to combine these changes in whole or part with the another branch or the mainline of development, or not.

The Production branch

MASTER

$ git branch

$ git checkout -b my_new_feature

$ git checkout master

$ git checkout -

Since you are deploying to Heroku, it's important to have a branch that you all agree will be deployable at all times.

Don't introduce broken code to the production branch!

A Feature Branch (of many)

This is where you will do your development. Break stuff here!

TEAM WOrkflow

1. Establish a production branch (master)
2. Each dev creates a feature branch
3. Devs make commits and test their feature
4. Devs keep their branches up to date with master
5. OPTIONAL: dev opens a pull request
6. OPTIONAL: code review; discuss changes
7. push changes to feature if needed
8. merge the feature to master
9. deploy!

* This is basically the GitHub Flow.

There are other established workflows out there.

Your workflow

On local FEATURE branch:

Make your commit(s).

On local MASTER branch:

$ git pull origin master

Make sure local master is up to date with remote master.

$ git merge master

Keep this branch up to date with master.

Resolve merge conflicts here on the feature branch.

Create a pull request to origin or upstream master.

 THEN...

👆This command merges master into the feature branch.

PULL OFTEN so you will have your colleagues' work.

PUSH OFTEN to keep your remote branch up to date.

COMMIT OFTEN to collaborate effectively.

PULL REQUEST
when your feature branch is ready to merge to master

PRO TIPS

verbal communication is key!

It's your job to keep your feature branch up to date with master. 

Tell your team when you are pushing up changes or have opened a pull request that requires their review.

MAINTAIN YOUR BRANCHES

WRITE GOOD COMMIT MESSAGES

Say why a change is needed or what it does.

Make sure your local and remote branches are in sync.

git status...git status...git status

$ git checkout master
$ git merge featurebranch 
$ git log --oneline 

brings two lines of development together while still preserving the lineage of each commit

MERGING

MERGE TO GET COMMITS FROM ONE BRANCH INTO ANOTHER

merge remote master to local master

Merge feature branch to MASTER*

$ git checkout master 
$ git pull origin master

Merge MASTER to FEATURE BRANCH

* OR OPEN A PULL REQUEST ON GITHUB

What could possibly go wrong??

MERGE CONFLICTS

Conflicts occur when changes occurred in each branch to the same line or group of lines, and git doesn't know which to choose. 

Here are lines that are either unchanged from the common ancestor, 
or cleanly resolved because only one side changed.
<<<<<<< yours:sample.txt
Your changes are reflected here in this section.
=======
Their changes are here in this section, in conflict with yours.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

The area where a pair of conflicting changes happened is marked with markers  <<<<<<<, =======, and >>>>>>>. 

The part before the ======= is typically your side,
and the part afterwards is typically their side.

WE ALL MAKE MISTAKES

Don't worry. Git is your friend.

and the file has gone back to its state at the previous commit.

UNDOING CHANGES IN YOUR WORKING TREE

If you haven't added (staged) files  or committed yet.

$ git checkout app/views/layouts/application.html.erb

...Your changes are gone from the working tree (and your editor)

The file is removed from staging, but your working copy will be unchanged.

UN-STAGING A FILE 

$ git reset app/views/layouts/application.html.erb

When you want to keep the changes in your working tree

 $ git checkout app/controllers/main_controller.rb

DIscarding CHANGES completely

Your changes are gone from the working tree.

Reset the working tree to its state at the last commit

if you have not staged:

if you have ALREADY staged:

Just reset the file first to unstage it. 

 $ git checkout app/controllers/main_controller.rb

 $ git reset app/controllers/main_controller.rb

Undoing committed changes

$ git log --oneline 

Git lets you go back to any previous commit.

Find & copy the SHA of the commit you NOW regret:

 $ git revert 53d23c4 
   # Your default editor will open here 
   # you can just save it and close it as is. 
 $ git log --oneline 

Notice that the original bad commit is still there, but now you also have another commit that undoes the changes introduced by the original one.

GIT REVERT

ER, WHAT IF I ALREADY COMMITTED IT?

keep calm & Follow these instructions