Git on Piotr Wittchen

Different ways of squashing commits

Sat, 21 Jul 2018 11:21:54 +0000

While creating a Pull Requests it’s good to squash all of our intermediate commits into one to avoid clutter in the git log, simplify analysis and allow for simple code revert when necessary.

Solution #1

Some time ago I’ve found project http://rebaseandsqua.sh/ made by Jake Wharton. It’s really useful, handy and allows us to rebase and squash commits quite easily.

We can just call:

curl rebaseandsqua.sh | sh

then edit our commit messages and push the changes.

Avoiding merging master to master branch in Git

Sun, 25 Mar 2018 13:35:06 +0000

Problem

If you are working with Git Version Control System, probably you have seen a commit messages in your git log like:

Merge branch 'master' to 'master'

or something similar. You might have even pushed such commits! Don’t worry, so did I ;-). In this article I’m going to explain why is it happenning and how to avoid it.

Such situation happens when you performed changes locally and at the same time someone else performed changes on the same branch as well, commited and pushed them to the remote repository. When you are done with your changes, you committed everything and want to push changes. If there are no conflicts, Git wants you to synchronize local repository with the remote repository. That’s why you need to merge changes from the remote master branch into your local master branch. After that you can finally push your changes.

Meet and Code 2017 - "Git – tips & tricks" presentation

Sat, 21 Oct 2017 10:36:00 +0000

Recently, during Meet & Code event organized by Media 3.0 and SAP Hybris, I’ve gave a talk for university and high-school students about basics of Git. Presentation was titled Git - tips & tricks and was organized at the Silesian Univeristy of Technology in the AEI Department where I was studying a few years ago. Presentation covered quite essential usage of Git, which could be helpful for people who are planning to learn it from the scratch. Nevertheless, in the talk I included a few tips, which could be applied even by more advanced users in their daily work. You can view slides from this presentation below.

Review your changes in the code before the commit

Sun, 26 Mar 2017 22:18:00 +0000

Most of the people use git as follows.

they create a feature branch
they make some changes
they add all the changes: git add -A
they commit changes: git commit -m "I've done changes"
they push it: git push

There’s a problem with such approach. When we created a lot of changes, it may happen that we forgot to delete something and we pushed some garbage to the remote repository.

My approach to Git aliases

Sun, 12 Mar 2017 13:20:00 +0000

While we are working with Version Control Systems like Git, it’s good to adapt them to our needs to perform daily work in a more productive way. People often create so-called Git aliases, which are shortcuts for longer commands. E.g. you can edit your .gitconfig file, which is usually located in your home directory and place a few aliases in the [alias] section. For example:

[alias]
  ls = log --pretty=format:"%C(yellow)%h%Cred%d\\ %Creset%s%Cblue\\ [%cn]" --decorate

Then you can type: git ls in your Git repository to see pretty Git log. Sometimes people go further and create many more aliases like:

Working with different Git configs

Fri, 10 Mar 2017 19:30:00 +0000

Short introduction

Sometimes people need to specify multiple values for single .gitconfig file or they want to share just part of the configuration between two machines. There are different approaches for that. I can show you mine.

Different configs for different Operating Systems

On my private computer, I use Linux. I use Git for my private projects and I use my private e-mail address there. At the same time, I use Git at work on macOS with exactly the same Git configuration, but with a different e-mail address. How to deal with that? In my .gitconfig file, I set my private e-mail address, which is used by default. In my .zshrc file, I created two aliases:

Automate boring stuff

Sun, 01 Jan 2017 11:10:00 +0000

Introduction

In my current company all the people who perform creative work (mostly programmers) need to prepare so-called PKUP report. PKUP stands for Podwyższone Koszty Uzyskania Przychodu in the Polish language. It’s legal regulation in Poland, which allows paying a lower income tax due to the particular type of work. For the regular employee, it means that he or she will simply get a bit higher salary per month.

How the report looks in practice?

As a programmer, I simply create software as a source code. Added, removed and modified lines of code in the existing codebase are treated as my creative work. Luckily, we use Git so I can generate *.diff files from the Git repositories I’m contributing to. Besides that, I need to prepare document as a *.docx file with a short description of my work. My tasks look different every month, but report actually looks almost the same every month. Preparing this report is boring and repeatable stuff.

3 questions about your Git repository

Mon, 28 Dec 2015 21:37:00 +0000

Introduction

Can you answer the following questions about your Git repository?

Does development branch has all changes from master branch?
Is your gitlog a crap?
How old are your branches?

If not, but you want to know answers, you’re lucky, because I prepared 3 simple scripts for you, which can help to find it out.

Does development branch has all changes from master branch?

git-branch-comparator is a python script, which checks if development branch has all changes from master branch in Git repository. Another, easier way to accomplish the same task suggested in comments by Mike (thanks!) is to call simply:

Checking consistency of git branches

Thu, 14 May 2015 15:16:00 +0000

Recently I’ve created a simple Python script, which checks whether ‘development’ branch has all changes from ‘master’ branch in a Git repository. It’s important when we work in a Git Flow. Branch inconsistency may occur when change with hot-fix will be committed to ‘master’ branch and we forget to merge ‘master’ branch back to ‘development’ branch to have our hot-fix in a ‘development’ version of the project as well. We should keep branch consistency to avoid merge conflicts and problems with release of the project in the future. Mentioned script is able to perform necessary validation helping to detect potential problems. Moreover, script can be integrated with the Jenkins CI server and we can execute it from a command line via Jenkins job. When, changes from ‘master’ won’t be merged into ‘development’, job will fail. In opposite case, job should finish with a success. In a Jenkins job we need to remember to add the following Additional Behaviours in Source Code Management (Git) section:

Basics of Git

Thu, 27 Nov 2014 21:49:00 +0000

Introduction

Git is very popular Version Control System used in many software projects today. In my opinion, it’s the best VCS available today. In order to start your adventure with this tool, you should know its basic commands and features. There are graphical tools, which allows to use Git without terminal, but I recommend you to use terminal. With CLI you can work faster, you can understand Git better and you have more control over your repository.

How to update forked GitHub repository?

Fri, 07 Nov 2014 12:29:00 +0000

When you fork GitHub repository, you usually want to have your fork up to date with the original repository. You can update your fork in a few easy steps. Just look at the following example of the Git commands:

Add the remote, call it upstream:

git remote add upstream https://github.com/whoever/whatever.git

Fetch all the branches of that remote into remote-tracking branches, such as upstream/master:

git fetch upstream

Make sure that you’re on your master branch:

Versioning Android applications

Sat, 13 Sep 2014 12:49:00 +0000

When we work in a team projects, our code constantly changes and being tested. Often some bugs occur in a specific version of application and no longer exists in next version of the project, because one programmer might fixed the bug according to the Boy Scout Rule and this is good. Nevertheless, sometimes we need to write documentation and check in which version bug occurred to be sure, that it was really fixed. In addition, QA Engineer needs to know, which version of the project he or she should check. That’s why we should introduce versioning system to our project. In Android Manifest we have versionCode and versionName. The versionCode is used for updates on Google Play Store and it has to be integer value. We should increment versionCode before releasing new version of the application for the users. The versionName available in Android Manifest is a string value and we can use it to store information, which we need in a current project. When we use Git as a Version Control System, we can put SHA value of a specific commit into our version name. In addition, we can add date and time of compilation to this variable. After that, our versionName contains very detailed information about current version of our application. Exemplary versionName will look in as follows: f935ea7-20140913144001. We can obtain that with proper configuration of build.gradle file containing buildTime() method and gitSha() method. Please, take a look at creation of versionName in 35th line of the build.gradle file presented below.

Updating Android XML resources before compilation via Gradle

Wed, 10 Sep 2014 21:22:00 +0000

Problem

In a team project, we encountered one of the common problems connected with mobile applications. Android application sends requests to backend web service and we don’t have backend web service deployed right now on a separate server, so every mobile developer is compiling and running backend web service on the local machine for testing purposes. In the beginning, url of backend url looked as follows:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="backend_url">192.168.1.1</string>
</resources>

Of course address varies on different machines.