Join Michael Lehman for an in-depth discussion in this video Saving changes and tracking history, part of Learning Software Version Control.
Once you've got your files in, and you can get your files out, the typical workflow when using any Version Control System looks like this in your repository. At Time 1, you can see that there's a file in your repository that contains A, B, and C. Let's say you check it out and then you delete B and you add D. Now when you save your files back into the repository, use a command that's called commit, check in, or update. When you command the Version Control System to save your updated file, it will ask you for a short description of the changes you've made.
This is oftentimes called a commit message, and this is a crucial part of the history of tracking information. The system will store the differences between the two different versions of the file, and you supply the reason. In some systems you can supply a single line, and in some systems you can actually supply not only a single line which is used in short displays, you can also provide an entire document that describes what it is. Reference bugs that are fixed by this have hyperlinks to websites that have appropriate references and so forth.
Once you've added a file to Version Control and made a change and checked it back in, your Version Control System can now show you the history of that file. So, we can see here we have the file here at T1 with our initial commit, then we have two versions of file, and we add D, and now three versions of the file when we deleted B, and four versions of the file when we add E. Each item in the history will show you not only what is changed between one version and the other, it will also show you who made the changes, and what that person said about those changes. In this case, initial commit, adding D, deleting B, and so forth.
It's important when creating commit or check in messages to be as descriptive as possible, because you may come back later and your memory may be a little fuzzy as to what you changed, or when you're working on a team, someone else may be reading your commit message and want to learn to understand what you did. Many systems allow you to create a one-line short commit message, and in certain systems, you can also create a longer descriptive message in which you can be more detailed in terms of what you've actually changed. You can add hyperlinks, you can add references to documents, you can add references to bug numbers.
When you're using the Command Line tools, you can only add the short version, or if you leave the short version text off, the Command Line version of the tools will open up in the editor to allow you to put in both the short version, and the subsequent long version on subsequent lines. If you think back to our demo when I typed in git commit -a -m and then put that string in quotes, if you leave the string off, it will open up an editor, showing you the information about what files have changed, and allowing you to enter in both the short and the long version, keeping track of the changes, automatically backing up your files, recording why something was changed, and who changed it is the essence of Version Control.
- Comparing centralized vs. distributed systems
- Saving changes and tracking history
- Using revert or rollback
- Working with the GUI tools
- Using IDE and shell integration
- Installing different systems
- Creating a repository
- Tagging code
- Branching and merging code
- Selecting a software version control system that's right for you