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
- VSCode
- 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 fork the 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 fork the original repo.
After forking, we want to clone this repo instead of the original one.
2. What do origin and upstream mean?
The naming in Git is pretty confusing (at least for me 😅).
What is the difference between origin and 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.
origin
It's our forked repo, the remote repo that we have from forking the original open-source repo.upstream
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 main and feature branches have the same updates as the upstream.
How to do this?
Go to our forked repo on GitHub.
We will see a Fetch upstream button on the right side.
GitHub makes it easy for us to fetch the updates from the upstream.
Click this button, and we will get a dropdown menu.
When the Fetch and merge button is in inactive mode, there is no update on the upstream. If it's green, click it.
Until here, our origin repo has the same updates as the upstream.
Go to our terminal.
- Go to our local
main branch with the git checkout main command.
- Run
git pull.
Our main branch now has the same updates as the origin and upstream.
- Go to our branch with
git checkout <branch-name>.
- Run
git merge main.
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 git stash.
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.
Then,
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.
With 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 origin repo.
7. Why do we want to make a habit of running git status?
- 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.
Final Words
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.
- Do
git stash when we only want to save our changes and want to continue working on them later.
- Make a habit of running
git status.
- Avoid running any command with
--force as much as possible.
Thank you for reading!
Last but not least, you can find me on Twitter. Let's connect! 😊
