Professional C__ - Marc Gregoire [414]
Don’t Be a Renegade
Whether a process is mandated by your manager or custom-built by the team, it’s there for a reason. If your process involves writing formal design documents, make sure you write them. If you think that the process is broken or too complex, see if you can talk to your manager about it. Don’t just avoid the process — it will come back to haunt you.
SOURCE CODE CONTROL
Managing all source code is very important for any company, big or small, even for personal developers. A software solution is required to manage all source code in a central place. In a company for example, it would be very impractical to store all the source code on the machines of the individual developers. This would result in a maintenance nightmare because not everyone will always have the latest code. All source code should be stored in a central place and should be managed by Source Code Control software. There are three kinds of Source Code Control software solutions:
Local: These solutions store all source code files and their history locally on your machine and are not really suitable for use in a team. These are solutions from the 70s and 80s and shouldn’t be used anymore. They are not discussed further.
Client/Server: These solutions are split into a client component and a server component. For a personal developer, the client and server components can run on the same machine, but the separation makes it easy to move the server component to a dedicated physical server machine.
Distributed: These solutions go one step further than the client/server model. With a distributed solution, the developers don’t need to be connected to the same company network. They can work on the same source code from anywhere in the world over the Internet.
Both the client/server and the distributed solutions consist of two parts. The first part is the server software, which is software running on the central server and which is responsible for keeping track of all source code files and their history. The second part is the client software. This client software should be installed on every developer’s machine and is responsible to communicate with the server software to get the latest version of a source file, get a previous version of a source file, commit local changes back to the server, rollback changes to a previous version and so on.
Most Source Code Control systems have a special terminology, but unfortunately, not all systems use exactly the same terms. The following list explains a number of terms that are commonly used:
Branch: The source code can be branched, which means that multiple versions can be developed side-by-side. For example, one branch could be created for every released version. On those branches, bug fixes could be implemented for those released versions, while new features are added to the main branch. Bug fixes created for released versions can also be merged back to the main branch.
Checkout: This is the action of creating a local copy on the developer’s machine based on a specified version of the source code on the central server.
Checkin, Commit, or Merge: A developer should make changes to the local copy of the source code. When everything works correctly on the local machine, the developer can checkin/commit/merge those local changes back to the central server.
Conflict: When multiple developers make changes to the same source file, a conflict might occur during checkin of that source file. The Source Code Control software often will try to automatically resolve these conflicts. If that is not possible, the client software will ask the user to resolve any conflicts manually.
Label or Tag: A label or tag can be attached to all files at any given time. This makes it easy to jump back to the version of those files at that time.
Repository: The collection of files on the central server is called the repository. This also includes metadata about those files, such as checkin comments.
Resolve: When checkin conflicts occur, the user will have to resolve them