Command Line

The problem During a git merge or rebase, you see the following merge conflict message:

A while back I wrote about managing local git branches with git rebase and I mentioned that I always submit my code changes with one commit only. No matter how many commits I make during my development process in my local branch when I prepare my code for code review and push it to remote, I squash all commits into one single commit, with one single commit message using git rebase.

git is a very useful tool for software development and you only need to know a few commands to get most of the job done. However, you can be a lot more productive if you go beyond the basics.

A few months ago I got a new computer and I have been very intentional about deciding what I install on it. From past experience I know that computers that are used as a development environment tend to get messy in no time since one might install all kinds of libraries, frameworks, dependencies, you name it, and to makes matters worse, you will probably run into version conflicts for any or most of those things. Hardly ever a development environment is a clean environment and I don’t know about you but there are very few things that I find more frustrating than wasting time troubleshooting development environment set up. Let me write the code already!

A few years back when I got serious about learning to program to become a software developer, I remember hearing about version control and getting really confused about git and GitHub (one can add GitLab to this list also!). Are they the same thing? Eventually, I figured it out but this past week in a conversation with a coworker, who is interested in getting into software development, I noticed that they also were confused about this so I decided to write about it.

When I first heard about git bisect I thought it sounded scary and complicated, so I never looked for an opportunity to learn more about it and use it. That’s until last week when I ran into a bug in our master branch. I knew that the bug was not there two days before so I tested an earlier commit and confirmed that that older commit was a good one. Now, we had tens of commits in between. How to find out when exactly the bug was introduced? It would be impractical to check and test each individual commit.

When I need to create a new custom Docker image, I usually start with a base image (alpine, debian, python, etc, depending on the project), running it in the interactive mode and install the tools and dependencies I will need. Once I get my container the way I want, I create a Dockerfile with all the commands I ran inside my container. It works, but I just learned that this might be unnecessary extra work.

In a large web application, the backend logs can get quite verbose: requests created, sent, processed, received, etc. The list can grow large very quickly depending on how logs are implemented.

I normally don’t use many shortcuts because it’s easier to just use my arrows and mouse to navigate than to memorize shortcuts but I am slowly realizing that the time spent on learning a new shortcut pays off.

OR: Run a Python script with arguments You can add arguments to the command line when running python scripts by importing the sys module from Python’s standard library and using its argv function.

NOTE: the steps below assumes you have a Bash shell. If you are using a Unix machine (Mac or Linux) and are not sure what type oh shell you have, it’s probably Bash.

Recently I needed to repeat a series of long~ish commands in the command line but I never quite memorized them so I ended up resourcing to arrow-up-arrow-up-arrow-up </ad nauseum> until I found the command I was looking for.

I wrote a very simple right-to-the-point Docker introduction post if you’re new to Docker. If you want to see your code changes applied right away to a running Docker container, you need to make sure to run the container using the share volumes tag: -v (or --volume).

From Python’s official documentation: “A profile is a set of statistics that describes how often and for how long various parts of the program executed.”

Docker has been around for a few years but it sounded too complicated and I never knew exactly what problem it was solving. Only recently I learned about it and started using Docker both at work and on my personal projects.

Here’s a list of the git commands I use most often: git status when to use it: to know what is the status of the files in your branch. It will show what files have been modified, added, removed, committed, etc. A snapshot of your branch’s current situation. It’s super safe because it doesn’t change anything. It just give you… the status. I git status everything, every time.

There are times when a command line output is too long and it’s hard to scroll through all the lines to see the beginning of the stack trace. This usually happens when you get errors and the best way to fix errors is to read the very first few lines to understand what error message you got and where the error is coming from.