How to contribute to open source projects (our community project walkthrough)
Вставка
- Опубліковано 18 лип 2023
- 📘 T3 Stack Tutorial: 1017897100294.gumroad.com/l/j...
🤖 SaaS I'm Building: www.icongeneratorai.com/
✂️ Background Cutter: www.backgroundcutter.com/
💬 Discord: / discord
🔔 Newsletter: newsletter.webdevcody.com/
📁 GitHub: github.com/webdevcody
📺 Twitch: / webdevcody
🤖 Website: webdevcody.com
🐦 Twitter: / webdevcody
This is one of the very rare practical videos showing how to contribute to open source. Beginners may find it a bit difficult. But with practice, can apply that easily. Thanks Cody 👍
rightly said bruh
Can you make a video on how to build a project from the start? From initializing a repository, to setting up a GH CI/CD, to workflows, to accepting contributions from the community, including the structure and setup of the project, etc., I've found that almost no one makes these kinds of videos. Current best practice workflows in the open source world.
+1 Agree 💯
+1 I’m planning to start on a new side project and this would be very helpful!
Yes please
best video suggestion! this will help a lot of us understand how to create our own open source projects
+1
Just some information for you guys to understand how it works in the professional world (4 years of development exp. here) they call the method 'Gitflow' and it's known as a 'Best practice standard' across many commercial software development firms. What this does is this:
- After cloning the project, a developer will create another branch based off of their fork (origin) like Cody was talking about.
- They will add a feature or edit to that 'Feature branch' that they created off of another branch called the DEVELOPMENT branch. This branch is based off of the origin branch (Commonly referred to as Master).
- They will then merge that feature branch into another the 'Development' branch once their changes are made.
- THEN from the development branch, they will create a pull request (As Cody mentions) to push their changes to the master (origin) branch.
That master Branch must contain code that can be ready to go into production environments at any moment. And so release engineers will only use code from that branch and not the other feature or development branches. It's also known as best practice to make sure your development & master branches are not out of sync so you dont have to scroll through different changes that were made into each branch trying to understand where everything came from.
im assuming before you make these pull requests the code should be tested and all of that before it goes into the master branch?
I am kind of like a beginner at coding(I am in my second year of college and know some C and java), will this be hard for me to start contributing or will I be able to right away
I have one doubt. I imagine since a team will be having multiple devs working simultaneously there will be multiple development branches from each dev working on different things, so my question is this: Say you have dev branch 1, 2 and 3. Dev 1 branch got the pass mark and ready to be pushed into the Master, after Dev 1 branch is pulled into the Master, does this Master update reflect into Dev 2 and Dev 3 branches ? Or that has to be done manually so each developer gets communicated to update their branch with the new Master code? How does that realistically work in a development cycle? Is it as easy as Github takes care of it automatically or do you have to plan accordingly for each development cycle to have an entire update stage for the whole team?
Hey Cody,
Thanks for the quality content. One of the bests TBH on YT that you can straightly forward understand the process.
Wow this is by far the easiest to understand and follow guide I have seen on how to contribute to Open Source Projects. God bless u fam
🔥 yet another 10/10 upload. Im excited you're talking about open source. it can be very intimidating, but the more people contributing to oss the better
This is so helpful to people who dont have familiarity with contributing to open source(I'm one of them). Thank you on behalf of all of us
Thank you for this video, very practical for beginners who want to contribute to an open source project
I'm glad someone made this kind of video. always shyed away from cs due to not knowing stuff like this.
Thank you for making this video it was very helpful, especially for me as a new developer
Thanks for wonderful content Cody
Great Video! This should get more views. Thank you Cody!
was confused, you made it easier thank you.
Glad to find this video !!! ❤
thank you, i didn't know about the upstream branch!
Thanks for the video man❤ which theme are you using in this video?
Thanks for this video very useful.
i have a question how do you create a selection area while recording?
awesome video! thanks!
Good job love ❤
spot on the people needed this one
Great video again!
Found this after contributing to open source project for the first time about an hour ago. Will find out if I made it correctly.
Really Helpful, Thank You
rebasing, squashing and avoiding merge commits are a very important part of this process.
we don't use rebase or squashing at work, so it's not that important imo
@@WebDevCody I agree it varies between projects, just never enjoyed merge commits and prefer a cleaner commit history without them while still being able to credit the author.
Wow
This is amazing
right to the point, thanks
If you want to get comfortable with contributing to open source projects, i suggest you participate in Hacktoberfest ( every October )
Thanks for this
I have an error “need to specify how to reconcile divergent branches “ when I want to pull all changes
nice initiative
Hey thanks for the video! If you do git fetch upstream and that updates your fork with the original “source” why do you need to do git pull upstream/main afterwards?
Well I think if you’ve already checkout the branch locally then you’d need to either rebase your local branch to it matches your origin, or back merge the origin branch changes into your local branch.
How do you find projects to contribute to that aren't MASSIVE complicated projects?
Very helpfull. Thanks
Bro, can make a tutorial on migrating express server to next js or at the very least use express with next
legend
what if the branched feature you are working on is taking days or weeks and people are constantly getting their PRs merged? Do i do a fetch upstream then pull for my branches and it would work as well?
yes you should be pulling in the upstream main into your branch daily, or even multiple times a day if possible. If you don't, you'll end up with just a bunch of merge conflicts you'll have to fix at the end.
it was informative and quite easy to follow, but I have few more questions like how do you find the projects that you can contribute on? who ask for changes ? like do you just go through it think yeah this should have this feature and start working on it? maybe somebody else is already working on it things like that. Thanks in advance
I have no clue, most projects i've tried contributing on just let my PRs rot
A little fast for me, but I learned something 👍
Cody do you think open source is good to do if your trying to get a job. Not sure how to add it if I have a lot of time already on projects, and interview prep. Thanks!
I don't find it useful. If you can get a chance to work with another developer daily so you can say you've had practice collaborating, that would be better.
@WebDevCody that's what I thought to, plus projects are way more fun and I learn just as much, thanks a lot
BRUH WHAT AM I SPOSED TO DOOOOOOOOO
🤔If the upstream changes, how do I sync my branch for future merge? Or should I?
you can either do a rebase or merge the upstream into your branch
10:00
How did you did that??
Which app do you use for the terminal??
visual studio i guess
6:09
I think it should be
git push origin update-docs
Still don't understand why you would fork rather than just create another brach in the main repository, any particular benefits?
From what I've understood in my limited time in SWE is that forking is more like you want to make changes that don't affect the original, but for feature development a branch is fine.
because when you contribute to repositories you do not own, you can't just make a branch due to security settings of the main repo, which means you won't be able to push your branch unless someone gives you contributor access. For example, you can't just go an start making branches on the React github repo, you'd need to fork it.
@@WebDevCody Ah makes sense, I've been mostly working with internal projects and haven't yet done anything surrounding open source. Thanks for the answer
Is it git push origin update-docs or git push origin main?
i think is the first option, since you're on the update-docs branch
Why cannot I start a branch from the main branch directly?
You can, that works as well, but having a separate branch for each feature makes it easier to have multiple pull requests open at the same time that you may need to switch between as reviews come in for those features
@@WebDevCody I have to review your talk. I did not catch the moment qhen the PR goes to the main branch.
Not on the fork but to the main
Thank you for your content. You are awesome
@@vittoriomorellini1939 it’s when I merge it from my phone and it turns purple
+1
trigger for interest