Pull requests Done Right

Pull requests

In their simplest form, pull requests are a mechanism for a developer to notify team members that they have completed a feature. Once their feature branch is ready, the developer files a pull request. This lets everybody involved know that they need to review the code and merge it into the main branch. Read more

Merge Conflicts

Merge conflicts happen when you merge branches that have competing commits, and Git needs your help to decide which changes to incorporate in the final merge.

That said, not all pull request get merged since there are alot of factors that come to play. The very first thing that github points out when creating a PR is the merge status. Whether the commit history is linear and things like that and in the event where the pull request notices a conflict that needs to be addressed it prescribes various remedies.

Further reading

• About pull requests
• About pull request merges
• Resolving a merge conflict using the command line
• Resolving a merge conflict on GitHub

Avoiding Merge Conflicts

The Elephant 🐘 in the room now becomes how to avoid running into merge conflicts and saving development time and having spare time for coffee breaks.

How to Prevent Merge Conflicts (or at least have less of them)

Merge conflicts are mostly inevitable. You will experience more than one merge conflict in your career, but with good communication and planning, you can reduce the number of merge conflicts you encounter. Let's discuss how we can do that!

Understand why merge conflicts happen.

Version control systems, like git, auto-magically manage code contributions. It identifies the change, when it occurred, who made it, and on what line so that developers can easily track the history of their codebase. However, git sometimes gets confused in the following situations:

When more than one person changes the same line in a file and tries to merge the change to the same branch When a developer deletes a file, but another developer edits it, and they both try to merge their changes to the same branch. When a developer deletes a line, but another developer edits it, and they both try to merge their changes to the same branch When a developer is cherry-picking a commit, which is the act of picking a commit from a branch and applying it to another

When a developer is rebasing a branch, which is the process of moving a sequence of commits to a base commit Git is unsure which change to apply, so it leans on the developer for help and notifies them of a merge conflict. Your job is to help git determine which proposed change is most accurate and up to date.

The benefits of preventing merge conflicts.

Sometimes, doing that upfront work for your team or yourself to avoid merge conflicts may seem tedious, but it's worthwhile. Using guard rails to prevent merge conflicts will save time and increase developer happiness. Solving a bug, writing a new feature, or scripting automation is time-consuming. Adding the barrier of debugging and resolving a merge conflict means it takes longer to merge to 'main' and longer to deploy to production. Also, if your team is constantly experiencing conflicts, they'll eventually feel disenchanted with their work.

Four ways to prevent merge conflicts

1. Standardize formatting rules

Many times conflicts occur because of formatting discrepancies.

2. Make small commits and frequently review pull requests

Creating large pull requests discourages teammates from thoroughly and quickly reviewing your code. Pull requests would sit longer than necessary because it teammates preferred to avoid.

3. Rebase, rebase, rebase (The earlier the better)

What is rebasing? The git rebase command reapplies changes from one branch into another, which is very similar to the git merge command. However, in this case, git rebase rewrites the commit history to produce a straight, linear succession of commits.

How rebasing helps prevent merge conflicts Rebasing is not going to magically remove all merge conflicts. In fact, you may encounter conflicts while rebasing. Sometimes, you will have to repeatedly resolve the same conflict while rebasing. However, merge conflicts happen because multiple changes happen to the same chunk of code simultaneously.

In many situations, rebasing first and then merging can make teamwork easier. Rebasing is an option, but not the only solution.

Be careful with rebasing Be warned – there are moments when rebasing is not recommended. Rebasing is dangerous because you're rewriting history. When rebasing, pay attention to the changes you're accepting because you risk overwriting teammates' changes or including files your teammates intended to delete. You also probably wouldn't want to rebase a public repository on the main branch because that would inaccurately rewrite the history.

If you're new to rebasing or nervous about rebasing, pair with a teammate.

4. Pay attention and communicate

No git command or software tool can replace the need for communication in engineering teams. Being a good software developer and collaborator goes beyond writing code. Good software developers communicate with teammates. Keep your team aware of what files you will be touching and coordinate with your Product Manager and SCRUM Master to avoid working on features that conflict with other features.

If you're working alone, pretend you're working on a team by:

creating branches

creating pull requests

Avoid allowing pull requests to become stale

Make sure you're not changing the same lines of code before merging a prior change

Establish and follow formatting rules

Working alone shouldn't stop you from practicing healthy coding habits, so try to keep your codebase clean! Your codebase may turn into an open source project or a project that you show off in interviews.