Version control

Editor's Notes

• #4: The code programmers write changes often. Bugs need to be fixed, features need to be added, and content needs to be changed. Most code is stored as plain old text files, and the code is changed by editing these files. Every time a change is saved, the old version of the file is overwritten with a new one. Unfortunately, no programmer is perfect, and sometimes, mistakes are made. If you make a change to a file, save it, compile it, and find out that something went wrong, it's often helpful to be able to go back to the old version or to get a report of what was actually changed, in order to focus on what may have gone wrong. That's where Version Control Systems come in.
• #5: Centralized version control systems are based on the idea that there is a single "central" copy of your project somewhere (probably on a server), and programmers will "commit" their changes to this central copy.   Distributed version control systems do not necessarily rely on a central server to store all the versions of a project's files. Instead, every developer "clones" a copy of a repository and has the full history of the project on their own hard drive. This copy (or "clone") has all of the metadata of the original.
• #6: Repository: Database with the complete revision history of all files under version control Working Copy: Local directory of files under version control where you can make changes Revision/Version: Snapshot(set of changes, state) of file or files in a point of time. Trunk/Master: The primary set of files in repository. Branch: A copy (or snapshot) of the repository that can be tracked in parallel without altering the main copy. Head: The latest revision in current branch.
• #8: What, who, why and when: Knowing the what, who, why and when of changes. That helps comparing the performance of particular versions, working out when bugs were introduced (or fixed), and so on. Any problems that arose from a change can then be examined by what, who, why and when of the change. Compare revision: Developers may wish to compare today’s version of some software with yesterday’s version or last year’s version. Coordinating Teams: Allows Team to share resources. It lets one contributor work on a copy of the resources and then release their changes back to the common core when ready. Other contributors work on their own copies of the same resources at the same time, unaffected by each other’s changes until they choose to merge or commit their changes back to the project. Branching: You can use branches to work on longer-term tasks and then merge the branch back into the main line when it's done. Maintains separate “Production” versions of code that are always deployable. It let you have multiple parallel lines of development. You can work in two simultaneous features without interference and switch back and forth without much hassle. Backup: You can have a backup. You can recover any revision of any file based on date or on a milestone that you defined. History: You can have a history of changes.