Gitkata push and_pull_options


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Gitkata push and_pull_options

  1. 1. $ git kata push & pull options 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) Mateusz Grzechociński
  2. 2. git fetch vs git pull
  3. 3. pull with fast forward = no merge commit
  4. 4. pull without fast forward = merge commit
  5. 5. Whats better? vs when.html
  6. 6. git pull --rebase
  7. 7. git config --global branch. autosetuprebase always Only for NEW branches
  8. 8. $ git checkout feature/securityBranch feature/security set up to track remotebranch feature/security from origin byrebasing.Switched to a new branch feature/security
  9. 9. git config <branch_name>. rebase = true For EXISTING branches
  10. 10. What about pushes?● Lets checkout remote "new_feature" as "security"● git checkout -t origin/new_fature -b security● Lets try to push to "new_feature"
  11. 11. First try... git push origin security
  12. 12. WRONG
  13. 13. "If :<dst> is omitted, the same ref as <src> will be updated." ... so new branch security is created :(
  14. 14. Second try... git push origin
  15. 15. WTF ???
  16. 16. The special refspec : (or +: to allow non-fast-forwardupdates) directs git to push “matching” branches: for every branch that exists on the local side, the remote side isupdated if a branch of the same name already exists on the remote side. ... so all other branches were pushed unintentionally :(
  17. 17. Third try... git push
  18. 18. WRONG
  19. 19. Works like git push <remote>, where <remote> is thecurrent branch’s remote (or origin, if no remote is configured for the current branch). ... so same as with origin :(
  20. 20. Fourth try... git push github HEAD
  21. 21. WRONG
  22. 22. git push origin HEAD A handy way to push the current branch to the same name on the remote.... but HEAD is resolved as security :(
  23. 23. Finally... use refspec!git push security:new-feature
  24. 24. OK :)
  25. 25. Whats the default behavior?"By default, git push origin will update branches on thedestination 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 optionpush.default can change this behaviour.”
  26. 26. git config push.default● nothing● matching (default)● upstream● currentIntroduced 4 years ago in commit:
  27. 27. What should be by default?● simple (not default)"push to the upstream branch, but only if it has the same name remotely. Ifnot, give an error that suggests the right command to push explicitely toupstream or current."Introduced in commit: since 1.7.11 ([00:33:03] mgrzechocinski ~ git versiongit version
  28. 28. git push -u● set tracking branch● set push branch$ git push origin -u topic/feature1Total 0 (delta 0), reused 0 (delta 0)To * [new branch] topic/feature1 -> topic/feature1Branch topic/feature1 set up to track remote branchtopic/feature1 from origin by rebasing.$ git pushCurrent branch topic/feature1 is up to date.$ git pullCurrent branch topic/feature1 is up to date.
  29. 29. Next katasManipulating 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) Mateusz Grzechociński