I admit, my understanding of revision control is quite limited. So I sat in on David Humphrey’s OSD class to learn more about Git.
- Client server model
- highly centralized
- checkout – gets the tip of the trunk (most recent revision). Your local copy (working copy)
- commit – sends change set (difference between trunk and your working copy)
- update – update your working copy with new change set.
RULE: DO NOT BREAK TRUNK
Suppose person A and person B checkout version 351 on the same day. Person A changes some code and commits it back to trunk. person B will have to update their version (pulls down change set ) and resolve conflicts.
Distributed version control. Not centralized model.
- Clone – similar to checkout BUT, you are making a copy of the entire tree (not just the most recent change
- Fork – create a split locally
- Merge – merges a fork back
File states with GIT. When working with GIT, your files are in one of 3 states:
- Committed: – committed to the repository
- Staged: – inbetween state, git is aware of file but its not yet in the repository
- Modified: – working copy not in repository
GIT Command summary:
- git help command <command>
- tells you how a command works
- git status
- gives status of files
- git add <file>
- stage a file
- git commit -m <message>
- git diff
- space in front of a line, line is context line to show you where change is
- + line added
- – line removed
If there are files that you want git to ignore (ie don’t track and don’t tell you its not tracking it) you can create .gitignore. You can add specific files or patterns. For example:
- *.o to exclude object files