Embedded development: five revision control best practices

　　 Every embedded software developer should use version control system . When something has been damaged , And cannot be undone , The ability to go back to the previous version is a lifesaver . Even if embedded developers know and use the revision control system , They should also use some best practices , To ensure that their revision control system is fully utilized .

　　 Best practices 1– Exclude debug folder

　　 The debug folder contains all the target files generated by the compiler for the source project 、 Binaries and executables . Although the team may want to save the released versions of these files , However, there are several disadvantages in saving them in the revision control system :

　　l Goals and executables are often large , It will soon exhaust a lot of space in the revision control system

　　l When the revision is checked out , Developers should use their own tool chain to build , Don't rely on files compiled under different conditions

　　l Unchanged files may be in different states , And cause unexpected behavior when executing software

　　 For these and other reasons , Embedded developers should avoid saving debug folders and their contents in the revision control system .

　　 Best practices 2– Use “ Ignore ” function

　　 Most version control systems , Such as git or mercurial, Both have the function of ignoring certain files and file types . A good way to use this feature is for objects that the repository system should ignore and not add to the repository 、 Executable files and other files create an ignored entry . The exact method of how to ignore file types will vary from version control system to version control system . The best way is to consult the user manual .

​　　

　　 Best practices 3– Submit a detailed submission log

　　 When developers submit code to a repository , Or do not add comments , Or add few comments , So that it is impossible to determine what has actually changed in the code base . Have a detailed list of code and changes , It is critical to rollback and find previous versions when needed . Countless times , Something in the software broke , Embedded developers need to check logs , And determine when the feature was added or modified . If there is no detailed log , This process becomes a time-consuming nightmare . Each log should contain some key information :

　　l Software version number

　　l What is added to the software , Where to add

　　l What has been modified in the software , Which modules are affected

　　l Contains a list of all currently known unresolved issues for the software version

　　l Any useful general comments

　　 Best practices 4– Synchronize frequently

　　 Revision control systems are only useful when developers who use them often synchronize their software libraries . Not submitting code for a few days or weeks is like asking for trouble . If developers don't get the latest changes frequently enough , The same problem can arise . Their software will soon be out of sync with the rest of the code base . therefore , Embedded developers need to ensure frequent synchronization . If they don't do that , They may find themselves spending too much time trying to merge their code into the main branch .

　　 Best practices 5– label / Branch officially released

　　 When a code base will be released to the wild , Separate the code by branching or marking it as officially released . Separating these codes will make it easier for developers to go back and find the code version . Code marked or branched into formal versions should not be modified in any way , It should be kept as an original copy .

　　 Conclusion

　　 Following these best practices will help ensure that you not only use revision control systems , You can also get the maximum benefit from the system . If used properly , Revising the control system can save time and energy , These best practices will help ensure that embedded developers make full use of their systems .