push & pull options

$ git kata

Mateusz Grzechocińskihttp://grzechocinski.net

Other katas NOW (11:30) Katas NEXT (12:20)

Git rebase (Wojtek Erbetowski) Manipulating commits (Jakub Nabrdalik)

Submodules (Paweł Cesar Sanjuan Szklarz) Git flow (Michał Bareja)

Configs/aliases (Jakub Nabrdalik) Refspec (Mateusz Grzechociński)

Branches and tags (Mateusz Harasymczuk) Merging and rebasing (Mateusz Harasymczuk)

Git filter-branch (Grzegorz Kubiak) USB workflow (Łukasz Siwiński)

Rescue stash (Kamil Trzciński)

Undoing changes (Marcin Zajączkowski)

git fetch vs git pull

pull with fast forward=

no merge commit

pull without fast forward=

merge commit

What's better?

vs

http://walkingthestack.blogspot.com/2012/05/why-you-should-use-git-merge-no-ff-when.html

git pull --rebase

git config --global branch.autosetuprebase always

Only for NEW branches

$ git checkout feature/securityBranch feature/security set up to track remote branch feature/security from origin by rebasing.Switched to a new branch feature/security

git config <branch_name>.rebase = true

For EXISTING branches

What about pushes?

● Let's checkout remote "new_feature" as "security"

● git checkout -t origin/new_fature -b security

● Let's try to push to "new_feature"

git push origin security

First try...

WRONG

"If :<dst> is omitted, the same ref as <src> will be updated."

... so new branch 'security' is created :(

Second try...

git push origin

WTF ???

The special refspec : (or +: to allow non-fast-forward updates) directs git to push “matching” branches: for every

branch that exists on the local side, the remote side is updated if a branch of the same name already exists on

the remote side.

... so all other branches were pushed unintentionally :(

Third try...

git push

WRONG

Works like git push <remote>, where <remote> is the current branch’s remote (or origin, if no remote is

configured for the current branch).

... so same as with 'origin' :(

Fourth try...

git push github HEAD

WRONG

git push origin HEADA handy way to push the current branch to the same name on the remote.

... but HEAD is resolved as security :(

Finally... use refspec!

git push security:new-feature

OK :)

What's the default behavior?

"By default, git push origin will update branches on the destination with one with the same name on the source, instead of using the association defined by git branch --track, which git pull origin would use — the config option push.default can change this behaviour.”

http://longair.net/blog/2011/02/27/an-asymmetry-between-git-pull-and-git-push/

git config push.default

● nothing ● matching (default)● upstream● current

Introduced 4 years ago in commit:https://github.com/git/git/commit/521537476fe99b97bfcdf1b8f0c579061af5fd3e

What should be by default?

● simple (not default)"push to the upstream branch, but only if it has the same name remotely. If not, give an error that suggests the right command to push explicitely to'upstream' or 'current'."

Introduced in commit: http://goo.gl/je6gkAvailable since 1.7.11 (https://raw.github.com/git/git/master/Documentation/RelNotes/1.7.11.txt)

Ubuntu: [00:33:03] mgrzechocinski ~ git versiongit version 1.7.10.4

git push -u

● set tracking branch● set push branch$ git push origin -u topic/feature1Total 0 (delta 0), reused 0 (delta 0)To git@github.com:mgrzechocinski/gitkata.git * [new branch] topic/feature1 -> topic/feature1Branch topic/feature1 set up to track remote branch topic/feature1 from origin by rebasing.

$ git pushCurrent branch topic/feature1 is up to date.$ git pullCurrent branch topic/feature1 is up to date.

Manipulating commits (Jakub Nabrdalik)

Git flow (Michał Bareja)

Refspec (Mateusz Grzechociński)

Merging and rebasing (Mateusz Harasymczuk)

USB workflow (Łukasz Siwiński)

Rescue stash (Kamil Trzciński)

Undoing changes (Marcin Zajączkowski)

Next katas

Mateusz Grzechocińskihttp://grzechocinski.net