Skip to main content

Workflow and Pull Requests

One of the main reasons we use Git is collaborative security. In a serious, real corporate environment NO ONE (not even the technical leaders) theoretically has permission to upload code directly to the main branch using git push origin main.

If everyone could freely push code directly to production, any human error could break the application or delete critical things!

To prevent this, all new code enters through formal requests called Pull Requests (PRs) in GitHub, or Merge Requests (MRs) in GitLab.

🛠️ The Complete Professional Cycle​

The natural flow followed by almost all companies on the planet is as follows:

1. The Detour (Branching)​

A programmer is assigned to build a new red button for the home page. The first thing they do on their computer is download the latest from the current version and derive an exclusive branch:

git switch main
git pull origin main
git switch -c feature/red-button

Now the developer is in a contained "safe" environment. Everything they do here will not touch the official main environment.

2. Development (Committing)​

The programmer writes their HTML code, saves the changes step by step, and packages the finished package into commits:

git add .
git commit -m "feat: Add red button structure and CSS animation"

3. Uploading the proposal for review (Pushing)​

Now the developer uploads their independent branch to the GitHub servers and databases.

git push -u origin feature/red-button

Their computer has done its job, now the GitHub web platform takes over. This last command "uploaded the branch" with the code, but main still doesn't know this happened nor has it absorbed the work.

🚪 What is a Pull Request (PR)?​

It is a formal web form where you politely tell the administrators of the main project:

  • "Hey, I have new code ready on my branch and I propose that I be allowed to incorporate it into the real company project".

4. Creation of the PR and Approvals​

On GitHub, you will immediately see a bright green button above your repositories that says "Compare & pull request" after pushing. You click it. You can write an explanatory title.

From this moment on:

  1. All the engineers (or colleagues) on the team receive a notification by email or Slack that a new PR is waiting.
  2. They log into GitHub and review your added code line by line before it is accepted.
  3. They leave "Comments" suggesting variable name changes and ask you to make improvements ("Code Review").
  4. On your computer, you make the requested changes, run git commit and git push again to your same branch, which will magically update the PR in the cloud.
  5. When the whole team agrees that your code is ready, they click a button that says "Approve".

5. Finalize and Merge​

Once formally approved by peers, someone makes a massive click on a huge green button named "Merge Pull Request". Behind the scenes, in the cloud, the GitHub servers run the "Git Merge" command and finally merge feature/red-button against main.

Your code is finally in the main branch. Your ticket is resolved. Mission accomplished. 🎉