EE160 Programming for Engineers

What is Source Control?

• A control/system/tool used to control your (source) code
• Also known as revision control

Why use GIT?

• it allows you to backup and restore your code to a previously known (and hopefully working) state
  • you can now make updates (and add features) to your code worry-free because you know you can always get back to a working state
  • you can share your code with others because they can get to a specific version of your code the same way you can revert to a specific version you have saved off
• it allows you to merge your changes and a collaborator's changes to the same code, automagically (GIT is magical)
• it is written by the creator of Linux to help programmers collaborate on the Linux kernel, a very intense piece of software

What is GIT?

• it is a distributed version control system
  • distributed means not centralized
    • older version control systems were centralized so you cannot touch a specific file if someone else has it checked out and is editing it)
  • version control system means it will sytematically control each version of your code
• it is the core of Github
  • Andreessen Horowitz is betting big on Github
  • so it's most likely going to stay around for awhile

How to use GIT?

• for the purposes of the challenges, you will just need to use the following commands:
  • git clone: Downloads a project and its entire version history
  • git status: List any changes you've made since the last save point
  • git branch: List all local branches
  • git checkout: Switch to another branch (all your files will automagically change to the last saved version of that branch
  • git add: Prepare (aka stage) files to prepare for saving (aka committing)
  • git commit: Save the staged files
  • git merge: Combine to two saved (aka committed) versions and automagically make sure each change is accounted for
  • git push: Upload the saved changes to the remote repository (e.g. Github)
  • git pull: Download the saved changes from the remote repository (e.g. Github) since the last git pull
• the typical workflow for these challenges will be as follows:

  Note: Be sure to check on what state your code is in by issuing git status and/or git branch at any time when performing the following steps

  1. git checkout -b feature/my_branch
     • -b means create feature/my_branch also
     • feature is just a naming convention; there's nothing special to it
     • at the end of this git checkout command, issuing a git status should show that you are on the feature/my_branch branch
  2. [make the additions and changes to the source code]
  3. git add .
     • git add will stage your updates in preparation to be committed
     • . means to stage all of your updates in preparation for committing
  4. git commit -m "my commit message"
     • git commit will save the updates you've staged
     • every commit needs a commit message to tell others what changes are being saved
     • -m says use my commit message as the commit message
  5. git checkout master
     • switch to the master branch
     • master is the name of the primary branch that is typically used by many GIT repositories
     • notice all of your changes are gone and the code is back to it's original state before you started making your changes
  6. git pull origin
     • get the latest version of the code
  7. git merge feature/my_branch --no-ff
     • combine the saved changes in feature/my_branch with the code in the master branch
  8. git push origin
     • upload the changes to the remote repository (e.g. Github) so others can download your changes
     • origin is the name of the remote repository that is typically used by many GIT repositories
     • you could have named origin something else and even add more remote repositories
• Be persistant
  • GIT does have a steeper learning curve than most other tools
  • like any tool, using GIT more often will make GIT easier to use
  • using a graphical user interface (aka GUI) will help in the initial learning process
  • feel free to practice using GIT on this play repository: git-practice (refer to the README for more info)
• References:
  • The official GIT documentation/reference
  • A typical branching model that has real world scenarios so you can visualize how GIT is often used and the differences between branches and commits
  • If you really want to learn the in's and out's of GIT, you can follow these tutorials
  • Visualize GIT staging and committing (git add, git commit)
  • Visualize GIT committing, branching, checkout, and merging (git commit, git branch, git checkout, git merge)
  • Visualize GIT local and remote repositories (git pull, git push)
• Other notes:
  • every commit is identically referenced by a SHA1 hash, which looks like ea24566c0f80b811d681b3a28bc42f52565444b7
  • git diff allows you to see the exact changes
    • you can git diff file1 file2 to see the differences between two files
  • git rebase allows you to move a branch
  • git log allows you to see the commit history
    • I typically use git log --graph --oneline --decorate --all
  • git stash allows you to temporarily save your changes so you can switch branches or start over from the last saved commit
    • git pop will bring those temporarily saved changes back
    • be careful when using git stash and git pop; you really have to know which stash is going to be brought back and how
  • The entire GIT repository is stored in the .git folder
  • All of the GIT configurations are located in .git/config file
  • When first learning, it is best to use the git status command before each GIT command to make sure the state of the files are in the state you think they are