It is important to keep each of commits to be as clear as possible - what is this commit about.
Sample
Let start with example repo where we have two issues open:
1. upgrade protractor library (technically to change version num in "package.json" file)
2. move some file from ES5 to the typescript
The common flow is that each bug/feature developed in its own branch and merged to the main "master" branch afterwards.
Lets say the issues where split between two team members - mr X:
and mrs Y.
Mr X created branch named upgrade-protractor wile miss Y created view2-to-typescript at the same time.
Since mr X's task was much easier - he finished before miss Y, and committed his work. According the flow, mr X should do pool request, after that his changes where merged into master.
Now , after miss Y will finish her work and commit - she will face problem to merge her changes into master since it had changed meanwhile.
Good Old Merge
The simple way to handle the problem is to do
git merge master
which will create special "merged" commit because of merge action:
Now the view2-to-typescript has the protractor version change inside it and can be merged into master.
The disadvantage of this way is that commits log has a commit with changes which have nothing to do with the typescript task
Thats Where Rebase Came To Play
The nicer way to handle the merger-to-master problem is to do:
git rebase master
That way the history will be "rewritten" and only one commit with the relevant changes will appear in the commit log: