Git and GitHub for PHP Projects (PNWPHP 2015)

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 joind.in/14906
2. Do you even Git?
3. VCS version control system
4. FTPVCS FTP "version control system"
5. ( TELNETVCS, SSHVCS, Wordpress File Editor
6. Proper VCS
7. control and track source code changes over time
8. me.
9. RCS revision control system
10. shocked.
11. limited to single files but still very cool
12. CVS concurrent versions system
13. yay! multiple files, remote access, deltas
14. boo! binary files & directories
15. Subversion
16. They didn't want to break new ground in version control methodology, they just wanted to fix CVS. — Subversion's History
17. It was a big step up!
18. 2001 through 2010?
19. True atomic commits!
20. Branches!
21. History for renamed, copied, and (re)moved files!
22. History for symlinks!
23. History for directory metadata and renaming!
24. Client/server protocol! Communicated via diffs!
25. One True Repository™
26. Git
27. DVCS distributed version control system
28. Every working directory is a full- fledged repository
29. No need for a central server
30. Branching is very light
31. I finally did it and stopped talking about it. — Me, March 10th, 2010
32. 2010 - now
33. The first few month transitioning between subversion and git were easily some of the most frustrating months I've spent as a developer.
34. It has totally been worth the investment.
35. 33.3% of professional software developers report Git as their primary source control system — Eclipse Foundation Community Report, May 2014
36. 42.9% if you include those that reported GitHub as their primary source control system — Eclipse Foundation Community Report, May 2014
37. GitHub
38. Web-based repository hosting service
39. Git++
40. Makes it easier than ever to collaborate
41. It also makes Git more complicated for newbies (if that is even possible)
42. Marketing by Extending and Overloading the Language
43. Fork git clone
44. Pull Request git request-pull similar concept, different implementation (not to mention Linus-rage inducing)
45. Git
46. repository
47. git init
49. git commit
53. Branches
61. Relative Addressing
66. Creating a new branch (checkout)
74. Changing History (removing a commit)
82. What about merges? How do those work? What abou–
83. Gemma Anible Navigating Your Git Repository Saturday at 3:30pm
84. Working Directory and Staging Area
85. Working Directory Where you work on your code
86. Staging Area Where code you've changed goes until it has been committed
88. 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"
89. Patch Mode Stage parts of modified files for commit git add -p
90. Git Status Your best friend
91. Git Diff Your next best friend
92. git diff Shows changes that only exist in your working directory
93. git diff --cached Shows changes that are staged and ready to be committed
94. Local Git Single Repository Totally legit.
95. git init # You never have to share this with # anyone but you can totally use # this Git repository for # amazingness.
96. Local Git Cloned local repository
97. git clone /path/to/repo my-clone # Now my-clone is a clone of some random # local Git repository at /path/to/repo.
98. 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.
99. Remote Git
100. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. — 2.5 Git Basics - Working with Remotes
101. 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.
102. origin initially the name of the remote that was cloned
105. GitHub
106. What's a fork?
107. 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.
108. Forks exist to facilitate web-based Pull Request functionality.
113. TMTOWTDI
114. Start with a simple set of rules and expand as needed and as comfort level allows.
115. Rename Remotes
116. 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.
117. Fork the repository and add your fork as a remote with your name for the remote
118. 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."
119. Keeping Everything In Sync
122. git clone
129. Fetch
130. # 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`.
131. # 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.
132. Emma Jane Hogbin Westby http://gitforteams.com/resources/merge-rebase.html
133. Push
134. # 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
135. 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.
136. How do I delete a remote branch?
137. Remember this one? git push [remote] [local-branch-name]:[remote-branch-name]
138. git push [remote] :[remote-branch-name]
139. git push monii :my-feature # Deletes the `my-feature` branch from the `monii` # remote by pushing *nothing* to the branch.
140. My Workflow
146. REJECTED If you are publishing code to a shared environment
147. git push monii my-feature # REJECTED git remote update git rebase monii/my-feature git push -f 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.
148. REJECTED If you are publishing code to a non-shared environment
149. 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.
150. Pull Request
151. A Pull Request represents a branch on your fork that has commits unique to your branch when compared to another GitHub hosted repository.
152. Continuing to work on a Pull Request (by adding, removing, or updating commits) is as easy as pushing those changes to your fork again.
153. Create a new branch for each Pull Request
154. My Process Review & Philosphy
155. Consistency and Limited Variation
156. 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.
157. 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.
158. 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.
159. 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.
160. 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.
161. Visit GitHub to create the Pull Request
162. 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 push simensen -f #
163. Your fork will not stay updated automatically So you can expect your master to stay hopelessly out of date.
164. Branching Models
165. Git Flow http://nvie.com/posts/a-successful-git-branching-model/
166. Contributing
167. CONTRIBUTING.md
168. Don't just assume master is where code goes Though it is probably a safe bet
169. LIVE
171. Thanks! beau.io • @beausimensen monii.io • @moniidev thatpodcast.io • @thatpodcast joind.in/14906