Pull Requests (or whatever their equivalents are called in your favorite Git distribution) are a norm. Most of us adopted them as the primary way of reviewing and accepting changes that will ultimately be deployed to production. They work hand-in-hand with feature branches.
If you are using Windows, please make sure that Git is configured to use “Checkout as-is”. This can be accomplished during the setup by selecting the second or third option from the screen depicted below. Also, if you do not have SSH installed, please make sure that [PATH_TO_GIT]\bin is added to your PATH.
This article will try to compare GitHub, GitLab and BitBucket Server (previously called Stash) installed on your own servers. Similar comparison of cloud offerings is outside the scope of this article. I won’t try to go feature by feature in some kind of a table so that you can count who has more features. I find that approach often misleading even though it’s very commonly used among companies (especially where there is a software architect around). Instead, I’ll give my opinionated view.
You got that great idea for an application that will be a huge success. High level feature set and design is done and you are ready to start bashing the code. Before you do, you might go through a checklist of tasks that should be done before the coding starts.
There are three things that I consider as prerequisites of every project (apart from knowing what the high level scope of the project is).
- Some kind of a project management tool or a task tracker
- Version Control System (VCS)
- Continuous Integration (CI) framework with jobs for each phase from the build to deployment
I, for one, am often inclined to simply start bashing the code. However, that temptation should be avoided in favor of a better and more stable project development.