Git With the Program: Superior Codebase Management
Overall Satisfaction with Git
Our organization uses Git for code versioning, namely to track and manage changes to the codebase in a way that avoids accidentally writing over another engineer's code, resolves change conflicts, and provides a rollback option in the event of a breaking change. Git has become an important part of the development workflow for most software engineering teams. The problem Git addresses for us is the problem of having multiple people updating a codebase. One developer might change a portion of the code in one area and another might change it somewhere else, and managing the merging of these changes together is the main job of Git. To facilitate this Git stores every committed change in a log, and this log can be reviewed and even used to roll the code back and reject changes further down the pipeline. In our organization, each engineer creates a new branch from the master codebase whenever they are starting a new task in the project, and once they have completed that task and confirmed the code is stable, the code can be merged into the master codebase and eventually included in the production build. Our team has a strict policy of not merging your own code, so the code is reviewed and approved by another engineer whom merges it in after assessing its impact. We use Git across our engineering department only.
Pros
- Git manages the merging of changes from different team members and provides for a way to roll back those changes when necessary.
- Git allows for management of multiple branches of a code project and merging them in through a controlled and considered manner.
- Git provides a complete history of all code changes and who made them, making the process of identifying when breaking code came in a much easier one along with identifying the code to roll back to (when needed).
- Git is a powerful tool for change management and avoiding breaking code making its way into production.
Cons
- Git has a steep learning curve in that it has traditionally been used through the command-line interface, and has a lengthy set of commands you must learn how to use to work with it efficiently. Fortunately, there are some good GUI-based applications to help you with this, but to really be a Git master you will have to know how to use in from the console.
- At times it can be difficult to determine just what action is appropriate when a mistake has been made in a Git commit. A deep understanding of how Git works can be required to correctly navigate the steps to recover from a bad commit.
- Git could benefit from an overhaul of its command syntax to focus on the subset of Git commands that most developers use all the time.
- Some Git commands have names that can prompt misunderstandings as to what they actually do. A prime example of this is "git blame" which simply tells you whom made a specific change to the code, but sounds like it is going to automatically report someone to their boss for a dressing-down.
- Git has saved our organization countless hours having to manually trace code to a breaking change or manage conflicting changes. It has no equal when it comes to scalability or manageability.
- Git has allowed our engineering team to build code reviews into its workflow by preventing a developer from approving or merging in their own code; instead, all proposed changes are reviewed by another engineer to assess the impact of the code and whether or not it should be merged in first. This greatly reduces the likelihood of breaking changes getting into production.
- Git has at times created some confusion among developers about what to do if they accidentally commit a change they decide later they want to roll back. There are multiple ways to address this problem and the best available option may not be obvious in all cases.
Comments
Please log in to join the conversation