Guidelines For Using Code Repositories

Aasim Naseem 2

Today I’m a little technical. I will talk about code repositories and their usages. This is an essential checklist for playing with code repositories. Everyone needs to follow this.

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

What is a 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?

The checkout means you get/download code from the repository to start your work. A copy of files downloads to your system for further changes.

What is commit/checked-in?

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

What is a code update?

Update means you synchronize your downloaded/checked out code with the repository. Anyone else who has checked in/commit some changes in the repository, those changes will be merged/added to your copy of the codebase. Your changes will not be sent to the codebase until you commit/checked-in them.

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




General guidelines working with code repositories 

Before starting your work

  • Always update your code before the 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 the latest/updated version of code to start your work.
  • It will also prevent having so many conflicts while updating/committing at day end with the bulk of code need to synchronize between you and the code repository.
When you have made your changes and are ready to commit your code;
  • Confirm that your changes are working fine on your machine.
  • Update your code again, so that you may have the 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 confused, don’t make any assumptions and instantly ask someone to help out. It’s a very sensitive step and needs 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 something isn’t going good (compile-time error or application’s behaviour isn’t proper in some scenario) ask your lead to verify, or discuss with your team member to resolve them. It normally happens when you are working in a team and some program logic conflicts between two developers when the code repository merge the codes. (it is one possible cause, some other reasons might be there)




When everything is good. It’s time to commit your code.
  • Check the status of files you have. If there are some un-versioned files (those files which you added in your project manually like images, new classes etc) First add them to the repository using add option.
  • Once new files have been added to the repository, commit your code using the commit option. Make a habit of providing proper comments while committing. It will not only help you but others too to know what changes were made in a specific version. Sometimes we need to get the old status of code (from some older revision) so in such a situation comments helps a lot to track the changes and status of the codebase.
  • After committing, check the status of your code again using the status command. There shouldn’t be any edited/modified and newly added files that need to commit. Your codebase should be clean and fully updated.
Important Note.
It is found that sometimes developers commit their code at day end. It’s not a recommended practice at all. (at least 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 the time of update/commit. It will take a lot of time to resolve them properly.
Remember
  • Before the start of any change, update your code.
  • As soon as you fix a bug or made such a change that your code is in working stable form, commit that change. Don’t Keep your change till day end. Be Updated and let others too.

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

Anyone who feels hesitation or fear while updating/committing code, keep a copy of this checklist and make sure not to miss any point. Ask your peer or lead instantly in case you are confused about what to do next. I’m here too to clear any query regarding the repositories usage.

Happy Development.

 


Comments 2

    1. You can, if and only if you can digest some techno terms. It will be dry for a person who designs and crafts creative things. ((:

Leave a Reply

Your email address will not be published.