DEV Community

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

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...
Collapse
 
dawnind profile image
Mainak Das

This definately helps ❀️

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

Collapse
 
aliarslanansari profile image
Ali Arsalan Ansari

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

Collapse
 
jkettmann profile image
Johannes Kettmann • 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.

Collapse
 
jkettmann profile image
Johannes Kettmann

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

Collapse
 
dawnind profile image
Mainak Das

Wow that's quite a long process πŸ˜…

Will try to follow the steps πŸ˜‡

Thread Thread
 
jkettmann profile image
Johannes Kettmann

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

Thread Thread
 
dawnind profile image
Mainak Das

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 !

Collapse
 
jkettmann profile image
Johannes Kettmann

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 πŸ™‚)

Collapse
 
dawnind profile image
Mainak Das

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.

Thread Thread
 
jkettmann profile image
Johannes Kettmann

That sounds great. Yeah the readme is important. But you're on the right path it seems πŸ™‚

Collapse
 
develliot profile image
Develliot

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.

Collapse
 
jkettmann profile image
Johannes Kettmann • Edited

Thanks a lot for the nice words and sharing your insights. That's very valuable.

I wasn't sure how many people actually investigate the commit history. But seems like I'm not the only one :)

Collapse
 
blessinghirwa profile image
Blessing Hirwa

I'm pretty sure that this will change my life.

Collapse
 
jkettmann profile image
Johannes Kettmann

Thanks 😊 Let me know if it does

Collapse
 
mardiya profile image
Mardiya Zubairu • Edited

Great content hereπŸ‘πŸΏ. As a junior starting out this came at the right time. Thanks for this

Collapse
 
jkettmann profile image
Johannes Kettmann

Thanks a lot for your kind words. Very motivating for me. All the best for your journey

Collapse
 
vaasudhand profile image
Vaasu Dhand • Edited

Loved it! Never thought about it from this prospective. Keep up the good workπŸ‘