Table of contents
Hello Fellow CodeNewbies 👋,
The first week of Hacktoberfest 2021 has passed.
This month, I'm participating in Virtual Coffee's October monthly challenge, and the collaboration program at The Collab Lab is also starting.
These events give me lots of opportunities to learn Git by doing.
I made so many mistakes along this journey and got countless panic attacks 😆.
But I also asked many questions and got a lot of help.
I'm sharing my top 8 questions about Git in this article and the answers.
I hope they can help you if you have the same or similar questions as mine.
These are the tools that I'm using for working with Git. If you have different tools, there could be other commands or steps for you to do.
- Windows 10
- Integrated bash terminal on VSCode
- GitHub website on the browser
❓ The Questions
1. Why do we want to
fork a repo?
Before we start working on an open-source, we want to
fork the original repo. This forked repo would be the repo we will make and push our changes to.
But why do we want to
fork the original repo?
The open-source is no longer active or abandoned by its maintainers.
Let's say we want to learn about something. Then we found a repo that we want to learn from. But then we realize that this repo has had no update for ages.
There would be a big possibility that this repo is no longer maintained or deprecated. But we still want to try it out.
One way to do that is to
forkthe repo and work with this forked repo.
No authorization from maintainers.
Most open sources don't give us the authorization to make changes and push them directly to their repo.
That's another reason we want to
forkthe original repo.
After forking, we want to
clonethis repo instead of the original one.
2. What do
The naming in Git is pretty confusing (at least for me 😅).
What is the difference between
upstream? Why are there commands such as
git fetch origin or
git fetch upstream? From where are we fetching?
Some opinions are saying it's a matter of conventional naming. But they are pretty much the same.
Both are remote repos but they are not the same.
It's our forked repo, the remote repo that we have from forking the original open-source repo.
It refers to the original open-source repo.
3. Why do we want to ensure to update our main and feature branches before we push our changes?
Because we want to avoid our
pull request causing conflicts on the remote
main branch, the remote
main branch could also lose some merged changes without updating.
Before pushing our changes, ensure our
feature branches have the same updates as the
How to do this?
Go to our forked repo on GitHub.
We will see a
Fetch upstreambutton on the right side.
GitHub makes it easy for us to fetch the updates from the
Click this button, and we will get a dropdown menu.
Fetch and mergebutton is in inactive mode, there is no update on the
upstream. If it's green, click it.
Until here, our
originrepo has the same updates as the
Go to our terminal.
- Go to our local
mainbranch with the
git checkout maincommand.
mainbranch now has the same updates as the
- Go to our branch with
git checkout <branch-name>.
git merge main.
- Go to our local
Now we can push our changes and create a pull request.
4. When do we want to commit our changes?
I'm self-taught and used to working alone. I have a terrible habit of not adding and committing my changes before I finish working.
We don't want to keep this habit when working in a team.
There are times when we want to go to other branches.
When we don't add and commit our changes, whatever changes we work on are carried onto the branch we go to.
And we don't want that.
The best time to add and commit our changes is as soon as we finish making some changes to our code, no matter how small it is.
This way, we can safely go to another branch when necessary. Besides, we can have a good history of what we're doing step by step.
Sometimes we want to save our changes but don't have an intention to commit them yet. In this case, we can run
5. I'm merging a branch. Now I get conflict. How can I resolve this?
I was merging a branch. Then I got some conflicts because someone else worked on the same file.
It gave me several options that I had to choose from on VSCode.
- Accept current change
To accept the changes that are already there at the beginning (HEAD).
- Accept incoming changes
To accept the new changes.
- Accept both changes
To accept both current and incoming changes.
- Compare changes
To compare current and incoming changes.
Which one we need to choose depends on our discussion with our teammates.
If we need to merge it soon and are unsure which one to choose, we can choose to
Accept both changes to be safe.
6. How to delete a local branch and pull the same branch from the remote repo?
One day when I worked on changes in a branch, it got so messed up. I wanted to delete this local branch and pull the branch from the remote repo to have a fresh branch.
We can do so by running these commands:
git branch -D <feature-branch-name>to delete our local branch.
git checkout <future-branch-name>to pull the branch on the remote repo.
We don't need to create a new branch as in
git checkout -b <future-branch-name> when we want to pull an existing branch.
git checkout <future-branch-name>, Git will check if we have that branch in our local repo.
It will look for the branch on the
origin repo when it can't find that branch. And if it's founded, Git will pull that branch to our local repo.
We want to make sure that we enter the exact branch's name as in the
7. Why do we want to make a habit of running
- We can make sure in which branch we're currently in.
- We can be aware of any changes that we haven't added or committed.
- We can see warnings if our branch is ahead or behind the remote branch, etc.
8. Why do we want to avoid anything with
--force such as
git push --force?
As straightforward as the name,
force means forcing any changes to a branch. It will ignore every warning.
Once we do
git push --force, it will force push our changes and replace everything on the remote with our changes. The bottom line, we are deleting all history on the remote repo and replacing them with ours.
When we work in a team, this can cause trouble for the whole team.
There are some rare circumstances where we need to do this.
But beforehand, we have to make our team members aware that we will do it and go for it when everyone agrees.
My key takeaways after these experiences:
- Always fork the original open-source repo before we start to work on it, and clone this forked repo.
- Do add and commit our changes even though we only do minor changes.
git stashwhen we only want to save our changes and want to continue working on them later.
- Make a habit of running
- Avoid running any command with
--forceas much as possible.
Thank you for reading!
Last but not least, you can find me on Twitter. Let's connect! 😊