Git for TFS users - a cheat sheet

It was tough.

When I started to use Git, because now nearby everybody is using Git, it was tough. Really tough.
Imagine transition from Visual Studio 2015 & TFS to Eclipse, Jira, Jenkins, Gerrit and Git (command line).

What I saw was that there are developers which have no other experience than Git. And Gerrit, And Jira. And Jenkins.
So those were satisfied.
I was not.

But another project arrived, with Jira, Jenkins, GitLab, Artifactory and ... with msbuild and Visual Studio 2015, and I was not lost :-)
So today I can say it is good to have experience with multiple development environments.

But to simplify start for TFS/Visual Studio developers, which are trying to use Git, I prepared a presentation and this "cheat sheet" which is improved version of this one.

TFS Version Control	Git
Workspace	Repository (aka. “Repo”)
Get Latest  (First time)	Clone
Get Latest (After first time)	Pull
Check in	Commit + Push
Check out	There is no lock ! no checkout !
Branch	Branch
Merge	Merge
Shelve	Stash - just local ! (on local machine ...)
Label	Tag
Included changes	Staged
Excluded changes	not staged

Also you can check may previous post about three common "scenarios" which are used in Git environments for "check-out - check-in"

Git: How to commit and merge

Hi,
I'm using Git just one year, and in second team, so here are three "algorithms" or "patterns" which I recognized yet:

1. Git+Gerrit+Jira, branch, commit --amend, upload

• create branch per Jira item  
• develop code
• try to pull
• solve merge conflicts
• commit
• upload (push + upload to gerrit )
• ... wait for gerrit review ...
• change code (regarding gerrit review)
• try to pull
• solve merge commits
• commit --amend (rewrite your commit - be careful )
• upload
• ...

This is probably good solution for big projects with long term gerrit review process ...

2. Git+Gitlab, master, stash, merge, push

Probable suitable just for not so big project (lines/changes/developers)
Just one branch used locally.

• You will change code.
• When there is something new on origin/master you will try to pull
• If it is impossible to pull, you will stash changes
• pull
• stash apply - solve merge conflicts 
• continue if needed
• push ( no review before push)

3. Git+Gitlab, master, commit, merge, push

The same as above but stash is not used, just commit and push.
But then merge commits will appears.

Probable suitable just for not so big project (lines/changes/developers)
Just one branch used locally.

• You will change code.
• When there is something new on origin/master you will try to pull
• If is impossible to pull, you will commit changes
• pull
• solve merge conflicts 
• continue if needed
• push ( no review before push)

Any other ideas ?