Git view files in another branch without checkout

If you like to view a file in another branch without (without checking it out) you can do this:

git show branch:file

So if you are in a branch called Feature_fancy and there is a file called fancy_controller.js:

git show Feature_fancy:fancy_controller.js

This will show the content of the file without having to check out this branch.

Git remove untracked files

If you have bunch of untracked files that you haven’t staged and they are sitting around, you can clean them all in once. While running git clean you have 3 options.

-n option does a dry run and shows you which files will be removed.

#git clean -n

-i option asks you interactively what to do:

#git clean -i

The last option is with -f option which forces removal of the unstaged files.

#git clean -f

That is about it.

Git Amend your last commit

Git has great features. One of them is to amend your previous commit. If you left something out on your last commit which can a file, or a change in a file that you just committed. Git amend can easily fix your problem.

You need to stage your changes with git add first.

#git add .

Then commit it again with :

#git commit –amend

You can also use –m option to overwrite the previous commit message.

#git commit –amend -m “your new message”

Once you are done you can check the log with:

#git log –stat

Git amend is pretty useful to recover from incomplete commits.

Git Cherry-pick

In a recent project, release team is having lots of problems while going to deployment.

Scenario: There are set defects, and new features which are planned for a release cycle. However, not all of them can make it to production. In current situation the whole release is postponed or cancelled.

Or, you have a feature branch that isn’t ready for a full merge but you have some commits that you want to push to master.

Git cherry-pick to rescue.

From your feature branch, defect or any branch, copy the first six characters of  commit hash that you want to cherry-pick.

In order to with the commit hash you can use git log.

#git log –oneline

Now checkout the branch that you want to insert the commit onto such as master.

#git cherry-pick ad9381b

Now if you do a git log you will see your cherry-picked commit at the top of the history.

If you like to indicate that the commit is cherry picked you can use -x option so that message will contain cherry-pick information. You can see in your branch that this commit has been cherry-picked with something like following:

(cherry picked from commit 676aac131c1349ebd5610b270c470a33bddc7cb0)

Pay attention to cherry-picking a lot of commits out of order, the Git log will reflect the order in which you cherry-picked, not the chronological order of the original commits (The original commit date is preserved, however).

While cherry-picking is pretty handy, use with caution. Finally, I hope the image below can help you understand it better.

Circuit breakers

In my previous post, bulkheads, I mentioned that “Since the popularity of service oriented architectures and then microservices, people are talking about bulkheads and some other terms like circuit breakers, timeouts etc. However, I see that many lacks the understanding of what these terms really mean or how to implement them. I decided to cover some of them and wanted to start with Bulkheads.”. In this post I will briefly cover up Circuit breakers.

Not many years ago, people used to plug too many electronical appliances into their circuit, each appliance drew certain amount of current and when the current is resisted, it created so much head in the walls of the house and then the house burns down. Later on there were some optimizations but still houses on fire.

Circuit breakers come to rescue.

This idea can also be applied to software applications with integration points. A software with one or more integrations are destined to fail at any given time. This is a given. Circuit breakers can help prevent operations that is already known not to be healthy.

Circuit breakers are a way to degrade functionality when the system is under stress. Changes in the circuit breakers’ state should always be logged and monitored. Circuit breakers are effective at guarding against integration points, cascading failures, slow responses etc.

In a normal closed state, circuit breakers executes operations as usual. Other services can be invoked, internal operations can proceed. However if any operations fail, circuit breakers store this information, that is including any times. Once the number of failures exceeds a certain threshold, circuit breaker trips and opens the circuit. Any call made to the circuit breaker, it fails immediately.

This is very important, because most of the failures occurs  due to blocked threads, race conditions and dead locks. Hence, if a service is not responding or continuously timing out, what is the point of invoking it. All yours threads will be blocked and you will run out of them. Soon, your JVM or runtime will crash.

After a configurable amount of time, circuit breaker can go into half open state, in which calls can pass-through and if all goes well, circuit breaker closes. If things are still failing, circuit breakers opens again.

If circuit breaker is open, you can either let the user know something is not working and check back soon. Or you can have fallback services. The latter is much more better however services unfortunately can not have fallback due to their responsibility and function.

You can have multiple circuit breakers for different purposes such as timeouts, connections refused and other type of failures.

There are several tools that can help you implement circuit breakers in your system. Netflix has an open source project for this purpose called hystrix . You can check out it and see how things work.



Since the popularity of service oriented architectures and then microservices, people are talking about bulkheads and some other terms like circuit breakers, timeouts etc. However, I see that many lacks the understanding of what these terms really mean or how to implement them. I decided to cover some of them and wanted to start with Bulkheads.

This term comes from Ships. In a ship, bulkheads are partitions that can be sealed and closed during an emergency. Something like following:

If one of the compartment starts taking water, it can be sealed once hatches are closed which prevents the water moving from one compartment to another hence sinking the ship.

Same technique can be employed for software and architecture. By partitioning your system you can avoid cascading failures. Bulkheads can be applied to physical and application services in such a way that if one of the hardware or application fails, the system should continue functioning. Critical applications should be partitioned and bulkheads should be implemented.

Imagine you have an application A and application B. Then there is a critical common service called service C. This service is very critical for both apps. In a conventional architecture, the design is as follows:

The problem with this architecture is if Service C goes down for any reason both of the apps will be affected. So Bulkheads pattern recommends the following:

Deploying Service C for both of the Apps provides better stability for the apps. This can be simply independent hardware, application host or thread pool.  You can partition thread pool in an application by deploying to multiple virtual machine.

Today many application servers provide means to separate runtime environments for applications. You can deploy the same application under different context and assign seperate JVM or CLR to go with it.

Also today we have docker and several Virtualization software which makes implementing Bulkheads easily.


The notorious SSL Handshake

The notorious SSL handshake process happens as following.

  1. The client issues a secure session request.
  2. Server sends back x.509 certificate containing server’s public key.
  3. Client authenticates server’s certificate against list of known CAs (Certificate Authority). If the certificate is not in the list, user is prompt to accept the certificate.
  4. Client generates random symmetric key and encrypts it using server’s public key.
  5. Client and user now both have the symmetric key. Client send data using this symmetric key to the server during the session.

If you like to see it in action. Open up your Chrome tools. Browse to chrome://net-internals/#events

Then go a secure URL, something like . In the events log you will see the events for SSL handshaking.

If you browse through events, you will see the handshaking process.