In a perfect world, a software developer is assigned tasks. They then work on those tasks uninterrupted until the tasks are completed. Following that, they move on to another assignment, with a perfectly coded feature in existence in the team’s shared branch. However, we don’t live in a perfect world, and this process for development often does not occur as just described. Instead, a developer’s professional life is often complicated and requires flexibility to the point where current tasks may need to be set aside for a time. This is just one situation of several where shelving your code may be the best option.
What exactly is shelving?
You may be asking yourself what exactly we are referring to when we say “shelving” code. Shelving is a feature that is available through the use of Team Foundation Server (TFS) from Microsoft, a tool for source code management. This feature allows us to create what is known as a “shelveset,” which will essentially hold our local changes in the repository without committing them to the shared codebase.
Shelving code in TFS gives us more flexibility with our local version of our codebase. A few key aspects of this stand out as far as convenience functionality:
- Once the code is “shelved,” the user has the option of reverting their local environment back to the current state of the common codebase, or they may keep their pending changes that were committed to their shelveset in their local environment.
- Shelved code can be viewed by others with access to the repository. Upon shelving, the code can be “unshelved” by any member of the organization with access to the repository.
When should we shelve our code?
The question remains: When is it appropriate to shelve our code? In what scenarios that occur regularly during development is shelving an option that provides us with some value? A few use cases come to mind.
The first scenario is dealing with a higher-priority task. Let’s envision a scenario where you have been working on a new feature over the past week. Your local environment has changed drastically from what is currently in source control. However, you are now required to start working on a completely new task that is of a higher priority and needs to be completed within the next day. If the new task requires you to work on any of the files you have been editing for your new feature, then it may make sense to shelve your code. You can create a shelveset on the source control server that contains your pending changes for your new feature, and then roll back your environment to the current state of the application. This will allow you to essentially obtain a fresh copy of the application’s code for working on the new task. And when you are done, simply unshelve the code you were working on and continue the job you were forced to step away from.
Another instance where shelving can be useful is in the interest of collaboration, such as performing a code review on changes before the code is integrated into the main branch. Shelving the code for others to then unshelve and view is a good option for allowing other developers to take a look at an implementation and ensure it’s ready for integration. The same goes for collaborating in all fashions. Maybe you have been working on a new feature that another developer on the team intends to finish. Rather than committing an unfinished changeset to the main branch, it’s an option to shelve the code and allow another developer to unshelve it to continue making changes. When the other developer finishes the feature, he/she can merge it back into the main branch and you are good to go.
Conclusion
As with any other feature, shelving has its use cases where it can prove to be of great value to the developer. Shelving can be described as a lightweight commit feature that allows us to preserve code on the TFS server without creating our own branch or committing to the main branch. In situations where a developer needs to be pulled off what they are working on, and a clean local environment free of pending changes is required, shelving may be the best option. Shelving can be of value in other instances as well, such as a small feature completed and up for a code review, or even an uncompleted feature that needs to be passed on to another developer to complete. When used properly, shelving can make a developer’s life easier by providing flexibility with the local version of the codebase, and providing a simple way to share code with other members of the team.
