DEV Community

Impress hiring managers by presenting your React projects like a pro - Part 2

Johannes Kettmann on July 10, 2021

In part 1 of this series we saw how you can build impressive portfolio projects by working like a professional developer in a real team. The idea...

Read full post

Mainak Das • Jul 10 '21

This definately helps ❤️

I just delete the branches after merging. Any opinion on that ?

Ali Arsalan Ansari • Jul 10 '21

You should have 3 branches
master/main
qa
development

And seperate branch for each feature which gets deleted after merging.
First make a pr on development, if it's working properly and create a pr from development to QA, then after testing from create PR from QA to master/main

Johannes Kettmann • Jul 11 '21 • Edited

Honestly, I don't think that's necessary. Yeah, some teams work like that. My current team also uses a development and master branch. But it highly depends on the deployment process. And tbh it's quite annoying if you use mandatory code reviews and want to deploy often.

If you use continuous deployment in combination with preview branches you use a super modern and professional workflow. It works like this:

You have one branch called main (or master or whatever)
You create new branches from main to implement your features
You create a PR to merge the branch into main
The PR gets deployed to a temporary domain where you can test the code in production conditions
If everything is alright you merge the branch
the main branch is then automatically deployed to production (this is called continuous deployment)

In a real team your coworkers would ideally review your code to improve quality.

Deploying the branch is usually a bit tricky if you set up deployment yourself. But in your own projects you can simply use Vercel or Netlify. They are free, easy to set up and give you advanced features like branch previews out of the box.

Johannes Kettmann • Jul 11 '21

Btw if you where hinting at the good old "git flow" there's no need for it for a typical web app. The author himself recommend against using git flow for web apps as you can read on the original article

Mainak Das • Jul 11 '21

Wow that's quite a long process 😅

Will try to follow the steps 😇

Johannes Kettmann • Jul 11 '21

See my comments above. No need to overthink git for your own projects imo 😊

Mainak Das • Jul 11 '21

You're right, creating 2-3 branches for prod, prev and dev in personal projects is kinda stretch !
As I use vercel the branch preview does the job !

Johannes Kettmann • Jul 10 '21

Generally that's totally fine. In a production app you'd typically delete your branches. At least from time to time since you end up with a big mess otherwise.

For a portfolio project there mighty be an advantage of leaving them if the reviewer wants to check them out. It's unlikely that they will though. And if you use pull requests you might see the changes there even if you delete the branch (not at all sure about this though 🙂)

Mainak Das • Jul 10 '21

Thanks, I'll keep this in mind. I use PR when I introduce massive changes or I'm not sure about a feature will work or not. Also, I create issues that I label and assign myself. Just have to improve my README.md file as I never edit those 😅 and also the about section.

Johannes Kettmann • Jul 10 '21

That sounds great. Yeah the readme is important. But you're on the right path it seems 🙂

Develliot • Jul 12 '21

I have been reviewing a lot of coding exercises and interviewing for a lot of developers this year, I can confirm this advice is bang on.

It's not just what you have done but also showing the thought process behind it and what you would like to do with more time.

I like to see the full commit history you can learn a lot about a developer by seeing what changes commit by commit, also if their commit messages are clear and logical.

Don't forget all the small things like moving as many imports as possible into dev imports to keep main bundle size down and don't forget to remove junk like console logs.