the magical realms of git

It's all about the history

$ git log --oneline

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

This is the shared branch that you will deploy to production.  Feature branches are merged in when your team agrees.

A Feature Branch (yours only)

This is where you will do your development work. Open a pull request to master when you're ready to merge.

$ git checkout -b user-authentication

Create a new feature branch from the master branch like this: 

<name descriptive of what you're building>

The Production branch

branch name: MASTER

Since you are deploying, it makes sense to have a branch that you all agree will be deployable at all times. Merge the dev branch here when it's ready to deploy.

Don't introduce broken code to the production branch!

A Feature Branch (yours only)

This is where you will do your development work. Push this up and open a pull request to the shared dev branch.

The SHARED DEVELOPMENT branch

branch name: DEVELOPMENT

This is where you will merge separate feature branches. Code might be broken here. It gives you a place to push changes and share work.

SETUP

1. You and your teammates will be collaborators on a shared repo. One person creates the repo and adds others as collaborators.
2. Clone the repo so you each have a local copy.
3. You each create and work on feature branches off of master.
4. Name each branch something descriptive of the work you are doing, not your own name.
5. Discuss as a team how you will work together and communicate throughout.

Discuss & Decide

• Who is working on what? How will you divide the work?
• What is your branching strategy?
• How will pull requests work? Who will merge, and when?
• When will you deploy? Who will deploy?
• How will you communicate when you are not in the same room together?

1. Establish a setup: using a single production branch (master), or a development and production branch
2. Each dev creates a feature branch
3. Dev makes commits and tests their feature locally
4. Dev keeps their branches up to date with master
5. Dev opens a pull request
6. Code review + discuss + make changes if required
7. Push changes to (remote) feature branch (updating the PR) if needed
8. Merge the PR (so that the feature branch is merged to master on the remote repo) 
9. Deploy to Heroku! (if you're deploying)
10. Each dev pulls down changes from remote to local master

* This is basically the GitHub Flow.

Team Workflow*

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.

If there are merge conflicts, resolve them here on the feature branch.

You can create a pull request on GitHub whenever you want, using their big green button

👆This command merges your local master into the feature branch.

$ git push origin 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 so team members can review your work.

MERGE feature branches to master on GitHub.

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

Merging brings two lines of development (branches) together, still preserving the history of each commit

Merging

Merge to get commits from one branch to another

MERGING STrategy

merge remote master to local master

Merge feature branch to MASTER*

$ git checkout master 
$ git pull origin master

Merge MASTER to FEATURE BRANCH

* usually OPEN A PULL REQUEST ON GITHUB  & MERGE THERE

When new code has been merged to remote master

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. 

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

The part before the ======= shows your changes,
and the part afterwards shows their changes.

REsolving Merge Conflicts

All you need to do is edit the file that the conflict is in to make it look the way you want it to look. 

TALK to a teammate if you are not sure what to keep and what to delete!

Delete everything, including the stuff git put in that file, that should not be there.

And here's some handy instructions from GitHub on dealing with merge conflicts.

it will all be ok

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