Outreachy : My journey so far with Mozilla
Are you a beginner? Want to start Open Source Contribution? If your answer is -Yes, then you have come to the right post.
Outreachy is an inspirational platform for engaging women in the open source world and all the organizations participating in it, it boost one’s confidence.
The combination of code, collaboration in teams and communication with the array of developers made me very excited to participate in Outreachy.
This is a kind of Google summer of code internship program, but the difference is, this program is only open to women (cis and trans), trans men, and gender-queer people internationally. For more information, you can visit here.
Recently I started contributing to the Mozilla’s fxa-content server while I was applying for Outreachy(round 13).
In my initial contribution, I started working on the good first bugs and learned the aspects and versions of contribution where tools like git was involved heavily along with looking closely at all the test cases to be passed. I got to be in contact with the developers of the products who are the mentors as well as other contributors and regularly discuss on the issues and flow of the product .
Git : A Monster-like looking Angel
To keep things practical, I’m basing this list off of the actual Git commands I used over the past week.
Almost every developer uses Git, and most likely GitHub. But the average developer probably only uses these three commands 99% of the time:
git add --all
git commit -m "<message>"
git push origin master
That’s all well and good when you’re working on a one-person team, a hackathon, or a throw-away app, but when stability and maintenance start to become a priority, cleaning up commits, sticking to a branching strategy, and writing coherent commit messages becomes important (like, was used by Mozilla).
Regularly used commands
To initialize Git in a repository (repo), you just need to type the following command. If you don’t initialize Git, you cannot run any other Git commands within that repo.
If you’re using GitHub and you’re pushing code to a GitHub repo that’s stored online, you’re using a remote repo. The default name (also known as an alias) for that remote repo is origin. If you’ve copied a project from Github, it already has an origin. You can view that origin with the command git remote -v, which will list the URL of the remote repo.
If you initialized your own Git repo and want to associate it with a GitHub repo, you’ll have to create one on GitHub, copy the URL provided, and use the command git remote add origin <URL>, with the URL provided by GitHub replacing “<URL>”. From there, you can add, commit, and push to your remote repo.
The last one is used when you need to change the remote repository. Let’s say you copied a repo from someone else and want to change the remote repository from the original owner’s to your own GitHub account. Follow the same process as git remote add origin, except use set-url instead to change the remote repo.
git remote -v
git remote add origin <url>
git remote set-url origin <url>
The most common way to copy a repo is to use git clone, followed by the URL of the repo.
Keep in mind that the remote repository will be linked to the account from which you cloned the repo. So if you cloned a repo that belongs to someone else, you will not be able to push to GitHub until you change the origin using the commands above.
git clone <url>
The command git branch lists all branches on your local machine. If you want to create a new branch, you can use git branch <name>, with <name> representing the name of the branch, such as “master”.
The git checkout <name> command switches to an existing branch. You can also use the git checkout -b <name> command to create a new branch and immediately switch to it. Most people use this instead of separate branch and checkout commands.
git branch <name>
git checkout <name>
git checkout -b <name>
If you’ve made a bunch of changes to a branch, let’s call it “develop”, and you want to merge that branch back into your master branch, you use the git merge <branch> command. You’ll want to checkout the master branch, then run git merge develop to merge develop into the master branch.
git merge <branch>
If you’re working with multiple people, you’ll find yourself in a position where a repo was updated on GitHub, but you don’t have the changes locally. If that’s the case, you can use git pull origin <branch> to pull the most recent changes from that remote branch.
git pull origin <branch>
If you’re curious to see what files have been changed and what’s being tracked, you can use git status. If you want to see how much each file has been changed, you can use git diff to see the number of lines changed in each file.
git diff --stat
The git log command lets you see the commit history. You’ll want to use this to see the history of your commits.
Your commits will come with messages and a hash, which is random series of numbers and letters. An example hash might look like this:
Let’s say you pushed something that broke your app. Rather than fix it and push something new, you’d rather just go back one commit and try again.
If you want to go back in time and checkout your app from a previous commit, you can do this directly by using the hash as the branch name. This will detach your app from the current version (because you’re editing a historical record, rather than the current version).
git checkout c3d45ebf1f34e3w2f
Then, if you make changes from that historical branch and you want to push again, you’d have to do a force push.
Caution: Force pushing is dangerous and should only be done if you absolutely must. It will overwrite the history of your app and you will lose whatever came after.(Force pushing is also done in case of rebasing)
git push -f origin master
Let’s say you have 4 commits in your local history (not pushed to GitHub) in which you’ve gone back and forth. Your commits look sloppy and indecisive. You can use rebase to combine all of those commits into a single, concise commit.
git rebase -i HEAD~4
The above command will open up your computer’s default editor (which is Vim unless you’ve set it to something else), with several options for how you can change your commits. It will look something like the code below:
pick 130deo9 oldest commit message
pick 4209fei second oldest commit message
pick 4390gne third oldest commit message
pick bmo0dne newest commit message
In order to combine these, we need to change the “pick” option to “fixup” (as the documentation below the code says) to meld the commits and discard the commit messages. Note that in vim, you need to press “a” or “i” to be able to edit the text, and to save and exit, you need to type the escape key followed by “shift + z + z”. Don’t ask me why, it just is.
pick 130deo9 oldest commit message
squash 4209fei second oldest commit message
squash 4390gne third oldest commit message
squash bmo0dne newest commit message
This will merge all of your commits into the commit with the message “oldest commit message”.
The next step is to rename your commit message.
In order to change the commit message, use the amend flag.
git commit --amend
One advice for all the aspiring candidates: Try to find a project that you actually like and is best suited in accordance with your skills and knowledge.
Thats all from my side.Thank you for reading my first blog with patience :)