@rubytester presents.“A Tale of Git Push and Pull”or why my push is rejected…

Let’s say we have a ‘master’ branchwith two commitson remote repo called ‘gitlab’

Notice in git graph arrow points to parent commit.It shows where commit came from.

You want to clone it and make changes

$ git clone #=> makes a ‘copy’ of git repository Gitlab is ‘remote’. You are ‘local’

you cloned remote locally

you have a perfect copyat the time you cloned.

You make 2 new commits on top of a branch and you want to push it to ‘remote’

blue commits represent your workon your local repo. ‘remote’ does not know about it.

$ git pushyour changes are pushed to ‘remote’ gitlab

Gitlab and you are exact copiesexact clones again.

But you are not alone. There is always ‘them’, people on your team.

One of ‘them’ cloned gitlabat the same time that you cloned gitlab

And they make commits and want to push as well. But they don’t know that ‘remote’ has changed

2 commitsfrom ‘them’planted onthe same parent nodeyour commitsare planted on

Git rejects the push from ‘them’. ‘remote’ has changed because you pushed

Same parent node.Common ancestordivergent graphs

‘They’ can not push. ‘They’ must fetch the changes first and integrate… But what should happen if ‘they’ git pull ???

$ git fetch brings changes from remote

Default strategy is to merge on git pull. This creates a commit with ‘two parents’(merge or rebase here???)

Now ‘they’ can ‘git push’ to gitlab. And you can integrated by ‘git pull’ But waitthere is more…

They can ‘rebase’ on pull instead of merge. In this case ‘they’ replant 2 commits ‘as if’ they were based on diff parent

And when ‘they’ push there will not be any ‘merges’. Just one line-of-work. (no superficial merges)

$ git config –global pull.rebase true #=> you can set this as your strategy

Now when you pull you will have clean graph. The latest changes from ‘them’ are in your clone

Define Convention for team.rebase? Or merge?

‘Rebase’ when you pull from otherswhile developing a feature.

‘Merge’ when feature is done.

Avoid superficial ‘merges’

THE END@rubytester