DEV Community: Andrey Barkov

6 Git tips for everyday use

Andrey Barkov — Thu, 18 Jun 2020 04:19:03 +0000

I've recently noticed how many things I've learned with experience, I assume, to be common knowledge. Although, not everything that is obvious to me can be obvious to someone else. I hope you'll find something for yourself.

Start fresh, merge fast, merge often

There are many branch strategies that you may use for managing your source code. Still, I know for sure that the longer the branch lives, the more chances it will cause you massive headache merging the changes.

Every time you start working on a new piece of code or fixing an existing one, make a branch specifically for it from the latest source code. As soon as you're done, and change has been approved and merged, delete the branch.

You might say, but hey, this next thing I need to build depends on this work, why wouldn't I keep working on this branch?
I'll answer, sure you can, but in this case, you need to make sure you keep rebasing the latest code in your working branch and help you God if somebody else is working on the same files.

The general best practice for Git is to commit fast and often. I will add that you also need to merge fast and often. Going in small increments allows you to avoid merge conflicts. It exposes your work to the team sooner so you can get feedback more quickly.

In case the work you're doing contains flaws, you would know about it before you're too deep in the rabbit hole.

Make Amends

Did you make a commit and then notice a typo or a missing space right after? Instead of making a "fixed typo" commit, you can add it to your previous one. Just make a change, stage your file and then do git commit --amend this way it will add your fix to the last commit and will also allow you to change the name your previous commit.

Note: if you have already pushed your changes to remote and then made an amend, you will need to git push --force

Backup before doing wonky stuff

There are situations when your branch becomes all messy and full of merge conflicts, and you're not sure if your next command is going to fix it or break it for good? Before proceeding, make a backup branch, just in case, to have your changes somewhere. If you override the history of your working branch by accident, then parts of your work might be gone!

Use aliases

Using aliases saved me ample of time typing "checkout" or "commit" every time. Setting aliases is as easy as that:
$> git config --global alias.co checkout $> git config --global alias.br branch $> git config --global alias.ci commit $> git config --global alias.st status
For some more advanced aliases check this article

Use stash

Have you ever started working on something only to realize that you're in the wrong branch? Or have you ever found yourself in a situation that you've changed something, and your program stopped working? Now you're commenting out a piece of your code or reverting line one by one to find a problem? Maybe your project has some configuration file that you need to change every time you work on your code locally?

Look no further than git stash to solve all the above scenarios for you. This command will take all your uncommitted changes and save them to a safe space independent of any branch and revert all your uncommitted changes on the current branch.

If you started making changes in the wrong branch and realized that before committing a change, do a git stash, switch to the branch you need. Then hit a git stash pop, and all your changes reappear but on the correct branch now.

Once the stash is popped, it is not going to disappear. You actually may see all your stashes by using git stash show. That means that you can pop stash multiple times. So if you have that annoying config file that you have to change back and forth, you can simply stash and pop it as you need. You can do it via git checkout stash@{0} -- <filename>

Also, useful when you do your work and suddenly completely unrelated unit test starts failing. Now you're not sure if you broke it or it was broken before you've started. Stash your changes and rerun your tests to learn the truth.

GitLens extension for VS Code is super convenient for managing your stashes, just FYI.

Don't delete your local repository

Not once I've seen people working on the local branch then pulling the latest code into local and being overwhelmed by the number of merge conflicts. In fact, they were so overwhelmed that deleting a local repository and downloading it again seemed like a valid option. What a surprise was for them to realize that all of their work was now gone.

In reality, deleting your local repository to fix a problem is never a viable option. So if you ever considering removing a local repository, do this thing first: Ask for help.

Do not hesitate to ask for help. It takes time to get used to Git. Being afraid of asking questions and appear not knowledgeable is not as bad as not asking questions and staying unknowledgeable.

Hit me up on Twitter to tell me what a bunch of nonsense I've written @ramen_modules

Why do we need a scrum master, anyway?

Andrey Barkov — Fri, 29 May 2020 19:23:54 +0000

Sometimes, maybe more often than not, you might wonder, what the heck does your scrum master do aside from scheduling useless meetings?

Agile and, particularly scrum, are being wildly adopted nowadays by every IT company. I believe you won’t be able to find a tech company founded after 2005 that won’t be using Agile methodology (or at least try). Although, based on my observations, it is rare when an entire company or even an entire team has a good understanding of what Agile methodology is. More than once I’ve heard from my peers: “Agile? Yeah, we have stand-ups every day and use JIRA”, “Sometimes, I don’t understand what for do we need our scrum master”.
I will try to explain why your team needs a scrum master.

Answering questions

One of the scrum master responsibilities is to ensure that everyone on the team understands Scrum and Agile. If certain practices or processes make little sense to any of the team members, it is up to the scrum master to answer the questions.

If you genuinely don’t understand why in the world you need daily stand up, retrospective, or any other meeting, raise questions to your scrum master.
Each team or company may have variations of Scrum, so I believe it is paramount for every Scrum master to have a session with the team where they discuss their understanding of Scrum, getting on the same page with the team and adjusting the process to the reality of a particular team and project.

There are also questions that the scrum master shouldn’t be answering. It is not up to scrum master to tell you how to solve a technical issue or write your code. Even if the scrum master knows the answer to the question, most of the time it is better to nudge team members in the right direction instead of giving a solution.

Asking questions

Questions are the best tools available to the scrum master. Asking the right questions at the right time enables scrum master to facilitate better communication within the team and help with problem-solving or decision making. This way with almost no intrusion scrum master can make the team more effective.
Good scrum master understands that the development teams are the experts at how to get their job done and seeks to understand what might hold the team back.

Removing impediments

One of the primary active tasks that scrum master performs is removing the obstacles in the way of the development team. Anything that is a potential or an actual roadblock brought up by the team is the responsibility of a scrum master.

Most of the time the impediments come from without the development team like 3rd party vendor, organization, or the client. In such cases, the scrum master has to analyze if the impediment is indeed blocking the team and what is the root cause for it. Sometimes there is a possibility that the development team can resolve or work around the blocker on its own. However, other times when the means of removing a problem is out of the team’s hands, the scrum master needs to track the impediment and drive the communication to achieve a resolution. The scrum master cannot let the impediment just hang in there.

Actively doing nothing

To help the team become more efficient the scrum master shall observe the team working, the processes spinning, and note any problems, but do not engage. By choosing to not engage, the scrum master allows the team to own the situation, otherwise, by acting and solving issues for the team, scrum master will be taking away the responsibility from the team as well as a chance to reflect on the process and identify problems themselves.

Protecting the Team

Scrum Master is also responsible for ensuring that the team is not being disturbed by any outside parties without need. There are certain situations when the client would reach directly to the member of a development team with some issues or asking for a favor. Scrum master shall keep track of such communications and handle client requests appropriately. There are different situations and circumstances when the team has to pivot during the sprint, but a scrum master should be a proxy for any non-sprint work or ask that may come up.

Things scrum master doesn’t do

Scrum master is not a traditional manager. Scrum Master doesn’t decide for a team.

Scrum teams are self-organizing meaning that scrum master doesn’t have the authority to make decisions on behalf of the team. The team is responsible for planning, estimating, and executing the work in the way they seem fit and in the priority defined by a product owner. Although, Scrum master can facilitate transparency and effective communication to help the team with decision-making.

With this said, Scrum master is not being held accountable for product delivery. The development team and product owner must hold ownership of their work and product delivery.

Scrum Master doesn’t talk to the team on behalf of the product owner or vice versa. If the team has anything to discuss with the product owner, a scrum master has to facilitate the communication rather than being a mediator.

Conclusion

The term scrum comes from rugby. It is the moment between rounds when a team comes together in a circle to quickly discuss tactics for the next round. Scrum master performs the same job as any sports coach:

Provides team with training and tactics
Helps to improve team performance through observation and advice
Inspires team to perform at the peak of their ability
Ensures team success by removing distractions and obstacles

An important thing to notice is that Scrum became so popular so fast, that you can meet a lot of inexperienced scrum masters and feel like they are not bringing any value to you and the team. Here is a little secret:
If the team is mature enough, it doesn’t need a scrum master.
Start with yourself and get educated about Scrum. Try to understand what stands behind Agile values and principles. Educate your team and, if needed, your scrum master.

Hit me up on Twitter to tell me what a bunch of nonsense I’ve just written @ramen_modules