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

Take the next step with git

Embed Size (px)

Citation preview

WordCamp Norrköping August 28, 2015

Take the next step with git

OriginalAuthor/AwesomeProject MyGithubName/AwesomeProject

push

PathToMyRepo/AwesomeProject

pull

make pull request

originupstream

the pull-request collaboration model

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

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

pull request is branch to branch

topic branches gets deleted after they are merged

work in topic branches - use pull requests

develop

initialize pull-requestmy-feature → develop

my-feature

h

git log will show you the history

source: http://xkcd.com/1296/

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

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

add part of a file to the stage

[~/_gitrepos/wcnkpg2015] (develop *) $ git add -pdiff --git a/functions.php b/functions.phpindex 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”

options

y - stage this hunkn - do not stage this hunkq - quit; do not stage this hunk or any of the remaining onesa - stage this hunk and all later hunks in the filed - do not stage this hunk or any of the later hunks in the file/ - search for a hunk matching the given regexs - split the current hunk into smaller hunkse - manually edit the current hunk? - print help

[~/_gitrepos/wcnkpg2015] (develop *+) $ git statusOn branch developChanges 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

orgit diff --staged

! - " 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

the history has been changed

59ab5f84 Add awesome feature

74c35a5f Add awesome feature

before

after

rebase

develop

my-feature

master

develop

my-feature

git rebase develop

moves the base of the topic branch to developthe commits are discarded and the patches reapplied to the new branch, creating new commits

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

summary

choose and follow a branching strategy

take advantage of the staging area

be mindful of the history

never rewrite history on shared branches