Guidelines for Using Code Repositories

Category: My Tutorials > Code Repositories

Hello everyone;

Hope you are doing good at your desks;

Today im lil technical; Will talk about code repositories and their usages; This is an essential checklist for playing with code repositories; Everyone need to follow this;

If I miss anything, or any point where you feel something need to describe more clearly, kindly correct me;

So lets starts;

What is source code repository?
A source code repository is a place where large amounts of source code are kept, either publicly or privately. They are often used by multi-developer projects to handle various versions and developers submitting various patches of code in an organized fashion. (definition from wikipedia)

What is Checkout?
In svn or cvs, checkout means you get/download code from repository to start your work; A copy of files download to your system for further changes;

What is commit/checked-in?
commit/checked-in mean you are sending your contents/changes to code repository; Your work will be available to others when they will checkout/update from same code repository;

What is update?
Update mean you synchronize your downloaded/checkedout code with repository; Anyone else who has checked-in/commit some changes in repository, those changes will be merged/added to your copy of code base; Your changes will not be sent to code base until you commit/checked-in them;

So here we go; These guidelines will help you to use code repositories in best way while working individually or in a team;

Before start of work;

Always update your code before start of your work; Tts more important when you are working in a team, so if anyone else has committed some code after your last update, you may have latest/updated version of code to start your work;
It will also prevent having so much conflicts while update/commit at day end with bulk of code need to synchronize between you and code repository;

When you have made your changes and ready to commit your code;

Confirm that your changes are working fine at your machine;
Update your code again, so that you may have latest code; (update once before starting your work and once when you are going to commit)
If there are some conflicted files, resolve them very carefully; At any point if you are confuse, don’t made any assumption and instantly ask someone to help out; Its a very sensitive step and need much attention and care;
Once you have updated code and conflicts has been resolved, build and run the application again; Confirm your changes and those areas where you resolved conflicts, and/or have merged/updated files;
If you feel somethings isn’t going good (compile time error or application’s behavior isn’t proper in some scenario) ask your lead to verify, or discuss with your team member to resolve them; Its normally happen when you are working in team and some program logic conflicts between two developers when code repository merge the codes; (it is one possible case, some other reasons might be there)

When everything is good; its time to commit your code;

Check the status of files you have; If there is some un-versioned files (those files which you added in your project manually like images, new classes etc) First add them in repository using add option;
Once new files has been added to repository, commit your code using commit option; Make a habit of providing proper comments while commit; It will not only help you but others too to know what changes were made in a specific version; Sometimes we need to get old status of code (from some older revision) so in such situation comments helps alot to track the changes and status of code base;
After commit check the the status of your code again using status command; There shouldn’t be any edited/modified and newly added files need to commit; You code base should be clean and fully updated;

Important Note;

It is found that sometimes developers commit their code at day end; Its not a recommended practice at all; (atleast in my opinion). Always commit your code when you feel your code is in stable form after your changes; Keeping your changes till day end will maximize the chances of conflicts at time of update/commit. It will take your lot of time to resolve them properly.

Remember

Before start of any change, update your code;
As soon as you fix a bug or made such change that your code is in working stable form, commit that change; Don’t Keep your change till day end. Be Updated and let other too;

Moreover, it is common that different developer use same svn user to update/commit their code; So in such situation, mention your name in svn comments at time of code commit so that it become more clear to know who committed what and when;

Anyone who feels hesitation or fear while update/commit code, keep copy of this checklist and make sure not to miss any point; Ask your peer or lead instantly incase you are confuse what to do next; I’m here too to clear any query regarding the repositories usage;

Happy Development;

Author Profile

Aasim Naseem

Hey, Thanks for your interest. I’m a PMP, AWS Solutions Architect, and Scrum Master certified professional with 17+ years of hands-on experience leading projects, building teams, and helping organizations deliver software solutions better, faster, and smarter.

Outside of work, I’ve got a deep curiosity for history — especially ancient civilizations like Egypt. I also enjoy reflecting on the everyday moments that shape how we live and work. This blog is my space to share insights, lessons, and thoughts from both my professional journey and personal interests.

Thanks for reading — and I hope you will find something here that matches your interest.