hpr-knowledge-base/hpr_transcripts/hpr2664.txt

Episode: 2664
Title: HPR2664: My git workflow
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2664/hpr2664.mp3
Transcribed: 2025-10-19 07:10:09

---

This is HBR Episode 2664 entitled, My Git Workflow, and is part of the series Introduction to Git.
It is hosted by first-time host Yannick, and is about 8 minutes long, and carries a clean flag.
The summary is, in this episode I talk about the workflow I use to contribute to open source project using Git.
Today's show is licensed under a CC Zero License.
This episode of HBR is brought to you by an honesthost.com.
Get 15% discount on all shared hosting with the offer code HBR15. That's HBR15.
Better web hosting that's honest and fair at An Honesthost.com.
Hello, my name is Yannick, I'm also known in some parts of the internet as the French guy from Switzerland.
This is my first contribution to HBR.
Today I'm going to talk about my Git workflow, because I'm recording this on the 2nd of October, and it's the beginning of Hacktoberfest.
So I'm deep into creating pull requests and using Git, so I thought maybe it's the right time for my first contribution.
So how do I create this pull request and contribute to open source project using Git?
I'm going to use GitHub as an example, but I'm sure it will work the same on GitLab, for example, or a bit bucket or even self-hosted platforms.
So the first thing I will do is fork the project I want to work on.
So I will have a repository that is even with the original project.
I'm going to give names to those repositories.
I will call upstream the project to which I want to contribute.
And origin will be my fork of this project, so that will be my repository on GitHub.
Then I will clone my own repository on my local machine using the command git clone, and with then the URL of my repository and GitHub.
So that will give me my local repository.
And then I will reference the upstream project on my local repository using the command git remote add upstream, and then the URL of the original project.
So now on my machine, I have a local copy of the project which references my own fork on GitHub with the name origin and the original project with the name upstream.
Now on my workflow, I never ever work on the master branch on my local repository.
That way I can always come back to that if I want to have a reference, see what was there originally or start working on something else.
So I never work on the master branch.
So what I do is I create a specific branch for a feature or bug fix, for example.
So let's say we're going to fix a bug to the original project.
So I will create a branch using the command git checkout hyphen B and then the name of the branch.
So let's say it's called bug fix.
Then I can now start working on this project.
I can start modifying files, adding files, removing other files, etc.
And at some point I want to stage my modifications.
So I will use the command git add.
Usually I add everything that I've modified.
So I use git add dot.
So it takes everything and stage that or sometimes when I just want to stage some parts of my changes.
I can use git add and then the name of the file or the directory I want to stage.
But yeah, usually I use git add dot and add everything.
And then at some point I want to save that.
I want to commit all my changes.
So I will use the command git commit.
I will then add the commit message.
At this point I can make more changes.
So I will again use git add and then git commit to save those changes.
And when I'm happy with my changes when I've tested everything and I'm ready to contribute.
This fix to the original project.
I will push my local branch to branch on my own GitHub repository.
So I will use the command git push hyphen you origin bug fix.
So that origin is my repository on GitHub and bug fixes the name of the branch.
I want to push to which is also the name of the local my local branch.
This will create the branch on GitHub on my repository.
And since I have forked the original repository, the original project,
GitHub knows that my project and the other one are linked and gives me the opportunity
to create the pull request directly from my own repository with a click of a button.
So now all I have to do is fill the pull request command, submit that pull request
and wait for upstream to merge the pull request into their master branch.
And then when that is done, I need to sync everything back.
So I can continue working and I'm not lagging behind the original project.
So back on my original repository, I do a git checkout master.
So I am back on my master branch, which I didn't change.
So it's in the same state as it was when I forked the original project.
I then git fetch upstream to get all the changes on every branch from the original project.
Now, since I am on my master branch, I can merge all the changes from the original project.
So I use git merge upstream slash master.
Now my local repository, my master branch on my local repository is ahead of my master branch on GitHub.
So I need to push those changes and I use the command git push.
That will send the my master branch, my local master branch to GitHub on my repository.
I don't need the backfix branch that I created earlier to work on.
So I can delete that using git branch hyphen d backfix.
And I also want to delete this branch on GitHub because I don't need it anymore over there either.
So I do git push origin hyphen d backfix.
And now I have on my local machine a clone or a copy of my GitHub repository.
And they are both even at the same commit.
And it's also even with the upstream repository.
So I can now start again if I want to create some other backfix or some feature.
So to summarize, I do git checkout hyphen b my awesome feature.
git add dot git commit git push hyphen you origin my awesome feature.
I didn't create the pull request and wait for the pull request to be merged.
Then I come back to my local repository and I do git checkout master git fetch upstream git merge upstream slash master.
git branch git push git branch hyphen d my awesome feature git push origin hyphen d my awesome feature.
And that's my git workflow for for contributing to open source project.
I don't know if it's something that everybody does or if it's only me, but it's working for me.
So I just wanted to share it with the HPR community.
It's as I said, it's my first contribution and I thought it was a subject that could be interesting.
So any comments are welcome.
You can send a comment on the HPR website or send me an email.
You can join me at yannickatfrenchguy.ch.
Thanks for listening.
Bye bye.
You've been listening to HECCA Public Radio at HECCA Public Radio dot org.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing to find out how easy it really is.
HECCA Public Radio was founded by the digital dog pound and the Infonomicon Computer Club
and is part of the binary revolution at binrev.com.
If you have comments on today's show, please email the host directly.
Leave a comment on the website or record a follow-up episode yourself.
Unless otherwise status, today's show is released on the Creative Commons,
Attribution, ShareLite, free dot org license.