1. GitHub workflow according to Google
Golosova Marina

2. Git after Subversion: unsafe history
Subversion stores commit history as it was written originally. Once committed – lasts forever. Good for credibility, pain for perfectionism.
In Git the commit history can be rewritten or removed – and not only locally, but also in the central (remote) repository. Good for perfectionism, dangerous for associates.
Unstable history is the main reason why GitHub is not friendly to the commit notifications by git push != svn commit == merged pull request

3. Workflow v

4. Workflow (1) Original Fork Local push push push push
Request accepted and merged
GitHub: pull request
6.1
6.5
Stable Branch (readonly)
Changes required
MyChanges2
Original
git pull upstream
or git pull
6.1
6.2
1.1
GitHub: fork
git push –u origin MyChanges2 5 7
push
Stable Branch (writable copy)
MyChanges Draft
MyChanges1
Fork
push
push
push
git push --force
1.2 8 5
Working (draft) Branch (+N commits)
Working (fair) Branch (rebase -i)
6.4
Working (fair) Branch (rebase -i)
Stable Branch (local copy)
Local
4.1 2
git clone <fork> git remote add upstream <original> or
git clone <original>
<commitA>
4.1
git branch new-branch
git checkout new-branch or
git checkout –b new-branch
git commit // <commitB>
git commit // <commitC> …
git commit // <commitX>
git checkout –b fair-branch1
git rebase –i <commitA>
pick <commitA>
edit <commitB>
drop <commitC>
pick <commitD>
squash <commitE>
fixup <commitF> …
git checkout –b fair-branch2
git rebase –i <commitA>
drop <commitA>
drop <commitB>
pick <commitC>
drop <commitD>
drop <commitE>
drop <commitF> …
git commit …
[git rebase -i]
6.3 3
4.2
4.2

5. Workflow (2) Create local copy:
Fork (via GitHub) (optionaly)
Clone (locally)
Add upstream (for fork)
Create a working branch for your changes see: why not to work in the “original” branch, Slide 14
Commit your changes locally see: when to push your changes to GitHub, Slide 15
Make-up the commit history
Create a new “fair” branch if there are more changes in the working branch than needed for one pull request if you’re going to keep on working in the branch after the pull request is sent
Use rebase –i to rewrite the commit history
Push the “fair” branch to GitHub

6. Workflow (3) Pull request Create request via GitHub
If the reviewer ask you for changes:
go the local “fair” branch
make changes required
rewrite the history (if needed)
push new commits to GitHub (use --force, if the previously pushed part of the history was changed) …
Request is accepted and merged to the stable branch:
Rebase + merge (fast-forward merge) for obvious cases (when there were no changes in the branch in parallel to the request
Merge (with merge commit) when fast-forward is not applicable without rebase
Squash (???) is not an option
Remove the remote request branch (at least in the original repository)

7. Workflow (4) Update local copy Update fork repository
git pull [upstream (for fork case)]
Update fork repository
git push

8. Git Keywords

9. Keywords
Pull – take (fetch) actual version from remote repository and merge local changes with it
Push – put local commits to remote repository
Push --force – overwrite remote history and current state with local version. To be used only in personal temporary branches (like those for pull request).
Pull request – “I have some good commits here, please add (pull) them to the stable branch”
Original / central repository – PanDAWMS/dkb
Fork repository – mgolosova/dkb (copy of the PanDAWMS/dkb on the GitHub side)

10. Keywords: rebase
Rebase {<commit> | <branch>} – rewrite the history (reapply commits on top of another base tip)
HEAD – “you-are-here”, last commit in the current branch
<commit>~<N> -- N commits earlier than <commit>
A---B---C topic /
D---E---F---G master
A'--B'--C' topic /
D---E---F---G master
git rebase master topic
o---o---o---o---o master \
o---o---o---o---o next
o---o---o topic
o---o---o---o---o master
| \
| o'--o'--o' topic \
o---o---o---o---o next
git rebase --onto master next topic
git rebase --onto topicA~5 topicA~3 topicA
E---F---G---H---I---J topicA
E---H'---I'---J' topicA

11. Keywords: rebase rebase –i <commit> Interactive rebase
Rewrite the history: reorder commits, drop them, edit, squash – whatever

12. Keywords: reset <=> Reset <commit> git reset --soft HEAD~1
set HEAD to <commit> (--soft)
remove changes between <commit> and last commit made before reset from index (--mixed) (default)
rewrite working directory to <commit> version (--hard)
git reset --soft HEAD~1
vi myFile.txt git add myFile.txt git commit
vi myFile.txt git add myFile.txt git commit --amend
<=>
More info:

13. Why & When

14. Why …(not) to fork the repository?
…not to work in a local copy of the original branch?
no merge problems when pull actual version from the original repository
there`s always a branch in the actual state to branch off of
less possibility to erroneously push to the original
…not to use push --force anywhere but your own working space (temporary commit branches, personal development branches, fork repository…)?
when the remote repository forcefully updated, the existing commit history can be rewritten
if your local copy is behind the remote version, you forceful update will erase someone else`s work (--force-with-lease helps here)
if someone has already pulled the previous history version and started to work on it, in the future the updated remote version might be harmful for the local changes
…(not) to fork the repository?
(+) less temporary branches in the original repository Lots of branches looks like a mess, but:
temporal working branches are to be removed after pull request (shall we use some prefix for them?)
pull request branches are to be removed after merge
human-related branches – our team is not so big to make it a problem
(-) extra work to keep the fork up to date (pull upstream + push to fork every now and then)
(-) no one can see if you`re working hard or do nothing without checking your fork version intentionally

15. When …to push to the remote repository? …to create a pull request?
work is finished
work is not finished, but you believe that a part of it is successfully done and want to “isolate” this part from the next one logically
you want to declare “I`m working on it, here`s the current state”
…to create a pull request?
work is not finished, but you want to ask someone for review and discuss your course (do not forget to add [WIP] (work in progress) marker (tag, or prefix to the request title))

16. That`s it