We created numbers like
1.0.1 for releases and hotfixes when we worked on Git Flow. What do these numbers represent, and why do we use them?
These numbers represent the version number of the product we put out in the world. We use them because we’re following a best practice called Semantic Versioning.
When we use Semantic Versioning, developers will know whether a change will break their code. The numbers give a clue to the kind of changes that have occurred.
Many popular projects use Semantic Versioning. Examples are React and Vue.
I don’t have time to learn.
Many people say that to themselves. I say that to myself too.
And I was almost burned out. I was unhappy and depressed.
Learning is important to me. When I don’t learn, I start to feel guilty.
One day, I decided enough was enough. I had to change up my schedule to allow time for learning. I did some experiments over the new few weeks and found a way where I could give myself 1.5 hours to learn every day. The best part is, I created even more content than I did before!
I want to share with you my experiment and how I tweaked my schedule to allow time for learning. I hope it’ll help you find some time to learn as well.
How do you manage your git branches if you have many of them? For this, we have a well-known method called the Git flow.
It contains five types of branches:
- The production branch
- The develop branch
- Feature branches
- Release branches
- Hotfix branches
We’ll go into what each type of branches do and how to create them in this lesson.
The best answer I could come up with was: “I don’t know”.
I hated myself for saying that.
I came to a point where I’m scared to promise a deadline. I don’t want to disappoint my students. I don’t want to disappoint myself either.
But I realize that I can’t say “I don’t know” to students who already bought the course. They have a right to know. So today, I’m going to overcome my fear and provide you with a proper estimate.
Note: This the seventh video in the Git for beginners series. Watch the first video here.
Imagine there are parallel worlds. We have:
- A world where I have created this video, and you’re watching it.
- A world where I have created this video, but you’re not watching it.
- A world where I did not create this video.
In this parallel world concept, a Git branch is a parallel world.
You can have a branch that stays the same in one world. Then, you branch off into a different world. Once you finish your code, you can complete the initial world by merging the changes into it.
I want to let you know that I’m changing to a new refund policy. I want to tell you about the new policy, and why I’m changing it.
Note: This the sixth video in the Git for beginners series. Watch the first video here.
Let’s say a friend of made a change to your repository and pushed the changes to the Git remote. At the same time, you also made a change to the same line of code.
When you pull their changes into your local repository, you’ll notice that there is a conflict.
This happens because Git no idea whether their version is the updated version or your version is the updated version.
This is what we call a Git conflict.
You’ll learn how to resolve a Git conflict today.
I made a terrible mistake when I tweeted about
:blank a month ago. I said that
:empty wasn’t useful, and
:blank is much more useful than
I was wrong!
:empty is actually good enough. We don’t even need
Note: This the fifth video in the Git for beginners series. Watch the first video here.
Let’s say you want to work on a project together with a friend. The two of you will be creating commits on the same project.
Let’s also say your friend has created the project. They initialized a repository on Github.
What you need to do next is to copy the project from the remote to your computer.
In Git, you can do this through a Git Clone.
And as professional frontend developers, we need to understand what our jobs are.