Advanced GIT tutorial - Cherry-pick vs rebase vs merge

One of the most important features of GIT is branching. The development of multiple functionalities can be done parallel, independently of each other.
In the end of course a version will be needed which includes functionalities from multiple branches. The article is a brief overview on the methods about how you can create such a version.

Overview on GIT branches

In GIT every commit knows its parent. So the list of your GIT commits is a one-way linked list, representing the order of the commits. By default you are working on a branch named master. A branch is always stored as a simple hash id, which is the hash id of the latest commit on the branch. You can anytime start a new branch based on the current HEAD commit by the command git branch branch_name. This command creates a new branch, pointing to the current commit. Then you can change to this branch by git checkout branch_name. This will change your HEAD to your branch. Or you can do these steps together by typing git checkout -b branch_name.
On a branch you can work independently from the master branch. You can implement a new functionality, fix a bug or do some refactoring. In the meanwhile others are working on the master branch or on some other branches. Until you are working on your functionality new functionalities will be added to the master branch. At this point you have to create a version which has all the content of the current master plus your changes from your branch. There are three ways to do it. Let’s see the details.


The first, very classical way is git merge. While being on master branch (you can always check your current branch by typing git branch) type git merge your_branch. This command will create a new merge commit to the master branch.
What is a merge commit?
In GIT every commit has one single parent commit, except merge commits which have two or even more parents. The command git merge master creates a merge commit with two parents: the last commit of your branch and the last commit of master. So that by checking out this commit you will have both the changes on the master and on your branch.  During merging conflicts can appear if the same lines have been modified on the two branches. In this case these conflicts have to be manually resolved.
Before merging always make sure that your branches are up to date with the remote branch.
The big advantage of git merge is that the history of the commit stays clear and unchanged.
The disadvantage is that large amount of merge commits can make the branch history unreadable.


The second option is git rebase. Git rebase is changing the parent of the first commit on your branch. So git rebase master will change the parent of the first commit of your branch to the latest commit on the master branch.
To be able to do it all commits on the branch needs to be modified, because in this way they will contain the change being done on the master. Since you are changing the commits, their hash id will also change. So technically they will be new commits. That also means that multiple instances of the same commit (rebased and non-rebased) can appear in the git log. You really have to pay attention!
Furthermore git rebase is being done commit by commit, so the same conflicts can appear again and again.
The advantage of this method is that your history will stay one straight line, on the other hand it won’t be possible to figure out later, that a git rebase happened.
You should especially pay attention to rebasing if multiple developers are working on the same branch.


Git cherry-pick is the best command if you want to move only one (or some) commit from different branches to the current branch.
For example you have a bugfix commit on one of your branches and you don’t want to merge the whole branch to the master, only the one commit which is fixing the bug. You should checkout the master branch and type git cherry-pick commit_id, where commit_id is the hash id of the bugfix branch. This command will create a new commit (with a new commit id) on the master branch, which has the very same changes as the cherry-picked commit. The cherry-picked commit will stay untouched.

Summary of merge, rebase and cherry-pick

To summarize the topic: git merge doesn’t change any existing commit, it just creates a new merge commit, which has two or more parents.
Git rebase changes the parent of the one commit (usually the root of the branch, or the commit given as a parameter). With other words it is rewriting the history of the branch (or commit). The commits get a new hash id.

Git cherry-pick reapplies one dedicated topic on the current branch, with a new commit id. The cherry-picked commit stays untouched.


How I became a certified scrum developer

Some weeks ago I attended a week long training session with the title “Certified scrum developer” (a.k.a LeSS in action), organized by the company Odd-e.
I regularly attend technical trainings in different fields, but I never wrote a blog post about them. Well, I wrote one with the title “How to do a proper technical training for developers”, but that post was the result of attending several trainings which I did not like.
This time the situation is different. I found this training really helpful and motivating. It had a clear effect on the way I'm thinking about agile software development, however there are still some points where I’m not absolutely convinced.
I’d like to summarize here what were the most important messages for me from this training.
And just to be honest: since the training I attended was not certified (even if its title was “Certified scrum developer”), I don’t have such a certificate, but it does not reduce the value of this training in my view.

The training

The training itself was very different from the trainings I attended before. The attendees have been split into four teams and each team had a workstation with huge monitors and computers (2-3 of such stations per team, each team had 5-6 members). Then during the week we simulated a sprint of working on a real product - an online game. We really worked day by day as teams in a large scaled scrum organization, and during these working days we had several sessions where we talked about dedicated topics. These sections were also reflecting on the situation in our sprint.
The first day was focusing on the refinement of the items. We did a nice refinement workshop, and we got a nice introduction into the methodology of specification by example and its connection to acceptance tests. We also did the sprint planning 1 where we decided on the items to be done by each team.
From the second day the teams really focused on the development. There was a CI system, which verified every new commit and notified all teams when something was broken. In this case one team  take over the “fix the build” responsibility. We were doing mob-programming, so usually 3 people were sitting in front of the same computer. There was a navigator of the mob session (who had the keyboard) and others who gave the instructions. The lead of the session has been changed regularly. We started every morning with a daily stand up and we evaluated the results of the day at the end of the day.
In case of any questions we were free to ask the product owner or even the customer. We also had to sync regularly with the other teams, since we had to touch the same code and implement similar functionality.
It was really exhausting, because the training was every day between 9 and 6 and it was really intensive. After the first day I almost lost my voice from speaking too much.
Although I've been working in a LeSS team for about a year (you can find my post about my first experiences and my later experiences part 1 and part 2), but this level of team work with continuous mob-programming was still something new for me.
The main topics of the sessions were: how to work in team and in pairs, how to do proper TDD, how to write good quality code, refactoring and how to do it, how does an agile organization look like, software architecture and design in agile development etc.
None of these topics were absolutely new for me, but they showed me these topics from a totally different perspective with very good practical examples, so I learned a lot.
Finally we closed the week with sprint review and a retrospective, where surprisingly most of the planned features worked properly.

The most important messages for me

First of all I have to clarify that I’m not a religious scrum believer. I started my career in an organization where we followed the classical V-model very strictly. There I have seen some advantages and a bit more disadvantages of that way of software development. Later on I worked in multiple projects which were following some kind of scrum organization, and as I have already mentioned, I'm currently working in a LeSS organization. Here I also see several advantages of the development process, but also some disadvantages. However, I have already realized that some of the disadvantages I observed were because of the wrong adaptation of scrum. So I think learning something new about agile development methodology can only help me. And to be honest this training helped a lot. Here I would mention some important points I learnt.

Proper way of specification by example

I already heard before about the idea of specification by example, but it was nice to apply it in practice. The high level idea is to describe concrete scenarios for your software with exact input and output data and use them as specification. To cover multiple cases (even the corner cases) you can organize the input values (and the expected output) into tables.
This way you can describe your requirements in a way which is well-readable by everyone, even for non-developers.
Additionally you can easily write automated tests based on these scenarios by using some acceptance test framework.

Taking a first bite

It is always a problem to refine and estimate tasks for topics which are absolutely new and unknown for the team. If we have no idea about the topic, how can we estimate it or how can we ask the right questions regarding the task?
The idea of taking a first bite is a solution for that. It means to first take something really small and easy from the topic, work on that and solve it. In the meanwhile you are becoming more familiar with the code base, so as a next step you can take over (and refine) a bit more complicated tasks with the same code. And keep on following this strategy until you are feeling comfortable with the code and topic.

How to do very proper TDD

TDD is a very popular buzzword nowadays. Basically the idea is to implement the code and the unit tests in parallel. But just like in the case of other popular buzzwords (SCRUM etc.) it is also pretty often misunderstood or misinterpreted.
The proper way of TDD is to always implement one test case (better to say, one check for your unit test), let it fail and then make it working in the code with the possible smallest change. Once it’s done you can do some refactoring to make your code nicer.
What is pretty strange for me is that you shouldn’t write more code than really needed. You really have to behave like you are being stupid.  For example if you are adding code where you know that you will have three different cases, you are not allowed to prepare your code for multiple cases as you are implementing the first one. It is absolutely against the way, how I usually work. I’m always thinking about what can be expected in the near future and implement my code to support these upcoming changes. It will still take some time to change this mindset.

The power of strong teamwork

I already realized before this training that teamwork is a really strong power. This training ensured me once again about this fact. I heard several times that pair programming is just a waste of resources, earlier I was not sure if it’s true or not, but now I’m sure that it’s not true. Simply the fact that we were doing mob programming all the time let us learn a lot and helped us to avoid making a lot of mistakes. And the flat communication channels also made it possible to detect issues in time.
However I have to mention that it is mentally really exhausting to work in such a way.

Software architecture in SCRUM/LeSS

There’s a really huge gap between the idea about software architecture in classical development models and agile models.
In case of classical development models software architecture is predefined, planned, well-documented and more or less static. Static in the sense that it should change as little as possible during the development.
In case of agile development there's usually a different practice. The architecture is not really planned, it just happens. It is just the actual state of the code and it is continuously changing. However there’s still a place to talk about the current architecture and to make architectural decisions.

The world is not always ideal

This was maybe the most important message for me.
The world is unfortunately not ideal. There are always issues which make it difficult to implement a proper scrum or to follow proper TDD. There can be thousands of reasons.
All these methods we learned about are working in an ideal world, but even if the situation is not optimal you should make the best of what is possible and try to optimize it.

Remaining open questions

There are some topics where I am still not totally convinced about scrum. Let's see those points.

How to apply scrum with less social developers

There are a lot of programmers who are not so good at communication and other social activities. For some of them that was the reason to become a programmer. But the world changed and soft skills became very important for developers. Especially in case of agile development models.
Of course these soft skills can be improved, but I think we can not expect wonder from developers who are not good at it at all.
I met a lot of developers who had very good technical knowledge, but they could not communicate with their team properly. What’s the future of these developers? How can they be integrated into Scrum teams?

Does it really make sense to avoid thinking about long term software architecture?

It is clear that software architecture is changing frequently together with the requirements. But there are  several cases when upcoming functionalities can be seen in advance. Does it really make sense to use a simpler solution and implement a more complicated one some sprints later if it is already known that the complicated one will be needed soon? At this point I’m still not totally convinced.

How to make sure that our unit testing is really done properly?

The way of TDD is to write test cases and to implement  related code and to keep doing it until we can not think about additional test cases. Well, but these test cases are really just up to us. How can we make sure that we really covered every corner case if our test cases are not connected to any kind of requirements? It is really easy to miss some points.

How to plan an agile project?

Well, agile projects are dynamic, flexible and open for changes.
However in case of projects the question is very often pretty simple from the customer: I need a software with this and this functionality: how long do you need to implement it and how much does it cost.
In case of classical project management both questions can be answered based on some estimations, however these estimations are not always proper.
But how to answer such questions in agiles modus?

Is pair programming always worth it?

I have already mentioned about the power of teamwork. One of the most common teamwork practices is pair programming. It really helps a lot, it makes the knowledge session much faster and it helps to improve the code quality. However there are tasks which are pretty easy, repetitive and even a bit boring and not challenging at all. I think there are such tasks in every big project. Is it really worth it to do pair programming for such tasks?

Final thoughts

I really liked the training. This was the most interactive training I have ever attended and I really appreciate it. From the content perspective it was nice to see a lot of things in practice, it helps much more than just reading about these topics.
It was really a pleasure to have hands-on experience with this way of working: strong teamwork, mob programming, TDD etc.
It was really active, so it is not possible to mention everything well-detailed in this post, but that was not my goal.

It clarified a lot of things for me, but I still did not become a religious scrum believer. I still see a lot of advantages of this working methodology, but it also has its own cons.


Difference between struct and class in C++

A really popular question of the C++ interview is about the difference between struct and class. It seems to be an easy question, but there are multiple views to be considered.

Historical background

Let’s start with the historical view. C++ is based on the programming language C, which is not supporting the object oriented programming paradigm. So that there were no classes in C, only structs. And struct was nothing else than a data structure to be used to store variables of different types together.
Later on with C++ together with the object oriented programming support the keyword class has been introduced to represent the typical object oriented classes.
In C++ Struct has also been extended with time, so it is also possible to inherit structs from each other, change the visibility of the attributes and to add constructors, destructors and member functions.

Technical difference

What is then the exact difference?
Technically there’s only one difference between structs and classes: in a struct the default visibility is public, since in a class the default visibility is private.
There’s technically no other difference in C++.

Practical difference

The difference is more philosophical.
As I already mentioned struct is a collection, a record of data, which belongs somehow together. And nothing more.
Since class is a bit more, class represents something, which has an interface, a state and a behavior. The state is usually internal, not visible from outside, that’s why the default visibility is private. The state can be changed through the predefined interfaces, which are the public methods of the class. Furthermore the usually the class has an invariant which is a restriction on its possible states. In case of a class you have methods which are handling the attributes of the class together.

So my suggestion is: use struct if you need a simple data container of data which belongs together and use class for everything what is more complex, what involves more abstraction.


You salary is less than it could be! - How to negotiate your salary at an interview?

Most of the companies handle the salaries as a secret and it has a cause. I am pretty sure that you have colleagues whose knowledge, experience and performance is worse than yours and they earn more and you. And there are of course colleagues who are better, but earning less. How to be part of the first group and earning more than the others?
Of course this question has a lot of factors. You can ask your boss for a raise. It is also important to change the companies at the right time. But where you can win the most is the negotiation during the interview process. To expertise your skills in this activity first you have to understand the view of the other participants.

The view of the company

If a company is hiring for a new position that means they have some work to be done, so they are looking for someone, who has the right skills to overtake the position with a possible short ramp-up time. Usually they have a clear view which skills are required to overtake the position. It is also important for them who is supporting them on long term, since a new change has a lot of extra cost and effort. And of course they are looking for the cheapest well-working solution. They are either hiring someone who is owning all the skills or someone who is lacking some of the necessary skills, but can be trained fast. Of course the one having all the right skills can achieve the highest salary, since there are no extra costs for trainings.
On the other hand, the company can only see from your skills what you are showing through the interview process. To be honest here you can present yourself a bit better as you are by concentrating on the skills which are really required for the position.
But in the end, the company has always a planned salary for the position, but usually it if defined in a range. If you have all the needed skills you can reach the maximum of this range. But unfortunately most of the cases this range is not public.

The view of the recruiter

Really often you have are first negotiating your salary with an external recruiter. The only goal for this recruiter to let you join the new company, since they are paid after the successfully hired candidates. So the recruiter can go to the company with some prepaid facts: there’s this guy, with these skills, expecting such amount of salary. As lower is the salary expectation, higher is the chance that the company applies you and the recruiter gets the success-bonus. That’s why the recruiters try to ensure you that your expectations are too high. They are often using phrases like “this is the realistic salary” etc. Don’t believe them. You have other ways to figure out what is your realistic salary.

Your realistic salary

It is very important for you to figure out what is your realistic salary. It is up to the company, up to the position, up to the city and up to your skills, that’s why it is not easy to find the right range. It makes it more difficult that in most countries salary is handled as a sensible information. People don’t like to talk about that.
Don’t use your current salary as a reference, it can be that you are really underpaid, but it is also possible that you are changing to a place where your responsibility is less, so that your current salary is not a realistic target. If you are changing the city that can make a really big difference on the realistic salary.
The first source you can use is the internet. There are websites, like glassdoor which can give you a good base, based on the inputs of the others. But in several cases it has simply not enough, or only obsolete inputs, so that it is not telling you a realistic value, especially if you are checking a smaller company or a smaller city.
It also worth to read to feedback about the company on different pages, like google maps, etc. Just google the name of the company and the city. You can find there often information which is comparing the salaries to other companies.
The most efficient way is to ask others who changed their jobs recently. Don’t ask them about their new salary, but ask them about what they think, what would be a realistic salary for you. It can also give you some guess.
Before you start to negotiate your salary, you should have a range in your mind about your realistic salary and don’t accept anything that is below this range.

How to negotiate your salary?

First of all you should show your best side during the recruitment process. Send a well-prepared CV with do your best on the interviews.
You will be might asked for your current salary. Just answer that it’s a personal info. Do not share it. Then you will be asked for expected salary. At this point you have to tell the higher limit of the range what you just determined, maybe a bit more. Most likely they will try to offer a bit less. If that amount is still in the determined range and it is not much less than the amount you told you can expect it. If it is much less or it is out of the range just tell, that sorry it is too less, then you rather search for something else. You may be asked for what is the lowest salary you would accept. Here you should tell a number which is just a bit below the first amount you asked.
During this whole process be patient, friendly but self-confident and very determined. You should show yourself strong and professional. Avoid answers like “let me think about this offer”. That would show weak and unconfident.
The most important point: if the company can’t give you an offer which is fulfilling your expectations, just keep on searching. That’s why it is good if you are not in a hurry at job searching. That makes you more confident.
It is always good to do 2-3 interview processes parallel, so that you can choose the best offer in the end.


To negotiate the highest-possible salary is not easy at all and the worst part is that you can never be sure that you reached the possible maximum. But it makes sense to take some time to negotiate. Because a higher starter salary makes an effect on your whole career at that company.


Introduction to UML

What are we doing as software developers? Nothing else than translating the language of humans into the language of computers. The language of the humans is any spoken language, like English and the language of the computer is binary code. There’s a huge distance between the two. To achieve this huge distance we have to introduce some middle stages. One well known middle stage is the programming language itself: no one writes binary code, everyone uses some programming language. From this step to compiler (or in some cases the interpreter) will transform you code into a low level language (like Assembly) and then into binary code. But there is still a huge distance between the spoken human language and the programming language, it is a good idea to introduce some additional middle steps.
There are several options for such middle steps, some of them are closer to the human language and others are closer to the programming language. Examples for this middle stage are: writing informal requirement specification, writing formal specification (like design by contract), specifying your program by examples or model your program by UML.

What is UML?

UML is an abbreviation of Unified Modeling language. The history of UML started in the mid of the 90's and today we are at version 2.4.1. It has several alternative versions and extensions, like SysML. UML is modelling by using different types of diagrams. UML is the way of representation. Later on based on your goals you can draw UML diagrams by hand on a table or on a white board, by using paint or by using a professional UML editor. There are several UML editor tools, some of them are free for use (ex.: Umbrello), others costs a lot (ex.: Enterprise Architect). Some of them are just like a specialized drawing tool, others are including a lot of features, like version control, connections between diagrams or even code generation on a certain level.
I also tried out several free UML tools and it was really challenging to find one which can save the diagrams as pictures in a proper way and which can draw all types of diagrams in the standardized way.
The UML diagrams are categorized into two big groups: structural (or static) diagrams, which are representing the static architecture of the software and behavioural (or dynamic) diagrams, which are representing how your software works in different situations.
Below I made a short introduction into the most popular UML diagram types.

Different sorts of diagrams

Structural diagrams

The first big group of diagrams describe the structure of your software.

Component diagram

A component diagram stands for modelling the high level architecture or your code.
It’s main elements are the following:
  • Components (ex.: User interface and Business logic on the diagram)
  • Ports of components: ports are marked by a small rectangle on the side of a component (see “Attributes” on the side of User interface called). They are an interface to other components, basically a collection of provided interfaces.
  • Provided interface: provided interface is represented by a circle connected to the component. These are basically the interface functions of the component which can be reached from outside.
  • Required interface: it is represented by a half-circle connected to the component. That means the the components requires an interface provided by another component. So that required and provided interfaces can be connected to each other.

Class diagram

The most frequently used UML diagram is the class diagram. It is representing the class hierarchy of your program or a part of your program.
Each class is represented by a rectangle, the name of the class is written on the top of the class. To represent interface classes an additional rectangle should be put on the top right corner.
After the name of the class there’s a section for the attributes (variables) of the class. The visibility of the attribute can be represented by a - (private) or + (public). Then comes the name, “:” mark and the type of the attribute.
The next section represents the operations (functions and methods) of the class.
In several cases the class diagram simple ignores the attributes and/or the operations and concentrates only on the connection of different classes.
The classes can be connected to each other in four different ways:
  • Composition: it is represented by a filled and rotated rectangle on the side of the class connected to a different class (like between Game and Table). It means that Table is part of the Game, it is a part of it. They lifetime is the same (they are created and destroyed at the same time). Practically it means that Game has a member variable of an instance of Table. Multiplicity can be added by adding numbers on the connection (if the game had multiple players), * means “any amount” of connections. An example of the real world: between a human and its head, there’s a composition: they have the same lifetime and the had can not be assigned to someone else.
  • Aggregation: it is represented by an unfilled and rotated rectangle on the side of the class connected to a different class (like between Game and Player). It means that the classes are connected to each other, but they lifetime can differ. It means the Game has a Player. But the lifetime of a Player and Game is different and the Player can be assigned to different games as well or even the Game can change its Player during the time. Multiplicity is the same as for composition. In the world of code it means Game has a pointer to a Player. From real life it means that between my clothes and me there’s an aggregation: I need clothes, but I’m changing them regularly and even the clothes can be worn by others.
  • Association: association is marked by a single line between two classes. (like Player and Table), or sometimes with a single arrow. It means that the classes are using each other, but not owning, like they have a local instance in one of the functions, or it is used as a function parameter or return value. It is like if I take the bus, then I am just using the bus, it is a typical case of association.
  • Generalization: generalization is represented by a triangle-ended arrow (like between Game and PausableGame). It means that Game is a generalized version of PausableGame or with other words PausableGame is a specialized version of Game. In the world of code it usually means inheritance. And as for example for the real world: Animal in a generalized version of dogs and cats.

Object diagram

Object diagram is not so popular as class diagram, but it can also be really useful in some cases. It is representing the state of the objects (instances of classes) of an object oriented program in one dedicated point of time. Each object is represented by a rectangle. In the top part of the rectangle there’s the name of the object (“player1”) : Type of the object (Player). Below that you can list the attributes of the objects with their actual value. The objects can be connected to each other (like game has two players and a table).

Deployment diagram

Deployment diagram is useful if your software is distributed on multiple different machines. You can add machines to the diagram (devices), like “Client machine” and “Server” on the picture and you can assign the software components to them which running on the given device.

Behavioural diagrams

The second big group of diagrams is the behavioural (dynamic) diagrams. Their purpose is to describe how the software behaves in different use cases.

Sequence diagram

The sequence diagram describes the communication between the different object or software components in a dedicated use case.
The above example describes a login procedure in case of a web portal.
The first element in the top left corner is an actor, which represents the user itself. The user calls the Login method (clicks on the login button). The event will be handled by the user interface. This is represented by a rectangle. Here it is also possible to add an object : Type pair. The dashed line below is the life time of the object/component. In this case the life time is the same for all components, but it could differ from each other. It is also possible to create on object later by a dedicated call or destroy it earlier. In this case the life time line should of course shorter.
As the next step the user interface is calling itself to check if the user name form is not empty. After this call there’s a big red rectangle with the tag “alt” in the top left corner. This represents that the part inside the rectangle will be only executed if the condition “user name is not empty” is true. Otherwise it won’t run. Instead of alt we could also use a loop.
So if the given username is not empty the User interface calls the Business logic.
The business logic calls the Database to check if the username and password pair is correct. Then the database returns with a value (dotted line) and the Business logic also returns with a value.
Of course a sequence diagram can be done in a more or less detailed way.

Activity diagram

The diagram type called activity diagram is maybe the easiest one, since it is nothing else then a well formulated flow chart. The filled circle is always the start point of our program/algorithm. The flow of the program or algorithm is represented by arrows. The rounded rectangle (like “Ask for a number”) represents an activity. And the diamond represents a decision (in this case if the given number is positive). From the decision start always multiple arrows, which are labeled by the result of the decision (here Yes or No). In some representation there is also a merge element which is also a diamond. A merge element has always multiple incoming line and only one which is started from that. In this case I missed this element and I connected it back directly to the action “Ask for a number”.
The last element to mention is the filled circle inside the unfilled circle which is always the endpoint of the program of algorithm. A program can have multiple endpoints.
So the above diagram represents a short program which is keep on asking for a number until the given number is not positive.

State diagram

The state diagram is used to represent state machines. The start point and end point is represented similarly as in the activity diagram. The transmissions are represented by arrows. The dedicated states of the program are marked with rounded rectangles. The state machine can also have multiple end points. It is also possible to have parallel states or add substates to an already existing state. The advantage of this representation of your program is that it’s giving a good, human readable overview and at the same time, it's easy to convert it into source code.
The above diagram means that at the start of the program is in a “Not logged in” state, by logging in we can change to the “Logged in” state, from that by logging out we can change back to the “Not logged in” state. From both state we can reach the end state of the program.

Use case diagram

The use case diagram is any light weight representation of the functionality or a part of the functionality of the program from the view of the user.
The so called actor is represented by a stick figure, in the case of this diagram we call it “User”. It is also possible to have multiple actors (like users with different permissions) and it can also be the case that the actor doesn’t represent a human, but another system using our program.
The functionalities which can be used are called use cases. They are represented by an ellipse and they can be connected by a line directly to the actor or they can be also connected to an other use case by specific connectors. In case of the example we have to main use cases: Login and Register.
The connectors between use cases can be the followings:
  • Generalization: it is very similar as in the case of class diagram, it is even represented in the same way. The general use case can have one or more specialized versions. Like in the example the use case “Login” has a specialized version “Login with Google account
  • Include: include connector means that one use case (functionality) is part of an other one. Like “Set a new password” is part of the functionality “Register”. It is represented by a dashed line with a label of <>.
  • Extend: Extend means that one use case is an extension of the other. For example the option of “Import personal data” is an extension of the use case “Register”. It is represented by a dashed line with a label of <>.
  • Precedes: One connector is missing from the example and this one is called precedes. By usage of precedes connector it is possible to define the order of the use cases. We could add a precedes connector between Register and Login, since to be able to log in first you have to register. It is represented by a dashed line with a label of <>.
Use case diagram is a perfect tool to represent the high level functionality of the program in a human readable way.


UML is a pretty strong tool to represent the software in a human readable format. It is a good basis also for technical discussions. However it should be considered that pretty often the same things are represented in different ways, since it is just semi-formal.

Advanced GIT tutorial - Cherry-pick vs rebase vs merge

Introduction One of the most important features of GIT is branching. The development of multiple functionalities can be done parallel, indep...