DEV Community: Vatsalya Goel

Rewriting Git history : Being opinionated about Git

Vatsalya Goel — Tue, 10 Jul 2018 14:39:56 +0000

In my short development career I've heard many different opinions on how to use Git the right way. There are a lot of times when the answer is "it depends" and can be daunting for a new user getting started on Git. I've picked on some tips to make my source control habits nicer which I'll mention below. Everyone's workflow is different but here are my tips on maintaining source control so when a new developer joins your team they won't be confused on where to start.

Learn the `git` CLI

Don't get me wrong, Git GUIs are nice and offer a lot of features that will feel very clunky if you used the cli such as comparing diffs, reversing hunks or just looking at the history. A GUI will be sufficient if all you're looking to do is commit and push. Git has a lot of other tools to offer and the cli is your friend when working with the history and not the content itself.

Trunk based development

To give a bit of context the master or trunk is where the production ready code should live and is the branch that is checked-out by default if you clone a new repository. There have been multiple occasions in which I've cloned a git repo looked at the history and there is a develop or a release branch which is 100 commits ahead of master which was last updated 2 months ago with code that doesn't even compile anymore due to outdated dependencies or no historical context of which branch I need to be using.

It raises so many questions such as:

Are we not using master anymore?
Is the branch deprecated?
Do I just reset master to the current head?

Trunk Based Development is a workflow defined as "a source-control branching model, where developers collaborate on code in a single branch called ‘trunk’, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after." So create short lived feature branches that are integrated often so any future developers who join the project remain happy.

If you do want to keep track of releases, tag the commits that you have releases on. That is what tags are for.

Never commit to `master` directly

Following up on trunk based development, don't commit to master directly. Protect your master branch from abuses such as:

"fixed typo"
"Hack-v2"
"resolving merge conflict"

Make your changes on hotfix/typo or feature/add-this-feature create a pull request and let other people review your code. Don't be scared, code reviews are nice. This also lets you run Tests your CI before it is merged so you can fix issues that may have been caused due to your change. If you use a remote source repository, you can physically protect your branch so no one can push to the source of truth.

Github
VSTS

Merge vs Rebase

Here comes the most discussed question about what is the right way of doing things.

Proof?

Always rebase instead of merge. It makes your history look nicer. Let the pull request create a merge commit into master. That is the only time you want a merge in your code.

git checkout master
git pull origin master
git checkout feature/feature-youre-working-on
git rebase master
git push -f origin feature/feature-youre-working-on

git push -f AKA force push is used to overwrite the remote branch if there are any changes on your history such as you rebasing.

Note: This flag can cause the remote repository to lose commits; use it with care.

Now you may say isn't force push bad. If no one else is working on the same branch as you i.e. no long running branches then you shouldn't have to worry about force push. Knowing changes on your own branch and manipulating it is your decision and since master is protected you can't modify any release.

Commit messages

Write meaningful commit messages. Commit messages are important and can help new developers understand context of what changes were done. If using a backlog management system, link your commits to work items in your backlogs. Take advantage of the fact that you have a title and a body in your message. Be concise and everyone will love you.

Tools and useful commands

Throughout my journey with git, I have picked up commands that help me learn git, rewrite the history and make my life easier on a day to day basis.

Before we get started on commands, get this tool GitViz. You can put the path of any git repository and it will give you a live visual representation of the history and current state of the repository. It is great for a playground but don't use it as a full git UI tool.

I would also recommend cloning this playground git project that I created to simulate different scenarios that you may encounter. Create a blank project on GitHub and change the origin to the new blank repository by running git remote set-url origin {new repo url}

Alternatively you can you an in-browser tool from GitHub.

Merge to resolve conflicts

In this scenario we cover a change done on a feature branch that results in a merge conflict to master. To fix the conflict via a merge back:

git checkout master
git pull origin master
git checkout feature/merge-conflict
git merge master
resolve merge conflict
git merge --continue
git push origin feature/merge-conflict

this creates a commit Merge branch 'master' into feature/merge-conflict with the merge conflict resolution and if the branch is then merged back into master it starts to look very ugly

Rebase to resolve conflicts

An alternative to above is to

git checkout master
git pull origin master
git checkout feature/rebase-conflict
git rebase master
resolve merge conflict
git rebase --continue
git push -f origin feature/rebase-conflict

This changes the parent of your branch to the latest master and gives you a straight path to a pull request.

Interactive Rebase

Sometimes just resolving merge conflicts isn't enough. I am a big proponent of committing often however this can cause my feature branch to have many commits that won't make individual logical sense for reviewers to review.

In this example we will use interactive rebase and see how we can rewrite the branch history and group multiple commits into one logical commit so that reviewers have an easier time reviewing your pull request.

git checkout master
git pull origin master
git checkout feature/rebase-interactive
git rebase -i master

This will give you an output like this:

Each pick in the above image is a commit and as you can see, there are many small commits that I probably want to group into one commit

we can edit the above output to change pick into fixup which deletes the commit message and amends the changes into the commit above. Saving the file and exiting will apply the changes

git push -f origin feature/rebase-interactive

This results in a history like this

You will notice that even though the changes are merged the commit message is still add two so how do we fix the commit message. Use Rebase again

git checkout feature/rebase-interactive
git rebase -i master

This time instead of using fixup we use reword

Saving and quitting the file gives us another terminal output with the commit

Lets change add two to add two, three and four

git push -f origin feature/rebase-interactive

Finally your history will look like:

In conclusion Git is a very opinionated topic and everyone is comfortable using git in a certain way. I hope that I was able to see the benefits of using certain git workflows to make your development life easier and keep the sanity of the person who takes on the source repository after you.

Setting up a public web server using a Raspberry Pi 3

Vatsalya Goel — Thu, 12 Oct 2017 08:41:48 +0000

Very recently, I got hold of a Raspberry Pi 3 Model B. With the desire to setup a home automation system I first wanted to see if I could access the Pi publicly through my home's internet connection. This would have been the easiest task by just port forwarding if not for my ISP locking down the router behind a NAT-1 switch. This crushed my dreams of being able to do what I wanted.

I started looking at online solutions to securely tunnel from the Pi to the internet and obtain a publicly accessible domain. This is where I came across Ngrok, a service that allows you to tunnel a port on a machine and expose it publicly. Their use case surrounds demos and testing without deployments. However I tried to re-purpose it to setup a webserver on my Raspberry Pi.

Setting up the Raspberry Pi

What do we need:

A Raspberry Pi 3
A micro SD card with at least 8 GB space (16 GB recommended)
An SD card reader
Raspbian OS which can be downloaded from here
Etcher which can be downloaded from here
An internet connection (Wireless or wired)

Download Raspbian Stretch with Desktop from the raspbian download page. Plug the micro SD card into the reader. Unzip the Raspbian image from the download and use Etcher to write the image to the SD card.

Plug the micro SD card into the Pi and power it on. On the first boot you have no way of remotely connecting to the Pi. To configure remote access, plug the Pi into a monitor using the HDMI port. Connect a mouse and keyboard in order to configure the system. Go to Menu > Preferences > Raspberry Pi Configuration and under the localisation tab configure your Timezone, Locale and Keyboard layout. In needed to do this because the default region was set to UK and the keyboard layout wasn't the standard one I used. Go to the Interfaces tab and enable SSH and VNC. This is so that you can remotely access the Pi without having any peripherals connected to it.

Open a new terminal session and run passwd in order to change the password. the default password is raspberry

Configuring remote access

Open a new terminal session and run ifconfig and note down the IP address

Run the following commands:

$ sudo apt-get update
$ sudo apt-get install realvnc-vnc-server
$ reboot
$ sudo systemctl enable vncserver-x11-serviced.service
$ sudo systemctl start vncserver-x11-serviced.service

This should now setup remote access to your Raspberry Pi both graphical and terminal. Now you can go ahead and disconnect any peripherals you dont need connected.

To connect to the Raspberry Pi graphically, download RealVNC Viewer

Start VNC Viewer. Go to File > New Connection Enter the above noted IP in the VNC server field and give the Pi friendly name you can remember. Connect to the pi by double clicking on the new system you see on the dashboard. You should see a window like this.

Enter pi as the username and the password you set earlier as the password.

You should now have a remote connection to the Pi.

Setting up a web server

For this task I decided to use Nginx due to it's lightweight nature. You can decide to use Apache if you do need to.

To setup Nginx:

$ sudo apt-get install nginx
$ sudo systemctl enable nginx.service
$ sudo systemctl start nginx.service

Browse to 127.0.0.1 in the browser within the Raspberry Pi and you should see a Welcome to Nginx page.

To change the contents of the site, navigate to /var/www/nginx and change the contents to the site you want to deploy.

Making the site publicly accessible

Now that we have our web server setup, we want to make it publicly accessible. This is where Ngrok comes in. Go to https://ngrok.com and register for and account. Note down the authtoken they give you. This will be used to setup the tunnel.

Download and install the Linux ARM version of Ngrok by running the following commands

$ cd /tmp 
$ wget https://bin.equinox.io/c/4VmDzA7iaHb/ngrok-stable-linux-arm.zip
$ sudo mkdir /etc/ngrok
$ unzip ./ngrok-stable-linux-arm.zip -d /etc/ngrok/
$ rm ./ngrok-stable-linux-arm.zip
$ ln -s /etc/ngrok/ngrok /usr/local/bin/ngrok

Create a new file ~/.ngrok2/ngrok.yml with the content below. This is the configuration file Ngrok looks at to begin tunneling. If you want to protect access to the site you can add an auth option auth: "username:password" and this will protect your site via basic auth

authtoken: your-auth-token
tunnels:
  pi:
    proto: http
    addr: 80

Once we have Ngrok configured, we need to set it up to run as a service. This is so that we don't need to keep a terminal session running.

Create a new file lib/systemd/system/ngrok.service with root permissions.

[Unit]
Description=Ngrok
After=multi-user.target

[Service]
Type=simple
ExecStart=/etc/ngrok/ngrok start -config /home/ **yourusername** /.ngrok2/ngrok.yml --all
Restart=on-abort

[Install]
WantedBy=multi-user.target

To start the service

$ systemctl daemon-reload
$ sudo systemctl enable ngrok.service
$ sudo systemctl start ngrok.service

Navigate to http://127.0.0.1:4040/status and you should see the name of your ngrok domain.

If you do want to setup a custom domain, it is only available on a paid plan. Review the pricing and if you find it useful, choose the plan that best suits you.

Navigate to the URL you obtained from the dashboard. Congratulations! You now have a public web server on a Raspberry Pi.