DEV Community: Diogo Leitão

To merge or to rebase: that is the question

Diogo Leitão — Tue, 16 Apr 2019 15:17:50 +0000

Photo by Pablo García Saldaña on Unsplash

It’s one of the eternal questions that ignite all dev discussions, on par with:

Tabs vs Spaces
Statically typed vs Dynamically typed
Han Solo vs Greedo
Jacob vs Edward

To make things simpler, I’m going to use an analogy. Let’s step away from code and programming for a while.

Integrating a paper research team

You recently integrated a group of people who are working on a big article or thesis. As you can imagine, you won’t do all the work and neither will the rest of your team. The work will be divided into fairly equal parts, so that each member of the team can focus on their branch of work.
A given member of your team is the lead researcher. This means that their decisions and comments carry more weight; in case of a draw, they are the ones who have the final say. Therefore, we can say that your lead researcher’s work is the source of your truth.
You have been assigned a new chapter on the research. You Google some existing papers on the subject (based on the main research document), find some images, plot some graphs, draw some conclusions, etc. A few days later, the lead researcher says some other colleague finished their part of the work and that piece has been merged into the main document (which, as I mentioned earlier, is your source of truth).

Photo by Jon Tyson on Unsplash

How should you continue your work from now on? How will you incorporate the newest additions into the research you’ve done so far? What if it clashes with what you currently have? Since the main document is your source of truth, you know it was approved by your peers and by the lead researcher, so you have to do you work starting from there!

Adding new information / Getting updates

How you think it will happen:

Zipper gif @ https://giphy.com/gifs/cgi-FS2GiqcNGT292

How it will most likely happen (with fewer deaths and injuries, hopefully):

Git Merge GIF @ https://tenor.com/view/git-merge-gif-5920259

Before the YOU’RE A REBASE PURIST accusations start pouring in, let me say that git merge has its advantages (of course it does!), the same way that git rebasehas its disadvantages. People who’ve been through it know that solving merge conflicts is easier and a lot less cumbersome when you use git merge.

However, what I want to focus is not which one is better, but rather which should be used in which situations.

Going back to the research paper analogy, once you get the updated version of the main document, rebasing your work on it will produce a more coherent work. If you were to merge everything together, you’d probably end up with clashing definitions and mixed up pages (if you started your work on page 20, and the latest document has 23 pages, your work does not belong on page 20 — the same way your commits will be spliced in-between the main branch’s commits).

Furthermore, when checking the log, we will see changes on both sides (main branch and our branch). If we place our changes on top of the most recent commit, there’ll be a straight line detailing in which order everything was done, and so we end up with a more coherent and clearer log history (and we don’t have to read through all the Merge branch develop into dl/feat-123/example commit messages as well).

Merging your research back into the main document

Now that you have your work sorted out and cleaned up, it’s time for the final review before merging it into the main document. By doing this, the moment your work was added to the main research will stand out, because everyone will know when what you did was introduced.

Back to code

I think that most of what I explained before was self-explanatory. Either way, here’s a quick recap, with code:

You’re added to a repo
Someone assigns you a feature (let’s assume the main branch is develop)
Someone updates develop, so you should rebase your branch
Once you’re finished, open a pull request, get your code reviewed, and merge it into develop

Summing everything up

If in the future you have any doubts about whether you should merge or rebase, remember the following:

Always rebase from parent branch: this way your work will always be on top of the most up-to-date version of the work (and you avoid having multiple merge commits, keeping you branch history cleaner and clearer)
Always merge into parent branch: when you merge your branch, you will know when that was done, since there will be a merge commit stating it!

Whether it’s frontend, backend, mobile or DevOps, at Runtime Revolution we have a spot for you!

Game DLCs look a lot like software releases, trust me

Diogo Leitão — Mon, 21 Jan 2019 10:19:06 +0000

Photo on Visualhunt

Did you ever stop to think that a game’s downloadable content (commonly known in the game industry as DLC) and the overall game development scene currently have a lot in common with software development? No? Well, let me tell you all about it!

Game development: an extremely abridged summary of its history

Game development used to be well thought out, designed from beginning to end, with intensive weeks of testing and fine tuning, bug fixing, and all the things you’d expect from a software company. Then, the game hits the stores, everyone buys it, it gets good reviews, happy customers, happy company.

In the last 5 years or so, the video game industry has seen a major change in its time-to-market. Fans and aficionados demanded that games be released as soon as possible since they are way too eager to try them out and beat all 500 levels in 20 different difficulty settings (your mileage may vary).

But that’s the customer side of things. What happened on the product/development side? If the customer demands it, we must deliver! Right? Well, that’s where things started to go wrong…

When some game studios decided to go down that road, it was well expected that some cracks would start showing. Let’s consider the following scenario:

The final deadline is in 3 weeks
You and your team have 30 tasks/features to do
You have estimated that this deadline is a bit tight for all the development (and testing!), but you can pull it off
Then, PR/Sales chimes in and says: “Guys, we really need to have this ready in 1 week, at most!”
chaos ensues

Some video games faced this exact type of situation, due to which they ended up getting bad reviews because of bad graphics (cinematic vs. in-game footage), plot holes, bad animations, buggy controls, etc. What the companies ended doing was releasing bug fixes and all the missing features as DLC, which contradicts what DLCs are: new game content!

Software development

Can you see how this relates back to your project? On the first meeting with the client everyone gets to know the project: scope, main features, obstacles that may arise when developing, the usual stuff. Based on this, you and your team outline a roadmap with sprints or a list of checkpoints, whatever flavour of project management you prefer. But one thing has to be set in stone: the deadline. The deadline should be a fixed date, far off in the future, and it is advised that the week before the deadline no major feature or redesign is implemented, since this has a huge cost on tracking down new bugs and testing the application end-to-end.

So, what can you do when the client wakes up one morning and says “This needs to be ready next week”, when it was supposed to be ready in three? Neither of the following answers are satisfactory (for you or the client), but here they are:

Cut down on project scope — let’s face it: it’s extremely hard to accomplish in 1 week what you had planned to do in 3. So, the easy thing to do is cut down on features. It’s better to have 15 fully working features than 30 somewhat-working-but-only-on-a-given-scenario features. The client may not like that the project doesn’t have all the sparkly stuff they wanted, but at least it won’t crash during the live demos.
Push the deadline forward — this is what may first come to mind when approaching the original deadline and acknowledging you can’t make it (if only I had more time…). This is hard to discuss, because now the client has to rethink their marketing strategy and PR stuff, as they have announced their project would go live sooner than expected. If they stick to this idea, then you’re gonna end up in a situation similar to one from the previous solution (30 buggy features vs. 15 working features).

If, however, you end up releasing the product as scheduled by the client without any changes regarding which features are included and feature completeness, then you’re probably going to be creating DLC-like updates, finishing up on your previous work and fixing bugs all the time.

Conclusion

None of the solutions presented above are ideal, nor should they be applied at all times as if they were a panacea. Feature status and deadlines should be something you discuss with the client regularly, to keep them informed on how far ahead/behind schedule you are, and to keep you informed of any schedule or feature changes on their side.

Whether it’s frontend, backend, mobile or DevOps, at Runtime Revolution we have a spot for you!