Devtov Online — Version Control Systems Explained | devtov.online
An ordered routine: put files in a working copy, save them with a commit, create a branch for a fix, keep the trunk for features, merge the branch back.
Start with a working copy — the set of files on disk where edits happen. Edit the files, then commit: a commit writes working-copy changes into the repository, creating a revision that everyone with access to the repository can see. A checkout retrieves those changes back into a working copy, which is how you load someone else's work or return to an earlier state.
When a bug must be fixed without disturbing feature work, create a branch. Branches let one line of work fix bugs while another adds features: the trunk keeps receiving feature commits while the branch receives fix commits. Work the fix to completion on the branch and commit each step.
On narrow screens, swipe or scroll the plate sideways.
When the fix is ready, merge the branch back into the trunk. A merge rejoins the two lines, adding an extra edge to the history graph. After the merge, both lines' commits are reachable from the trunk.
Two failure modes dominate this routine. Uncommitted work exists only in the working copy, so it is invisible to collaborators and to any backup that reads the repository — the fix is lost the moment the disk fails. Renames that cross a branch boundary produce merge conflicts, because the system must decide whether a renamed file is one file or two; if it tracks the rename the merge is clean, and if it treats the rename as delete-plus-add the merge reports conflicts on every affected file.
A practical order for the first session: edit, review the diff, commit, branch, edit again on the branch, commit, merge, and verify the result on the trunk. Each step is reversible — revisions can be compared, restored and, with some types of files, merged — but only if the work was committed before the next step began.
Further reading