GitHub

workflow
according to Google
Golosova Marina
 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 e-mail
git push != svn commit == merged pull request

01.06.2017 2/16
 Workflow
v.01.06.2017

01.06.2017 3/16
 Workflow (1)
Request accepted GitHub: pull request 6.1
and merged
6.5
Changes
Stable Branch git pull upstream required
Original (readonly) or git pull 6.1 MyChanges2
6.2
1.1 GitHub:
git push –u 5
fork 7
origin push
Stable Branch MyChanges MyChanges2
Fork (writable copy) Draft
MyChanges1

1.2 push 8 push 5 push git push --force

6.4
Working (draft) Working (fair) Working (fair)
Stable Branch 4.1
Local (local copy) 2
Branch Branch Branch
(+N commits) (rebase -i) (rebase -i)
<commitA> 4.1
git clone <fork>
git remote git branch new-branch git checkout –b fair-branch1 git checkout –b fair-branch2
add upstream <original> git checkout new-branch git rebase –i <commitA> git rebase –i <commitA>
or or
git clone <original> git checkout –b new-branch pick <commitA> …
git commit
drop <commitA>
edit <commitB> [git rebase -i] drop <commitB>
git commit // <commitB> drop <commitC> pick <commitC>
git commit // <commitC> pick <commitD> 6.3 drop <commitD>
3 … squash <commitE> drop <commitE>
git commit // <commitX> 4.2
fixup <commitF> drop <commitF>
01.06.2017 … 4.2 … 4/16
 Workflow (2)
1. Create local copy:
o Fork (via GitHub) (optionaly)
o Clone (locally)
o Add upstream (for fork)
2. Create a working branch for your changes
see: why not to work in the “original” branch, Slide 14
3. Commit your changes locally
see: when to push your changes to GitHub, Slide 15
4. Make-up the commit history
o 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
o Use rebase –i to rewrite the commit history
5. Push the “fair” branch to GitHub

01.06.2017 5/16
 Workflow (3)
6. Pull request
o Create request via GitHub
o 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)
• …
o 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
o Remove the remote request branch (at least in the original repository)

01.06.2017 6/16
 Workflow (4)
7. Update local copy
o git pull [upstream (for fork case)]

8. Update fork repository

o git push

01.06.2017 7/16
 Git Keywords

01.06.2017 8/16
 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)

01.06.2017 9/16
 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 git rebase master topic A'--B'--C' topic

/ /
D---E---F---G master D---E---F---G master

o---o---o---o---o master o---o---o---o---o master

\ git rebase --onto master next topic | \
o---o---o---o---o next | o'--o'--o' topic
\ \
o---o---o topic o---o---o---o---o next

git rebase --onto topicA~5 topicA~3 topicA

E---F---G---H---I---J topicA E---H'---I'---J' topicA
01.06.2017 10/16
 Keywords: rebase
• rebase –i <commit>
o Interactive rebase
o Rewrite the history: reorder commits, drop them, edit, squash – whatever

01.06.2017 11/16
 Keywords: reset
• Reset <commit>
o set HEAD to <commit> (--soft)
o remove changes between <commit> and last commit made before reset
from index (--mixed) (default)
o rewrite working directory to <commit> version (--hard)

git reset --soft HEAD~1

vi myFile.txt
vi myFile.txt
git add myFile.txt <=> git add myFile.txt
git commit --amend
git commit

More info:
https://git-scm.com/

01.06.2017 12/16
 Why & When

01.06.2017 13/16
 Why
• …not to work in a local copy of the original branch?
o no merge problems when pull actual version from the original repository
o there`s always a branch in the actual state to branch off of
o 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…)?
o when the remote repository forcefully updated, the existing commit history can be rewritten
o if your local copy is behind the remote version, you forceful update will erase someone else`s work (--force-
with-lease helps here)
o 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?

o (+) 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
o (-) extra work to keep the fork up to date (pull upstream + push to fork every now and then)
o (-) no one can see if you`re working hard or do nothing without checking your fork version intentionally

01.06.2017 14/16
 When
• …to push to the remote repository?
o work is finished
o 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
o you want to declare “I`m working on it, here`s the current state”

• …to create a pull request?

o work is finished
o 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))

01.06.2017 15/16
 That`s it

01.06.2017 16/16