Git and GitHub for PHP Projects (PHPNW15)

Thanks largely to Composer and its tight integration with GitHub, it has never been easier for people to share and contribute to the PHP ecosystem. These days, it more or less required that contributors have a working knowledge of Git and GitHub to be effective. Thankfully, learning how to use Git and GitHub doesn't have to be scary. Whether you're new to Git, still using Subversion, or don't have any experience with version control systems, this workshop will get you started using Git and GitHub so that you can start contributing back to your favorite PHP projects!

Transcript

1. Git and GitHub for PHP Projects Beau Simensen @beausimensen joind.in/15421
2. FIRE DRILL 15:00 Remember! If it lasts longer than 60 seconds, it isn't a drill. :) Break at 15:30
3. Do you even Git?
4. VCS version control system
5. FTPVCS FTP "version control system"
6. ( TELNETVCS, SSHVCS, Wordpress File Editor VCS)
7. Proper VCS
8. control and track source code changes over time
9. me.
10. RCS revision control system
11. shocked.
12. limited to single files but still very cool
13. CVS concurrent versions system
14. yay! multiple files, remote access, deltas
15. boo! binary files & directories
16. Subversion
17. They didn't want to break new ground in version control methodology, they just wanted to fix CVS. — Subversion's History
18. It was a big step up!
19. 2001 through 2010?
20. True atomic commits!
21. Branches!
22. History for renamed, copied, and (re)moved files!
23. History for symlinks!
24. History for directory metadata and renaming!
25. Client/server protocol! Communicated via diffs!
26. One True Repository™
27. Git
28. DVCS distributed version control system
29. Every working directory is a full-fledged repository
30. No need for a central server
31. Branching is very light
32. I finally did it and stopped talking about it. — Me, March 10th, 2010
33. 2010 - now
34. The first few month transitioning between subversion and git were easily some of the most frustrating months I've spent as a developer.
35. It has totally been worth the investment.
36. 33.3% of professional software developers report Git as their primary source control system — Eclipse Foundation Community Report, May 2014
37. 42.9% if you include those that reported GitHub as their primary source control system — Eclipse Foundation Community Report, May 2014
38. GitHub
39. Web-based repository hosting service
40. Git++
41. Makes it easier than ever to collaborate
42. It also makes Git more complicated for newbies (if that is even possible)
43. Marketing by Extending and Overloading the Language
44. Fork git clone
45. Pull Request git request-pull similar concept, different implementation (not to mention Linus-rage inducing)
46. Git
47. repository
48. git init
50. git commit
54. Branches
62. Relative Addressing
67. Creating a new branch (checkout)
75. Changing History (removing a commit)
83. What about merges? How do those work? What abou–
84. Gemma Anible Navigating Your Git Repository Openwest 2015 https://www.youtube.com/watch?v=kAGca33IVmY
85. Working Directory and Staging Area
86. Working Directory Where you work on your code
87. Staging Area Where code you've changed goes until it has been committed
89. echo "Hello World" > file.txt git add file.txt # file.txt staged with "Hello World" echo "Goodbye World" > file.txt # file.txt staged: Hello World # file.txt modified: Goodbye World git commit # commits staged changes; "Hello World" git add file.txt # file.txt staged with "Goodbye World" git commit # commits staged changes; "Goodbye World"
90. Patch Mode Stage parts of modified files for commit git add -p
91. Git Status Your best friend
92. Git Diff Your next best friend
93. git diff Shows changes that only exist in your working directory
94. git diff --cached Shows changes that are staged and ready to be committed
95. Local Git Single Repository Totally legit.
96. git init # You never have to share this with # anyone but you can totally use # this Git repository for # amazingness.
97. Local Git Cloned local repository
98. git clone /path/to/repo my-clone # Now my-clone is a clone of some random # local Git repository at /path/to/repo.
99. Local Git: The Point Git does not have to be a network-only sort of thing. It can be used quite effectively in an isolated or local-only environment.
100. Remote Git
101. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. — 2.5 Git Basics - Working with Remotes
102. Remote repositories are Git repositories external to any given Git repository. If you run git clone, the repository you clone is considered the origin remote, even if that repository was a local repository. — Beau Simensen, now.
103. origin initially the name of the remote that was cloned
106. GitHub
107. What's a fork?
108. fork [fawrk] noun 1. Fancy marketing term for a remotely hosted clone of another remotely hosted repository with some invisible metadata that magically binds them together.
109. Forks exist to facilitate web-based Pull Request functionality.
114. TMTOWTDI
115. Start with a simple set of rules and expand as needed and as comfort level allows.
116. Rename Remotes
117. git@github.com:monii/monii-nimble-framework.git cd monii-nimble-framework git remote rename origin monii # Now you have cloned the original repository # and have renamed origin to monii, the # name of the repository owner.
118. Fork the repository and add your fork as a remote with your name for the remote name
119. git remote add simensen git@github.com:simensen/monii-nimble-framework.git # Now my fork is available as a remote in my # local clone! I can now reference either # the actual project using "monii" or # my fork using "simensen."
120. Keeping Everything In Sync
123. git clone
130. Fetch
131. # Fetch all remotes git fetch --all git remote update # I use `git remote update` because of habit # and I already use the remote command # quite a bit managing my remotes # so it flows more nicely. # I never have a reason to run `git fetch --all`.
132. # Fetch changes from monii and then merge # changes from monii/master. git fetch monii && git merge monii/master git pull monii/master git remote update && git rebase monii/master # Some may argue that rebase is bad here and # under certain circumstances it may not be # ideal. However, I find it to be well # worth the risk/potential problems.
133. Emma Jane Hogbin Westby http://gitforteams.com/resources/merge- rebase.html
134. Push
135. # Push the changes to the local # `my-local-feature` branch to # the `my-feature` branch of # the `monii` remote. git push monii my-local-feature:my-feature # [local-branch-name]:[remote-branch-name] # If currently checked out branch # is `my-feature`, and you wish # to push to `my-feature` on # the remote, the branch can # be specified once. git push monii my-local-feature
136. git push -u monii feature git push # Sets an upstream; some git commands, like # pull and push, will now default to this # remote if a remote is not specified. # Nice but can lead to you making assumptions. # It may be nice to just be explicit when # making every command in the beginning.
137. How do I delete a remote branch?
138. Remember this one? git push [remote] [local-branch-name]:[remote-branch-name]
139. git push [remote] :[remote-branch-
140. git push monii :my-feature # Deletes the `my-feature` branch from the `monii` # remote by pushing *nothing* to the branch.
141. My Workflow
147. REJECTED If you are publishing code to a shared environment
148. git push monii my-feature # REJECTED git remote update git rebase monii/my-feature git push monii my-feature # The rebase will change code that has already been # published to my fork. Git will reject this as # it cannot be automatically resolved easily. # Force pushing results in completely # replacing the branch that was # already published.
149. REJECTED If you are publishing code to a non-shared environment
150. git push simensen my-feature # REJECTED git push -f simensen my-feature # If you're the only one working on a branch or your # branch is otherwise not shared you can just # force push. Think hard, though. Always # ask yourself, "is it possible that # someone is already basing code # off of this branch?" # Most often happens in teams where everyone is # working off of the same shared repository # and not contributing via personal forks.
151. Pull Request
152. A Pull Request represents a branch on your fork that has commits unique to your branch when compared to another GitHub hosted repository.
153. Continuing to work on a Pull Request (by adding, removing, or updating commits) is as easy as pushing those changes to your fork again.
154. Create a new branch for each Pull Request
155. My Process Review & Philosphy
156. Consistency and Limited Variation
157. git clone git@github.com:monii/monii-nimble-framework.git cd monii-nimble-framework git remote rename origin monii # Clone the actual project's repository first and # then rename the `origin` remote to the name # of the GitHub user that owns the project.
158. git remote add simensen git@github.com:simensen/monii-nimble-framework.git # Create a fork of the project under your GitHub account. # Add a remote with the name of your GitHub user and # give it the URL of your forked repository. # You now have two remotes, one with the name of the # project and one with your own name. Using these # names explicitly will help you always know # where you are fetching changes from and # where you are pushing changes to.
159. git remote update git checkout -b my-feature monii/master # I almost always try to run `git remote update` # when creating a new branch so my branch # starts out with recentish code. # Specifying the remote/branch also ensures I # am basing my new branch off of actual new # code in case my local `master` has not # been rebased in awhile.
160. git remote update git rebase monii/master # Rebase often, especially if your branch is going # to be around for awhile. This ensures you will # find conflicts earlier than you might # otherwise find them.
161. git push -u simensen my-feature # After some commits are made, push the branch # to your own fork by specifying your GitHub # username as the remote you are going # to be pushing to.
162. Visit GitHub to create the Pull Request
163. git push simensen # After any additional commits are made, push # the branch to your own fork by specifying # your GitHub username as the remote you # are going to be pushing to. # If rejected, rebase and force push! # # git remote update # git rebase simensen/my-feature # git push simensen -f #
164. Your fork will not stay updated automatically So you can expect your master to stay hopelessly out of date.
165. Branching Models
166. Git Flow http://nvie.com/posts/a-successful-git-branching-model/
167. Contributing
168. CONTRIBUTING.md
169. Don't just assume master is where code goes Though it is probably a safe bet
170. LIVE
172. Thanks! beau.io • @beausimensen monii.io • @moniidev thatpodcast.io • @thatpodcast joind.in/15421