Once you get the hang of the basics, it's time to dive in and start getting work done with git. In this session we will talk about branching strategies, staging your files, writing a good commit message and merge vs rebase. We will also touch on the topic of rewriting history - what it means, examples of doing it and when to avoid it at all costs.

1. WordCamp Norrköping August 28, 2015
Take the next step with git

2. OriginalAuthor/AwesomeProject MyGithubName/AwesomeProject
push
PathToMyRepo/AwesomeProject
pull
make
pull request
originupstream
the pull-request collaboration model

3. proposed by Vincent Driessen
 master and develop are long-lived branches
 feature-, release- and hotfix- branches gets
deleted when they are finished
 suitable for projects with traditional release
cycles and semantic versioning
git-flow

4. github flow
master
small-bugfix
awesome-feature
when deployment happens often
 master branch is always deployable
 all development happens in topic branches
 topic branches are verified before merging
 suitable for more agile environments with
shorter development cycles and regular
deployments

5. pull request is branch to branch
topic branches gets deleted after they are merged
work in topic branches - use pull requests
develop
initialize pull-request
my-feature →develop
my-feature

6. git log will show you the history
source: http://xkcd.com/1296/

7. write helpful commit messages
git commit -m “Fix login bug” Redirect user to the requested page after login
https://trello.com/path/to/relevant/card
Users were being redirected to the home page
after login. It is better to send them back to
the page they had originally requested before
they were redirected to the login form.
* Store requested path in a session variable
* Redirect to the stored location after
successfully logging in the user
vs

8. all the world is a stage
- first.php
- second.php*
- third.php
- assets
- first.js*
- second.css
- fourth.php
stagework commit
second.php
first.js
59ab5f84 Add awesome feature

9. add part of a file to the stage
[~/_gitrepos/wcnkpg2015] (develop *) $ git add -p
diff --git a/functions.php b/functions.php
index 3ccacf2..53a67e2 100644
--- a/functions.php
+++ b/functions.php
@@ -10,8 +10,32 @@
[big diff of all changes to the file]
Stage this hunk [y,n,q,a,d,/,s,e,?]? s
use ”git add -p” or ”git add --patch”

10. options
y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
/ - search for a hunk matching the given regex
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help

11. [~/_gitrepos/wcnkpg2015] (develop *+) $ git status
On branch develop
Changes to be committed:
(use “git reset HEAD <file>...” to unstage)
modified: functions.php
Changes not staged for commit:
(use “git add <file>...” to update what will be committed)
(use “git checkout -- <file>...” to discard changes in working directory)
modified: functions.php
[~/_gitrepos/wcnkpg2015] (develop *+) $ git commit
[develop 0337c46] Add theme setup scaffolding
1 file changed, 12 insertions(+)
[~/_gitrepos/wcnkpg2015] (develop *) $
review all changes staged for commit with
git status -v
or
git diff --staged

12. - first.php
- second.php*
- third.php
- assets
- first.js*
- second.css
- fourth.php
- fifth.php
- first.php
- second.php
- third.php
- assets
- first.js
- second.css
- fourth.php
- fifth.php
second.php
first.js
fifth.php
stage commit --amend
fifth.php
74c35a5f Add awesome feature
- first.php
- second.php*
- third.php
- assets
- first.js*
- second.css
- fourth.php
- fifth.php
stagework commit
second.php
first.js
second.php
first.js
59ab5f84 Add awesome feature
amend previous commit

13. the history has been changed
59ab5f84 Add awesome feature
74c35a5f Add awesome feature
before
after

14. rebase
develop
my-feature
master
develop
my-feature
git rebase develop
moves the base of the topic branch to develop
the commits are discarded and the patches
reapplied to the new branch, creating new commits

15. rebase vs merge
rebase
 use only on a short-lived local
topic branch
 makes the history cleaner
 will update your work to be
based on the latest upstream
development
merge
 when a branch has been shared
with other developers
 is non-destructive
 can make history harder to
follow if there are many merge
commits

16. summary
 choose and follow a branching strategy
 take advantage of the staging area
 be mindful of the history
 never rewrite history on shared branches

17. KARIN TALIGA
@_middlesister
�https://github.com/middlesister
invistruct.com
Thank you!