This content originally appeared on DEV Community and was authored by Ayu Adiati
Hello Fellow CodeNewbies 👋,
The first week of Hacktoberfest 2021 has passed.
This month, I'm participating in Virtual Coffee's October monthly challenge. I also start collaborating with The Collab Lab.
These events give me lots of opportunities to learn git by doing.
Along this journey, I made so many mistakes and got countless panic attacks 😆.
But I also asked many questions and got a lot of help.
In this article, I'm sharing with you the top 8 questions that I had around git.
I hope they could help you as well if you have the same or similar questions as mine.
🛠 Tools
These are the tools that I'm using for working with git. If you have different tools, there could be different commands or steps 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 in an open-source, we do want to fork the original repo. This forked repo would be the repo where 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/abandoned by its maintainers.
Let's say we want to learn about something. Then we found a repo where we want to learn from. But then we realize that this repo is not updated 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 toforkthe 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 directly to their repo.
That's another reason why we want toforkthe original repo.
After forking, we want toclonethis repo instead of the original one.
2. What do origin and upstream mean?
The naming in git is pretty much confusing (at least for me 😅).
What is the difference between origin and upstream? Why there are commands such as git fetch origin or git fetch upstream? From where are we fetching?
There are some opinions telling it's a matter of conventional naming. But they are pretty much the same.
Both are remote repos, but they are not the same.
-
originIt's our forked repo. This is the remote repo that we have from forking the original open-source repo.
-
upstreamIt refers to the original open-source repo.
3. Why do we want to make sure 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. Without updating, the remote main branch could also lose some merged changes.
Before we push our changes, make sure our main and feature branches have the same updates with the upstream.
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
upstream.
Click this button and we will get a dropdown menu.
When theFetch and mergebutton is in inactive mode, it means that there is no update on theupstream. If it's green, click it.Up until here, our
originrepo is having the same updates as theupstream. -
Go to our terminal.
- Go to our local
mainbranch with thegit checkout maincommand. - Then run
git merge origin/main.
Our
mainbranch is now having the same updates as theoriginandupstream.- Go to our branch with
git checkout <branch-name>. - Run
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 use to code solo. I have a bad habit of not adding and committing my changes before I completely finish working.
This habit can definitely be very bad when we work 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 that we work on are carrying onto the branch that we go to.
And we don't want that.
That's being said, the best time to add and commit our changes is as soon as we finish making some changes to our code. Doesn't matter how small it is.
This way, we can safely go to another branch when it's 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 it 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 get some conflicts because someone else also worked in a same file.
It gave me several options that I have 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.
In case we need to merge it soon and we are not sure 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.
When it can't find that branch, it will look for the branch on the origin repo. 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 if there are any changes that we haven't added and/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 remote with our changes. The bottom line, we are deleting all history on the remote repo and replace them with ours.
When we work in a team, this can give trouble to 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 small changes.
- Do
git stashwhen we only want to save our changes and want to continue working on it later. - Make a habit of running
git status. - 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! 😊
This content originally appeared on DEV Community and was authored by Ayu Adiati
Ayu Adiati | Sciencx (2021-10-13T10:43:23+00:00) First Week of The Hacktoberfest: 8 Top Questions Around Git. Retrieved from https://www.scien.cx/2021/10/13/first-week-of-the-hacktoberfest-8-top-questions-around-git/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.