README.org

Introduction to Git

Why Git

git bisect

• Define a point in history when a bug appears
• Define a point in history when a bug is not there
• Git finds the problem commit!
  • git bisect visualize
    • Works even when code is nonlinear and history is complicated
    • 

git blame

• blame commits, time or people for messing up a line
  • “code was working one week ago”
  • find reasons why you keep introducing bugs
  • Find related commits that may have introduced bugs
• see how the code grew and why each line was added/changed

Code is self documenting.

• need for comments is less
• you learn a valuable skill: How to read other people’s code
  • you learn how to write good code
  • encourages checking each others changes
    • there’s no one person who knows all the code and cannot take a break

• more people understand the code and it will be fixed faster
  • Easily merge other people’s changes
  • no more: main_final_2_3_submit_this_do_this_FINALFORREAL_FIXEDEVERYTHING.c
  • Free to experiment
    • can take out and experiment freely (when you get good)

Why command line

• Allows you to automate stuff.
  • ie. as soon as I push: upload my new code to my website server
• Use all of Git’s commands and bug fixes
  • Git’s error messages in CLI is much better
    • Easier to google what’s wrong
    • documentation will always explain using commandline
• Git is so versatile with so many people with different workflows

Basics

• Use tab completion. typing the beginning of a file and pressing tab will complete the file path
• git <subcommand> <flags> <what your are operating on>
  • Each git <subcommand> will have a default operation
  • <flags> are optional and will depend on how you want to alter the default operation of git <subcommand>
  • <what your are operating on> is also optional depending on <flags> and <subcommand>
    • <what your are operating on> can be files, branches, etc.
• Up arrow key takes you to the previous command you ran

TOO MUCH TO MEMORIZE

• git <subcommand> --help to see the flags, examples, default operations, and purpose of a subcommand exists
  • / to search for a phrase
  • q to exit
• git aliases: https://githowto.com/aliases

The Project

1. Fork the repository
   • This means I want to start a project on the server using your code as a base.
2. Clone the repository git clone
   • This means download a copy of this repository on the server to my computer
   • Note: this will download every commit, every version, and every branch of the code

Aside

You can start with a blank folder. Simply click new repository on the homepage and follow the commands.

1. Add anjandev as a member to your new repository. Make him maintainer.

Looking around

• git status: see current state of git repository
  • # USE THIS ALL THE TIME
  • modified files
    • files that have changes but have not been staged or commited
  • problems
  • files NOT staged
    • files that git is not tracking the changes of
  • files staged
    • files with changes that will be added to the next commit

Looking around cont.

• git log: see commit history
  • You can go to any point in the project’s history by running git checkout <COMMIT_SHA>
  • Each commit is a snapshot of the code at that time
• git diff
  • Show changes not set to stage yet

The first change

• Use git status to see files with changes that you may want to add to commit

Staging area

the changes you want in the next commit

• git add adds changes to the next commit
• NOTE: you must add a file to staging atleast once to have git track it and list it under modified

• git clone <url> download the <url> repository to your computer
• git add <FILE-PATH>
  • tell git that you want to add changes in <FILE-PATH> to the staging area

The first change cont.

• =git commit -m “<MESSAGE>”=
  • put a message on the commit
  • Commit all the files in the staging
• git push origin master
  • send all of the commits on the master branch to the origin server

More on staging

• when you create a new file, you must run git add <FILE-PATH> to tell git about the file
• How to remember the 3 “places”

  “working directory”

  what you see when you right click open with notepad

  “staging”

  what git sees as changes you want to commit next

  “commit”

  A locked box of changes with a message

• git reset .
  • This will not delete the changes. It will just remove the files in staging and put them back into working directory.

Exiting vim

• If you type git commit instead of =git commit -m “<YOUR MESSAGE>”= you will enter vim
• fear not, just type :q! and you will exit and it will be as if you never ran git commit
• you may now run git commit -m <YOUR_MESSAGE>

You made local changes that you havent commit you want to undo

• git checkout <FILE_PATH>
  • this will undo the changes to a file in the working directory so that it matches the last commit’s state
• You may now git pull

Branching out

• Since you should commit early and commit often:
  • Branching is good for when you have a large feature you want to implement
  • These changes will not affect the master branch
• To create a branch: git checkout -b <BRANCH_NAME>
• To see all branches: git branch
• Make sure you run git push origin <BRANCH_NAME> to push history

Branching out Cont.

• The github flow
  • Enable code review
  • Disable commiting to the master branch (make master a protected branch)
• http://git-school.github.io/visualizing-git/

• git log <BRANCH-NAME> if you get confused
• the branch you are on will get the commits

Merging

• To merge a branch into master:
  • git checkout master
    • go onto master branch
  • git merge <OTHER-BRANCH>
• When comparing snapshots if you have changed seperate lines between branches, you should get a message like:
  • “`Merge branch ‘master’ of github.com:msess/msess.github.io“` in vim
    • type “:wq” to make the merge commit
    • type “:q!” to cancel the merging
• If you have not changed seperate lines between branches:

Merge Conflicts

• When pulling changes from remote that is ahead, applying a stash, or merging branches, you merge
  • If the same lines are changed on the two things you are merging - merge conflict
• git status after each merge to see where merge conflict is
• Edit the files: https://git-scm.com/docs/git-merge#_how_conflicts_are_presented

Pull Request

• Basically someone sending you a message saying: “Please merge this branch into this branch”
• Someone with a fork can ask you to merge their master branch to the original’s master branch
• If you guys have changed seperate lines: you will get a button that says merge
  • Everything will be good
• If you have changed some same lines: you will have to choose which line you want to use
  • See: merge conflict

Working directory modified but want to pull server

• git stash
  • This moves all your “modified” files to a special side so you have no changes from your last commit
  • It does not do anything to untracked files
• git pull origin <BRANCH_NAME>
  • <BRANCH_NAME> is the name of the branch which you want to pull
  • Make sure you are on <BRANCH_NAME> before running this
• git stash apply

Server is ahead and you have a local commit to push

• You will see the error when you git push origin master:
• Solution: run git pull origin master
  • Run git status
    • If you both changed seperate lines, you will see:

• “`Merge branch ‘master’ of github.com:msess/msess.github.io“` in vim
  • type “:wq” to make the merge commit
    • If you both changed the same lines:

Tips for working with other people

1. Have each function be it’s own file
2. Agree on what each function does, what it’s arguments are, and what it outputs
3. One person should be assigned to edit a file at a time to avoid merge conflicts (more of a reccomendation)
4. Each feature/bug fix should be it’s own branch
5. When you want everyone to have the feature/bug fix, make the person send a pull request and have one person review their code
6. Commit early and commit often
7. Make sure you check if server is ahead constantly

ALWAYS GIT STATUS look into changing $EDITOR on windows