Course's Objectives            You can recognize how basic git workflow with local branches and remote branches work. Where to push, where to pull from. Hot to connect to master. You can save temporarily unstaged or uncommited changes in case you want to check immediately another branch or do something different. Additionally you can recover these changes and get them back when needed. You can bring new changes from another branch and add them to your own local branch without changing the order. Thus you have everything clean, all code from both branches, but your commits are on top of the others in your branch. Additionally you can tell the difference between merging a branch and rebasing a branch and when the latter is better option than the first. You can bring a specific commit by hash from another branch to your local branch and put this commit on top of your branch. Thus you have also code from a specific commit of a colleague to your branch and you can work with. Additionally you can tell the difference between cherry-picking and rebasing.

Diagram above shows git workflow as it should be at a simple professional form.

The flowchart above represents a normal git workflow. In the middle with the blue color you can see the  master branch that has already 4 commits to its history at the beginning. Then 2 colleagues decide to split up and take over one part of a new feature each. Thus we can see that 2 branches were created. At some point the green branch has finished first on it's local computer, merged to local master and pushed by updating the remote master.   Question:  Now that green branch has fulfilled it's purpose, and the red branch is still in use, how can the man who works on the red branch and has already made 4 local commits, fetch the new changes from the remote master and merge them to it's own branch, but by keeping his own commits also on top?

The answer is git rebase! Supposedly that the man who works on the red branch has already made 4 commits locally. Suddenly the colleague who was working on the green branch informs him that he has updated the remote master by pushing his changes there and that he should check the new changes out now.  In case you are the man who works on the red branch, the first thing to do is go and checkout the master branch and then pull from the remote master (git pull origin master). If you have uncommited or even unstaged files then git prevents you from going out of your current branch until you commit them or discard them. The most usual hack here is to temporarily save them to memory by applying git stash. Then you are free to go to master. Once you pull from origin master and your local master has your colleague's updates, it is time to think how are you going to introduce these changes from master into your branch. One way is to merge master into your branch, but what if you want to keep yours  on top, so the commits appear chronologically exactly as they happened?  You switch to your master. If everything is clean you proceed. If you have stashed files, then you need to unstash them now by git stash pop.  This action will make this files again available to your branch ready to be added and committed. When you commit and your working directory is clean and there is nothing to commit you can run git rebase master.  This will create a new commit on top of your local commits that will fetch and merge everything from master and then it will copy all your previous local commits up to this point that master does not have and will put them on top of it.  Attention: That means that it will recreate 4 new commits that are identical with the first ones but they have different hash (different commits).  If there are conflicts you resolve them manually in your editor. Then you add everything to staging area and then you type git rebase --continue.  That's it! Now you have all the changes that have been made by others locally to your branch and your commits on top of them. So when you feel ready the only thing you have to do is merge to your local master and then push to origin master.

Cherry Pick The diagram above describes the cherry picking procedure by taking the b2 commit specifically from the green branch and putting it on top of the red branch. Thus a new cherry pick commit is created that contains everything from C2 and B2 respectively. Conflicts have to be resolved in case they exist.  After the cherry pick the man who works on the red branch has all the differences that b2 offers.