Project management and git

My inspiration for this blog post was the git hell I have endured this week. I’m currently on the last day of my project week in the 3rd module of my flatiron Bootcamp. My project could be anything I wanted it to be so long as it was a single page web application. With my enjoyment of games and drinking me and my group decided to make a pub quiz application with the intent of a bar running it and allowing customers to order drinks through it. My entire week, however, has been fixing merge conflicts that should never have happened in the first place. Hours wasted making sure the most current and correct version was available to everyone on my project and running as intended.

Plan your project

One of the biggest problems with working with legacy code is when you change how a feature that already exists works you could end up breaking thousands of lines of code which work with that specific line of code. While my git hell this week was working with code written during the week, we failed to plan out the entire project before getting started. Features made at the beginning of the project were not compatible with features designed and developed near the end of the project, which means that for a new feature to work, the base code required altering to allow this. Doing this meant we needed to have someone rewrite entire aspects of the project and then merge it with our most up to date version, this caused any work done during this time which could be using the previous code would break the moment a merge happened.

When starting any project, you should make a thorough plan. Think about what data you will store in your database, and how this you intend to organise it, decide on how your user experience will be, and what project files and folders you will need to have a neat repository. By choosing this ahead of time, you will be on the road to success. Having to make any significant changes to these concepts down the road will cause you a massive headache as you will be rewriting code when you could have just written it correctly the first time.

Separate files for separate concerns

One of the biggest mistakes made by myself and my team was when setting up the project setting up one javascript file to contain all our code. Then never making a new file for the unique aspects of our project we wanted to build. While this worked fine and we weren’t experiencing any bugs from doing this, the code started to become a monstrosity. When trying to fix a problem or add a feature, we needed to navigate lots of irrelevant aspects of our program as it was all to do with other aspects of our program.

Part of proper planning is about deciding what aspects of your code will exist in your final project. You might miss something, but you should have an idea before you get to heavily invested in doing your project in a certain way only to find out it all needs rewriting.

In my project this week we failed to think of this beforehand and as such a few days in we realised we had one large file which was impossible to navigate. Eventually, we decided to get together and split it out into its general concerns. Because of how intertwined the project had been allowed to become, this was an excruciating process. Ultimately it was for the best, and our code became more comfortable to read, navigate, and improve.

Keep versions as up to date as possible.

When working on a project where there are many moving parts and multiple software engineers pushing updates regularly it is crucial to make sure any new feature you are working on is using the most up to date version. A fair amount of the git hell I experienced would have been easily avoidable if everyone’s base code had been the same as everyone else before they started working on a feature. Sticking to this concept, you will find yourself with more controllable conflicts that have the least amount of bleeding into other features as you might create code which already exists.

You should merge your code as frequently as possible in as small doses as possible this will allow you to reduce your conflicts. By doing this, it will enable you to write code that builds on previous commits that your team members have written, allowing you not to have to reinvent the wheel every time and rely on previously written functionality. Also means you run less risk of writing the same function with the same name causing git to have a meltdown when seeing the same function written for the same purpose but very differently.

Bite-sized features for tastier merges.

A lot of the conflicts I experienced this week were because of features touching up or correcting a lot of other code. Refactoring code is essential, and no one in their right mind will say otherwise. However, this should usually be kept in a different branch and be specific to the feature you’re updating. By doing this, you can merge the distinct branches one by one, allowing you to see the exact changes happening within that particular update rather than one massive merge where code gets lots and bleeds into one another.

Last night, in particular, we had three big merges all having to be put into the project; this was my most prominent feeling of git hell this week. I spent over an hour getting the final two versions to merge while on a zoom call due to the features overlapping each other and touching too many irrelevant things causing git to make weird conflicts that shouldn’t have been happening.

Conclusion

While this is only a brief overview of project management, it is essential to consider it at every step of the way and level up your skills in project management and git. By doing this, you are setting yourself up for success when making your projects more scalable and as such more powerful.

For those who are interested in the project which inspired this post is here https://the-waiting-game.netlify.app/ credit goes to both Dinno Roni and Lee Bardon who were the best team, I could have asked for this project.