Git

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.

Existem algumas maneiras diferentes de desfazer as coisas no git, mas para o propósito deste post vamos considerar o seguinte cenário:

There are a few different ways to undo things in git but for the purpose of this post we will stick with the following scenario:

When you work on a codebase with other people, you need to manage your local branches: you need to ensure that when you push some code and create a merge/pull request on the remote branch, your changes will be easily integrated with the main codebase. And by “easily” I mean preferably without merge conflicts or the dreaded message “your branch is xxx commits behind the target branch”. ?

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 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.

I recently committed an API key to a repository and even worse, I pushed to GitHub before I realized my mistake… 🙁 Removing the key from the code base wouldn’t completely solve my problem since a commit diff would still display my secret key. The solution was to remove that commit from history.

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.