There are two types of merges in Git: fast-forward and true merge. Fast-forward is the default type of merge. Fetch updates the local repository with changes from the upstream repository. Pull fetches changes and merges the current branch. Push publishes local branch changes to the upstream repository, performing an implicit fast-forward merge. Tags allow labeling specific commits, like releases.

1. Git Series. Episode 2
Merge. Upstream Commands. Tags
Mikhail Melnik, 2015

2. Merge
There are two types of merge:
fast-forward and “true merge”.

3. Fast-Forward

4. Fast-Forward

5. Fast-Forward

6. Fast-Forward
OR

7. True Merge

8. True Merge

9. True Merge

10. Merge Summary
There are two types of merge:
● fast-forward
● “true merge”

11. Merge Summary
There are two types of merge:
● fast-forward
● “true merge”
Fast-forward is the default.
Only when it fails, true merge is made.
Should be explicitly set for merge!

12. Pointers
Every local and remote branch
(master, origin/master, etc)
is just a pointer to certain commit that in turn
points to certain data snapshot.
The same thing for tags.
HEAD is special Git word that represents a pointer
to the current working tree state.

13. Upstreams
Upstream is a Git term describing the remote referenced object. For origin repo it means
source repository it was cloned from. For local branch it means referenced branch from
the remote repository.
You can watch these references using your favourite IDE or using a console Git command:
git branch -v
There are also Git aliases for it: @{upstream} or @{u}. It’s possible to use following syntax:
git fetch origin
git checkout production
git merge @{u} /* instead of ‘git merge origin/production’ */

14. Origin is an Alias
After we do “git clone” we get a local
copy of the remote repository that can be
referenced locally using certain alias.
“Origin” is an default alias, representing
repository if no other were set.
Similarly to it, “master” is the default
name for the first branch in the newly
created repository.

15. Origin is an Alias
All origin/* branches are not reachable
directly, so you cannot modify them.
Instead you have local branches that
were forked from one of the origin/*
branches that really are not branches on
the remote repository.
In fact, they are a remote branches copy
that exist in your repository clone.
And that repository clone has a reference
to the source repository.

16. Git Fetch
Fetch is a command for Git to update specified local repository with latest changes from its referenced upstream.

17. Git Fetch
Fetch is a command for Git to update specified local repository with latest changes from it’s referenced upstream.

18. Git Fetch
Fetch is a command for Git to update specified local repository with latest changes from it’s referenced upstream.

19. Git Pull
Pull is actually a combination of fetch and merge. Pull fetches the new data to your repository and merges your current
branch with it’s upstream.

20. Git Pull
Pull is actually a combination of fetch and merge. Pull fetches the new data to your repository and merges your current
branch with it’s upstream.

21. Git Pull
Pull is actually a combination of fetch and merge. Pull fetches the new data to your repository and merges your current
branch with it’s upstream.

22. Git Pull
Important thing for pull is
that it merges (updates with changes)
only the current branch you are on.
Don’t forget to update other branches
after switching to them!

23. Git Push
Push is a command for Git to publish commits, that were made on local branches to their upstreams. Publishing
changes does implicit fast-forward merge on the upstream repository.

24. Git Push
Push is a command for Git to publish commits, that were made on local branches to their upstreams. Publishing
changes does implicit fast-forward merge on the upstream repository.

25. Git Push
Push is a command for Git to publish commits, that were made on local branches to their upstreams. Publishing
changes does implicit fast-forward merge on the upstream repository.

26. Git Push
By default, Git publish changes
from all referenced branches.
Always explicitly specify the branch
what changes you want Git to publish.

27. And Be Careful of Force Push

28. And Be Careful of Force Push

29. And Be Careful of Force Push
Never use --force (-f) flag without specifying a certain branch name!
NEVER! Cause it may lead to data loss!

30. And Be Careful of Force Push
Whenever you do a force push
be sure
you shout a loud to your team about it.

31. Git Push
You can set default behaviour for push in the Git settings.

32. Git Push
There are a bunch of push.default politics you can chose from:
● nothing — do not push anything unless a refspec is explicitly given.
● current — push the current branch to update a branch with the same name on the receiving end.
● upstream — push the current branch to the branch whose changes are usually integrated into the current branch
(which is called @{upstream}).
● simple — works like upstream, but refuse to push if the upstream branch name is different.
● matching — push all branches having the same name on both ends.
Matching policy used to be the default until Git 2.0 came up.

33. Git Push
But I strongly recommend to be obvious and always set the branch name explicitly.

34. And Use the Tags
The simplest way to add new tag on current commit is
git tag v1.4
or
git tag -a v1.4 -m 'my version 1.4'
As it was said before in case of data/history loses
you can easily checkout your tag.
Of course if it wasn’t deleted by somebody :)

35. Links
Core Git sources:
1. Pro Git book
2. Git reference
3. Git magic
Step-by-step tutorials:
1. Nice online Git tutorial
2. Become a Git guru
Additional links:
1. Git visual reference
Feel free to mail me at mikhailimelnik@gmail.com.
Specific topics:
1. Git best practices
2. Upstream term discussion
3. Fast-forward problem