Many of my experiences as a software developer have involved version control. I've designed and performed migrations from one version control system to another and acted as a focal point for the version control of the development team. I have encountered some practices that, when followed, can make teams and projects work easier and better.
What Is Version Control?
For starters, version control systems are used for managing file changes by multiple users while still preserving history. It is widely used by software developers on a daily basis.
It is important to save all of your relevant files under version control. Aside from just code, there are also scripts and other related files that are often changed. The main repository must be managed and backed up properly.
It is important to populate existing file changes via the version control commands, meaning by merging, copying, moving, etc., all while avoiding or reducing manual operations.
Some common use cases include the rolling up or rolling down of a bug fix or feature to a different version and refactoring and renaming a file or directory.
Doing this has benefits, such as that it should be easier to do than manual changes and it should be helpful for avoiding mistakes. Additionally, the full relations history is preserved and developers can see via a graph who did what changes originally with more details. Files will not be not replicated in the server.
You can also isolate files. In some versions, specific files can be isolated so that they will not appear in merges.
Being able to shelve and stash is another very useful option, and should definitely be used when needed. This option allows you to save your not-yet-finished task files into the repository without the need to submit them to the version. This can be useful for temporary backup and for sharing with other team members, as opposed to needing to manually share and merge files.
Development versions ( / branches / streams)
Generally, when one or more developers are working on a task (even if it is only a few days of coding long), a development version is recommended to be opened. This way, developers can submit often for version history, back-up, and sharing.
Working as a Version Control Focal Point
Moving on, I learned a lot during my time as a version control focal point. So things were learned from good experiences; others, not so much.
You should rename files and directories via the version control system. This way, the physical file is not replicated to the server. Additionally, the full history is preserved and can be seen in a graph.
You can merge a hotfix from one version to another via the version control merge feature.
This is also commonly used for hotfix rollups.
Putting version related files which are often changed under version control.
Less Good Experiences
You should not submit a few non-related changes in one change list. This caused a mess. When only one of the changes had to be merged to a different version, it was going to be hard, time-wasting, manual work.
Don't save a lot of work locally without submitting for a long time. Note: sometimes, this is caused by developers avoiding opening development versions.
It's a bad idea to put files in version control that aren't recommended to be there, like generated files from the build process and large binary files that are not changed.
In summary, the version control system is here to help developers, and when used properly, it can be very helpful.