Tag Archives: software

What Is Git

Posted on by
2

Git is a distributed revision control system (RCS). Git is open-source and focuses on speed. It was originally developed by Linus Torvalds for the Linux Kernel Project.

Revision control systems allow developers to keep track of the changes they make to their code. Before such systems existed, developers would keep backups of their files in case their changes would break something. In case it happened, they could easily revert to the previously working version.

Such systems are an essential part of any technology business. Without them, it would be very hard to release early and often, quickly revert buggy releases of software, etc.

What Is A Distributed Revision Control System

Decentralized revision control systems (like Git) allow developers to :

  1. Track changes to their code;
  2. Work in teams without having to fear overwriting someone else’s code;
  3. Work on a given project without needing a central server for hosting the code.

Other systems like CVS or Subversion (SVN) are centralized. This means that they require a main repository to exist. Each developer then checkouts a working version from this main repository, and commits back changes when they are complete. In a decentralized system, there is no main repository. Each developer has it’s own complete repository and changes are exchanged across developers.

How It Works

Conceptually, there are many ways to work with Git. This is what is beautiful with decentralized systems, they allow the team to choose what best suits their needs. Let’s explore two common methodologies :

  1. Every team member has a private and a public repository.
    In this case, each developer has it’s own private repository where he can freely change code, revert modifications, etc. When changes are ready to be shared with other developers (code is tested, compiles or parses and is believed to be bug-free) it is pushed to the developer’s public repository. The public repository is remotely accessible by other developers. The rest of the team can then pull the newly committed changes in their own private repositories. This way of working allows team members to easily add only the changes they want in their working versions.
  2. Every team member has a private and share one master repository.
    Again, each developer has it’s own environment for working, but instead of having one public repository for each, there is only one master repository which is remotely accessible. It makes it easier for changes to propagate to everyone (each team member has only one repository to pull changes from).

Making your repository available to your team

It is up to the team to decide where is the right place for hosting the remote repositories. Git can be remotely accessed from anywhere (HTTP, NFS, etc.). You can even share your repositories on Dropbox (something that was not possible with Subversion). There is also the famous GitHub.

What revision control tool do you use? Where and how do you share changes to your code? Feel free to add your methodology in the comments.

Why nine women can’t make a baby in one month

Posted on by
4

In software engineering, when schedule slips, it can be tempting to redirect or add new resources to an important project. However, most of the time, boosting the number of resources in a project’s late stage has exactly the opposed effect: it takes more time. This principle is called Brooks’ law.

Adding more people in a project won’t necessarily make it happen faster. Software engineering is complex. First, it definitely takes some amount of time to the newcomer to understand and get used to the existing environment (existing code, development environment and most importantly, the team). Second, increasing resources also increase communication overhead. The information flow must go through all team members, in a clear and efficient way. Finally, you might also drain your existing resources’ energy and time by asking them to train and to coach the others.

For late software development projects, sometimes finding better ways to do more with less, simplifying processes and eliminating any nuisance to the team is better than giving more.