
I love Git for its efficiency in source code management, its user-friendly interface, and how straightforward it makes deploying applications to GitHub Pages or integrating with external hosting services such as Vercel, Render, and Netlify.
I especially appreciate Git’s ability to make repositories public, making it easier to share and distribute code with the wider developer community. This gives contributors greater visibility into projects while encouraging collaboration and knowledge sharing.
I also value the flexibility Git provides through private repositories, open-source licensing, and organizations for effective team collaboration, while still maintaining control over access and privacy. Review collected by and hosted on G2.com.
It’s not quite a dislike; however, I would recommend that Git improve its merge and pull request workflows. In my experience, these workflows can feel overwhelming, especially for developers who are still learning how Git handles branches, conflicts, and synchronization.
I once worked on a remote project with a team of junior developers. Whenever they pushed code to our development branch and encountered a merge conflict, I often had to join a call with them to walk them through the conflict-resolution process. I explained Git merging and conflict resolution to them several times, but they still found it difficult to understand what was happening and how to resolve conflicts confidently on their own.
This became quite hectic and time-consuming, especially since we were working towards a deadline and I had my own tasks to complete. Because of this experience, I feel that Git’s merge and pull request workflows could be more beginner-friendly, with clearer guidance to help developers understand what to do when conflicts occur. Review collected by and hosted on G2.com.


