gitkata push and_pull_options
TRANSCRIPT
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 [email protected]: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