DEV Community: Chris L

Switch context faster with git worktree

Chris L — Fri, 25 Oct 2019 14:57:28 +0000

Working with git has made lives of many developers in the world a lot easier but it also brought some quirks, especially for those who work in fast paced environments. Having multiple branches and working on many things at once is a normal thing nowadays.

So, what do you do when you're working on a feature, you're deep down the rabbit hole, and suddenly, you have to switch and work on something else like a hotfix?

For me, personally, it meant that I'd stash my changes, fetch master, create a new branch and restart my editor to not have cluster of opened files. That also meant that when I finished working on the hotfix and when I got back to the original feature my reaction was somewhat like this:

Let's introduce git worktree.

A git repository can support multiple working trees, allowing you to check out more than one branch at a time
https://git-scm.com/docs/git-worktree

But what does it mean?

Using worktree you can easily create a local copy of your desired branch outside your main repo, work on it like you'd normally would, without having to stash anything!

Enough talk, show me the code!

In your main repo dir do

git worktree add -b super_important_hotfix ../super_important_hotfix origin/master

This will create a new directory with an exact copy of your repository (at origin/master) and switch to a new branch called super_important_hotfix.

You can now work on your super important hotfix without polluting the main dir.

touch super_important_hotfix.txt
git add super_important_hotfix.txt
git commit -m 'Fixed bug'
git push

Go back to your main repo dir and eveything is exactly the same you left it!

Once you're done with you hotfix you can remove the dir we created for it and run git worktree prune from the original directory to cleanup references to it.

You can have a more in depth look at git worktree here

Happy coding!

Love Ruby, new tech, and working remotely? Check out https://leadfeeder.com/jobs and don't forget to mention my name!

How to quickly search all your repos at once

Chris L — Wed, 06 Mar 2019 11:29:21 +0000

Working with microservices can be a pain, especially when one change can require multiple places to update. You have to check various repositories for occurrences of the piece of code you need to change. What can you do in that situation?

Open all your repos in your favourite editor at once
Use GitHub's search
Open each and every one of your repos and search manually
Follow instructions below and start using Hound

What is Hound and how to set it up locally?

Hound is an extremely fast source code search engine. The core is based on this article (and code) from Russ Cox: Regular Expression Matching with a Trigram Index. Hound itself is a static React frontend that talks to a Go backend. The backend keeps an up-to-date index for each repository and answers searches through a minimal API.

from https://github.com/etsy/hound

And here's how it works!

Here's what you do:

Go to the folder you want to keep the configs for Hound, for me it was ~/code/hound
Create a config.json file, that points to your local repositories, like this
Run docker run -d -p 6080:6080 --name hound -v $(pwd):/data -v ~/code:/code etsy/hound. Please remember that if the folder you keep your repos at is named differently, you have to adjust it in the config.json and in the docker command, specifically -v ~/code:/code part!
Go to localhost:6080 & enjoy your quick search!

Bonus: Hound has integrations with Sublime, Vim, Emacs & Visual Studio code so you don't have to leave your favorite editor!

Shout out to https://twitter.com/kmossco and https://twitter.com/balazs_kutil for showing me Hound 🙇

Don't forget to check out my other posts at here.
Love Ruby, new tech, and working remotely? Check out https://leadfeeder.com/jobs and don't forget to mention my name!

General ideas/guidelines for fresh developers

Chris L — Tue, 05 Jun 2018 21:31:19 +0000

This is a very general guide for less experienced software developers. It took me some time to realize these over the years and I think it would be a great help to me back when I started with coding.

Your code should be readable. Why? This great quote will explain it all.

Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write
- Robert C. Martin
Tests... Some clients/project managers believe that spending money on testing is a waste. You don't need that kind of negativity in your life. Tests are very useful for a bunch of reasons! First of all, they check if your code actually does what it's supposed to do. Second, refactoring - have you ever tried to refactor a class and hoped that each method returns the same result as before? Tests are also a type of documentation that helps new teammates understand what how and why.
Even though code never lies and comments sometimes do, it's generally a good idea to comment your code. Try to shy away from comments that explain your complicated code (see point 1) and use comments as a way to explain the business logic. Why this piece of code does what it does.
As a developer, it's your responsibility to take care of your ~~child~~ code. You think that a refactoring is in place? Get your client or project manager and explain to them why refactoring is a good idea and is needed. Technical debt always comes back.
Ever wonder what's with all the rubber ducks around developers? When you're stuck on a piece of code you can try explaining it to a rubber duck. This method is called rubber duck debugging and it's a very powerful weapon in a developer's arsenal. Talking about your code and trying to explain it to somebody will help you get unstuck and think differently about your code.
Sometimes even a duck won't help. Talk to other people, preferably other developers ;)
Have you heard of Agile? There's this idea of a daily meeting where the team talks to each other and shares problems or issues. Give that a try, it's easier to share ideas and ask for help when everyone knows what you're doing.
Documentation. Even more dreaded then tests. Tell me this, how would you use your favorite API or 3rd party service without their docs? Keep your teammates and other teams happy when working with them and document public-facing things.
Remeber the principles of software development (DRY, KISS, SOLID, and YAGNI) and try to use them on a daily basis, e.g. extracting a class or a module (DRY) will help to keep your code maintainable.
Sometimes when you read through the code you can find some oddities or simply a bad piece of code. Sure it works, but if you can improve it easily then why not? It's called the boy scout rule - "Always leave the campground cleaner than you found it".
"Measure twice, cut once" - it's always better to think about (or write down) things before doing actual development.
It may come as a surprise to you, but you're human. Everybody makes mistakes. You make mistakes. Get it over with. Making mistakes is a part of the job, I'd say. Try to make the most of it and when you make a mistake, try to learn from it as much as possible.
Don't hesitate to ask questions and oppose ideas. Questions can spark a discussion on why this feature is needed, how we should implement it, and what are the risks of this implementation.
Be eager to learn and to spread your knowledge. Books, blog posts, RSS feeds, conferences, podcasts, local user group meetings. Those are great to learn new things and to talk about your experiences.
Always keep an eye out for new libraries and new versions of frameworks/libraries that you use. Newer versions bring new and exciting features!
Use your workflow to your advantage. You're using vim? Great. Atom? Nice. Sublime? Yay. Write down your code on pieces of paper and then scan them? Whatever floats your boat. You want to know which editor/ide is the best? The best is the one that makes you feel comfortable.
Try to be professional. Don't use phrases like "we'll see" and "hopefully". How would you feel if you took your car to a mechanic and he'd tell you that hopefully, he'll fix it?
Never be afraid to ask. If you don't know something or are not sure, for the love of god, ASK.

PS. Oh, and take Ballmer Peak into consideration! ;)