DEV Community: Srisuma Atluri

Git Handbook

Srisuma Atluri — Mon, 23 Jan 2023 15:22:30 +0000

Hello everyone!

This blog post is going to contain all the git commands with its use cases for quick lookup.

Without further ado, let's jump into it.

BASICS

git init - to initialise the repository for git to track it.
git add <filename> - adds the untracked file to stage.
git add <file-1> <file-2> <file-3> - adds multiple files based on the specified file names to stage.
git add . - adds all the untracked files to stage.
git restore -stage <filename> - unstage the i.e it moves to untracked files list.
git stash - moves both the (un-committed) staged and unstaged files to stash (like backstage) for cleaner working directory.
git stash pop - moves back all the files in stash area.
git stash clear - clears the files in stash i.e permanently deletes.
git commit -m <title> -m <description> - commits the staged/tracked files with the corresponding commit message and description.
git log - public record of commit history for a branch.
git reflog - private record, saved locally used for recovering deleted branches.
git reset <commit-id> - resets the head to the commit id mentioned and the removed commits are pushed to unstaged area.
git reset --hard <commit-id> - resets the head to the commit id mentioned and deletes the changes of above commits permenantly.
git revert <commit-id> - While git reset does this by moving the current head of the branch back to the specified commit, thereby changing the commit history, git revert does this by creating a new commit that undoes the changes in the specified commit and so does not change the history. 14.git push origin <remote-branch> - pushes your commits to remote repository, thats mentioned in the command.
git push origin <remote-branch> -f - force push required when remote branch has some commits which aren't present/removed in local(eg: with git reset).
When working with forked projects, we need to fetch upstream commits - git pull upstream develop This creates an extra commit.
git rebase -i <commit-id>- Squashing your commits above a particular commit id(you can either pick or squash)
git commit --amend -no-edit - adds the staged files to previous commits without generating a new commit.
git commit --amend - adds the staged files to previous commit whilst providing an option to edit the previous commit. This and the above are very helpful when some logical step is missed in the previous commit.

Prefer rebase over merge to pull remote changes to avoid merge commits -

git remote -v - displays all the remote urls attached to the local repository.
git remote add <remote-name> <remote-url> - connecting your local git repository with the remote repository hosted on Github with the remote name.
- <remote-name> is generally origin for the repo cloned from github. It basically depicts the repository that we want to connect to.
- A repository might have multiple forks in which one of them can be cloned to the local repository.
In order to pull the changes from upstream repo into the fork - git pull --rebase <remote-name> <feature-branch>
- this pulls and rebases the remote branch of upstream repo without making an extra commit on feature/develop branch of forked repo. Feature branches don't need to track merge commits.
- resolve the merge conflicts in the process of rebase if exists.
- use git rebase --continue once merge conflicts are resolved for a particular commit to continue further.
- use git rebase --abort for aborting the rebasing.
If you need to squash any duplicate commits, use git rebase -i HEAD~N or git rebase -i <commit-id>.
DO NOT FORGOT to FORCE PUSH the commits that are squashed or amended. git push origin develop -f

QUESTION

And there's some famous question/doubt everyone has on their mind when starting off with git/github:

Why is a git 'pull request' not called a 'push request'?

"Push" is you forcing the changes being present in the target repository (git push).
"Pull" is the target repository grabbing your changes to be present there (git pull from the other repo).

A "pull request" is you requesting the target repository to please grab your changes.
A "push request" would be the target repository requesting you to push your changes.

Always write better commit messages

Commit history is the index.
Writing meaningful, logical and verbose commit messages allows others to understand the task or story that the PR solves.
Prepend the commit message with its the type like feat, chore, fix, test, docs, refactor etc. https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/
squash all duplicate commits so that the master branch contains clean commit history.

Thank you!

My first step towards OSS

Srisuma Atluri — Tue, 01 Nov 2022 06:29:12 +0000

Hello everyone!
Most of you might already know what open source software is and the community around it.
Today I would like to share my first step towards OSS where I participated in the Hacktoberfest event and was able to successfully submit 4 PRs that got approved 🚀🚀🚀🚀

My contributions and learnings

During the month, maintainers of OSS from all around the world tag issues as "hacktoberfest" and "good-first-issue". Most of the issues are beginner friendly, especially for first time contributors. This was the best time for me to start out and learn the about it.

So I found a project called ToolJet that signed up for Hacktoberfest and actively providing good first issues for contributors who are beginning.
ToolJet is basically an open-source low-code framework to build and deploy internal tools quickly without much effort from the engineering teams. It was using javascript and react where my area of interest lies.
I worked on fixing few good first issues that were opened by the maintainers.They were very responsive, reviewed the PRs carefully and always checked if changes align with their code standards. Even though my contributions weren't huge, having it merged gave me an immense confidence boost.
Checking to a whole new repo, reading through the code and figuring out things was great. While contributing to this repo, I additionally learnt about docker and how applications run on it.

Also, while preparing for interviews last month, I found the Freecodecamp developer quiz resources very useful. Javascript was my main area of focus, so I wanted to added few questions to the repo that didn't have few important topics like closures, event delegation etc. So opened a PR for the same.

Therefore, from a developer who was using numerous open source libraries in own projects to contributing to one of them feels awesome. I am so glad for choosing to participate and hope to continue on it.

Would love to take any suggestions related to OSS contributions.

Thanks!

My experience and learnings as a Software engineer so far

Srisuma Atluri — Mon, 31 Oct 2022 07:52:59 +0000

Okay, it is little more than two years of my career and would like to take a moment, pause and write down things I learnt and would love to share with you all. Hope these bits of information might help you if you are just beginning your career and looking for some guidance.

I started off my career after my graduation in the pandemic, mid of July, 2020 which was the period where whole world was in total chaos, so was I. Reason for it being - how can I start working online? It's something I never thought of, remote jobs was so unfamiliar. How can I get to know my teammates online and ask for help? And when I got to know I would be the second developer in Hyderabad working with my lead to learn and build the team from there ahead, a hell lot of questions were running on the mind.

But so grateful that all the negatives I thought about while my career hit off turned out to be not so negative, instead they all were beautiful learnings. I had an awesome supportive mentors during the initial days which turned out to be a blessing in disguise. Why a blessing? It's because I was just not taught on what and how we should be working but also why we are actually working on a particular project/task and at what scale/impact the changes would result in.

This played a subtle but huge difference in my thought process on the tasks I picked up, the way I looked at problems. Initially, I was girl who used to rush things to finish off the task quickly and panicked when things wouldn’t fall in place. But over these 2 years understood that Software Engineering is not sprint to be completed quickly but a marathon to be ran carefully.

Things I picked up on my first job apart from the tech stack:

Planning

Planning things properly played a crucial role. Writing down a list of things I would like to finish off for the day in the morning and keeping enough pace to at least complete 80% of it. Not always I could finish off goals I set for the day. Sometimes, a part of your day might be involved in helping your teammates or you might be in a very bad mood, end up unable to concentrate or get stuck somewhere. Having said all the above, having a list is still important. Always track things down and carry forward the leftovers.

Communication is key

When things go south, never hesitate to ask for help. Don't get stuck with a problem for too long, you can always google and try to fix things but if even that doesn't help, reach out your teammates. They have a fountain of knowledge that they would definitely love to share. Ask in the channels so that someone on your team would jump in to help you. Having a good bond with all of your teammates is a great thing you can do for yourself. We aren't machines who can keep on work, pause for a while, talk to people maybe new people as well sometimes. There would be so many ideas triggering out of your mind.
And also always share your knowledge with them.

Writing clean code

Also, I had a misconception that being a software engineer, my love for problem solving would be the driving factor but it is more that just solving problems like in CP. We need to identify and articulate problems, architect/design possible solutions for it and then comes to implementation. Hold on, it is not the end. I spent days addressing reviewing comments for the my PR’s initially and most of them include writing clean code apart from the functionality review.

Debugging

Learning how to appropriately use debugging tools has had huge impact. During the first few days, I had no clue of google dev tools when working on web or placing debugger on VS code for server side code. I just used logging statements throughout the codebase and hoping that I could find clues as to the location of the problem. But once when I was told to learn more about the debugging tools, I fell in loving with solving bugs. These tools helped me interpret code a lot better as we could see the data thats flowing through.

Summary

Therefore, planning, communication, problem solving (debugging) and writing clean code are few key attributes I think a software engineer should possess.
Let me know the ones that I might have missed and you think are definitely required on this list or anything amiss.
Happy to discuss.