Mac or PC? Android or iOS? Ember, Backbone, or Angular?
Developers aren’t shy about sharing their opinions within these technology debates. Since both sides of each argument have their own respective pros and cons, it really boils down to personal preference. As a result, these discussions never end, which is often confusing for newcomers to the space.
This happened to me when I started learning Git, a popular system for storing and tracking versions of software code. I’d be surprised when one tutorial would suggest an action as a best practice, while another claimed it would break my project. But just like with the Mac and PC debates, there isn’t one solution that’s necessarily better than the other. It’s simply a matter of choice.
Here are the three most enduring disputes among developers using Git.
Git Pull Vs. Git Fetch Then Merge
It’s so straightforward that it’s in all the beginner tutorials. Want to make sure your current version is up to date with the master branch? Simply type “git pull.”
But not so fast, say some developers. “Git pull” is a shortcut for “git fetch” followed by “git merge.” So in order to understand the way your project branches, they suggest using the latter sequence of commands. To them, simply using “git pull” is cutting corners because when things go wrong, you don’t have a way of knowing which branch is having an issue.
“[B]y both fetching and merging in one command, your working directory is updated without giving you a chance to examine the changes you’ve just brought into your repository,” developer Mark Longair explained.
On the other hand, “git pull” exists to make life easier. It keeps you from writing two commands when just one is needed. And if you’re the only developer working on a repository, there’s only one branch to worry about, so there’s no need to merge.
Pulling isn’t a problem when you’re working alone. But if you’re developing in a group, make sure everyone agrees on which commands to use.
Merge Vs. Rebase
If you’re a casual Git user, you may have never even needed to use rebase. After all, the much more mainstream command “git merge” does nearly the same thing.
Merge lets you join two or more development histories together. It’s simple and straightforward, which is why it’s taught to beginners first. The more complicated rebase command compares your local commits, or changes, with the latest point in development history, and applies only the missing commits to the top of the project.
Rebase is more specific than merge and will only update new things, instead of duplicating changes you’ve already made in previous rebase commands. Simply merging will duplicate changes each time you use it, and create a messy development history.
According to Marco Monteiro, an independent PHP developer, merging is the simpler command to understand. But it creates a far more complicated paper trail.
“If the need to merge arises simply because multiple people are working on the same branch in parallel, the merges don’t serve any useful historic purpose and create clutter,” Monteiro said.
Compared to merging, rebase, according to Atlassian developer Nicola Paolucci, creates a development history that is clean and easy to read. However, this presents its own problem, since when you rebase, you are “rewriting history” in order to create a more readable past.
“Going back through history to figure out when a bug or feature was introduced, and why it was done, is going to be tough in a situation like this,” Paolucci said.
A messy past with duplicates, or a clean past with erasure? There’s a reason the merge/rebase debate is still going strong. However, some developers have decided to take the best (and worst) of both worlds by applying both to a project, depending on which strategy works best for each commit.
Pull Request Vs. Code Review
Technically, this is a beef some developers have with GitHub about the way it lets you access and suggest edits to other peoples’ code.
By now, GitHub is the most established online hosting service for developers that use Git. Around this time last year, it had 3.5 million users. No other Git-based hosting service comes close.
But even as developers flock to the service, some miss how more obscure systems, like Gerrit, fostered developer interactions.
On GitHub, if you want to suggest edits to another user’s code, the only way to do it is with a “pull request,” a note that lets you tell others about a series of commits you’ve pushed to a GitHub repository, which they can approve or reject.
On Gerrit, “code reviews” are performed per commit. Each commit is its own pull request in a way, and developers can discuss the changes made in each individually. This allows the main developer to cherry pick which changes she wants to commit, instead of approving or denying a whole slew of them in a single pull request, like she would on GitHub. Not to mention it can really piss off GitHub contributors to have their pull requests denied due to one errant commit.
With pull requests, GitHub has streamlined and sped up the collaborative change-making process. Not every little commit needs to be nitpicked. But could it be too heavy handed?
“I think that one of the key of any development process, which is code review, is not well covered by Github pull-request system,” wrote developer Julien Danjou. “It is, along with history integrity, damaged by the goal of making contributions easier.”
Then again, if making contributions isn’t easy, it’s hard to say if people will bother contributing to your obscure open-source project. It’s a tradeoff depending on your priorities.