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...
For further actions, you may consider blocking this person and/or reporting abuse
This definately helps β€οΈ
I just delete the branches after merging. Any opinion on that ?
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
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:
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.
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
Wow that's quite a long process π
Will try to follow the steps π
See my comments above. No need to overthink git for your own projects imo π
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 !
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 π)
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.
That sounds great. Yeah the readme is important. But you're on the right path it seems π
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.
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 :)
I'm pretty sure that this will change my life.
Thanks π Let me know if it does
Great content hereππΏ. As a junior starting out this came at the right time. Thanks for this
Thanks a lot for your kind words. Very motivating for me. All the best for your journey
Loved it! Never thought about it from this prospective. Keep up the good workπ