Open main menu

CDOT Wiki β

Changes

DPS909 & OSD600 Winter 2017

250 bytes added, 15:45, 30 January 2017
Week 4
* Working with git Branches
** Lightweight, movable, reference (or pointer) to a commit
** Series of commits: a branch is the furthest tip of a line of commits
** It is always safe to branch, it won't change the code in any way
** Relationship of <code>git commit</code> with branches
*** commit SHA: <code>e0ee2b5acd01acbe5b0bc1ee24b73e5d53a1fd70</code> or shortened to <code>e0ee2b5</code>
*** <code>HEAD</code>: the most recent commit (NOTE: you can also do <code>HEAD~2</code> to mean 2 commits older than <code>HEAD</code> or <code>HEAD~5</code> to mean 5 commits older than <code>HEAD</code>),
*** branch: an easy to remember name we give to the current commit, e.g., <code>master</code>
*** <code>master</code> branch vs. "Topic Branches": '''all work happens on a new branch'''
** creating, switching between, updating
*** <code>git branch <branch name></code>: <code>-d</code> (maybe delete), <code>-D</code> (force delete), <code>-m</code> (rename), <code>-a</code> (list all)
*** <code>git checkout <branch name | commit SHA></code>, discussion of "detached HEAD"
*** <code>git checkout -b <branch name> [<base commit> | HEAD]</code>(create if doesn't exist, checkout new branch)
*** <code>git checkout -B <branch name> [<base commit> | HEAD]</code> (create or reset, checkout new branch)
** local vs. remote, tracking branches
*** Branches are '''always local''' to your current repo
*** <code>git branch -a</code> will show all of your branches, and any/all '''remote branches''' (i.e., branches in remote repos your repo knows about via <code>git fetch</code>)
*** Example: <code>git checkout -b bug123 friend-repo/bug123</code> will create a branch '''bug123''' locally that is pointing at the same commit as the remote repo '''friend-repo''''s '''bug123''' branch.
*** Any branch you check out that is based on a remote branch will be '''tracked''' by git, and any commits they have ahead of you, or you have ahead of them, will get reported
** common workflow
*** <code>git checkout master</code> - switch to master branch
*** <code>git pull upstream master</code> - pull in any new commits from the upstream/master branch
*** <code>git checkout -b issue-1234</code> - create a topic branch for your work, named with bug #
*** <code>git add files</code> - edit files, add to staging area
*** <code>git commit -m "Fix #1234: ..."</code> - commit changes, referencing bug # in commit message
*** <code>git push origin issue-1234</code> - push your topic branch (and all commits) to your origin repo
*** create pull request
** merging
*** A merge in git is a way of combining branches into a single branch/history
*** We always fix bugs and add features on '''new branches''', but then we need to '''merge''' them back into the main '''master''' branch
*** Merging doesn't change any of the branches it combines, it simply connects them.
*** <code>git merge <branch name></code> merges <code><branch name></code> '''into''' the currently checked out branch
*** Different merge algorithms
**** fast-forward merge - given identical histories, move the branch ahead in the history to the new tip
**** 3-way merge - divergent histories, use common ancestor commit (commit 1), and two branch tops (2, 3)
*** recall that <code>git pull</code> does a <code>git fetch</code> and <code>git merge</code> in one step
** rebasing
*** Replay a series of commits on a different branch vs. the current one, rewriting its history
*** Often done with '''squashing''' (combining multiple commits into a single commit) on topic branches before merging with <code>master</code> to simplify the history
*** Because it rewrites history, you shouldn't do it on branches shared with other developers
*** <code>git rebase <new-base></code>
*** After a rebase, it's easy to do '''fast-forward''' merges
*** <code>git rebase -i</code> starts an interactive rebase, and lets you specify what to do with each commit. <code>git rebase --abort</code> let's you stop it mid-way through.
*** If you need to squash the last few commits, you can use <code>git rebase -i HEAD~2</code> for example.
** gh-pages
* Lightweight, movable, reference (or pointer) to a commit
* Series of commits: a branch is the furthest tip of a line of commits
* It is always safe to branch, it won't change the code in any way
* Relationship of <code>git commit</code> with branches
** commit SHA: <code>e0ee2b5acd01acbe5b0bc1ee24b73e5d53a1fd70</code> or shortened to <code>e0ee2b5</code>
** <code>HEAD</code>: the most recent commit (NOTE: you can also do <code>HEAD~2</code> to mean 2 commits older than <code>HEAD</code> or <code>HEAD~5</code> to mean 5 commits older than <code>HEAD</code>),
** branch: an easy to remember name we give to the current commit, e.g., <code>master</code>
** <code>master</code> branch vs. "Topic Branches": '''all work happens on a new branch'''
* creating, switching between, updating
** <code>git branch <branch name></code>: <code>-d</code> (maybe delete), <code>-D</code> (force delete), <code>-m</code> (rename), <code>-a</code> (list all)
** <code>git checkout <branch name | commit SHA></code>, discussion of "detached HEAD"
** <code>git checkout -b <branch name> [<base commit> | HEAD]</code>(create if doesn't exist, checkout new branch)
** <code>git checkout -B <branch name> [<base commit> | HEAD]</code> (create or reset, checkout new branch)
* local vs. remote, tracking branches
** Branches are '''always local''' to your current repo
** <code>git branch -a</code> will show all of your branches, and any/all '''remote branches''' (i.e., branches in remote repos your repo knows about via <code>git fetch</code>)
** Example: <code>git checkout -b bug123 friend-repo/bug123</code> will create a branch '''bug123''' locally that is pointing at the same commit as the remote repo '''friend-repo''''s '''bug123''' branch.
** Any branch you check out that is based on a remote branch will be '''tracked''' by git, and any commits they have ahead of you, or you have ahead of them, will get reported
* common workflow
** <code>git checkout master</code> - switch to master branch
** <code>git pull upstream master</code> - pull in any new commits from the upstream/master branch
** <code>git checkout -b issue-1234</code> - create a topic branch for your work, named with bug #
** <code>git add files</code> - edit files, add to staging area
** <code>git commit -m "Fix #1234: ..."</code> - commit changes, referencing bug # in commit message
** <code>git push origin issue-1234</code> - push your topic branch (and all commits) to your origin repo
** create pull request
* merging
** A merge in git is a way of combining branches into a single branch/history
** We always fix bugs and add features on '''new branches''', but then we need to '''merge''' them back into the main '''master''' branch
** Merging doesn't change any of the branches it combines, it simply connects them.
** <code>git merge <branch name></code> merges <code><branch name></code> '''into''' the currently checked out branch
** Different merge algorithms
*** fast-forward merge - given identical histories, move the branch ahead in the history to the new tip
*** 3-way merge - divergent histories, use common ancestor commit (commit 1), and two branch tops (2, 3)
** recall that <code>git pull</code> does a <code>git fetch</code> and <code>git merge</code> in one step
* rebasing
** Replay a series of commits on a different branch vs. the current one, rewriting its history
** Often done with '''squashing''' (combining multiple commits into a single commit) on topic branches before merging with <code>master</code> to simplify the history
** Because it rewrites history, you shouldn't do it on branches shared with other developers
** <code>git rebase <new-base></code>
** After a rebase, it's easy to do '''fast-forward''' merges
** <code>git rebase -i</code> starts an interactive rebase, and lets you specify what to do with each commit. <code>git rebase --abort</code> let's you stop it mid-way through.
** If you need to squash the last few commits, you can use <code>git rebase -i HEAD~2</code> for example.
* gh-pages
** Great for hosting static web content associated with a project
** https://pages.github.com/
** Once enabled for a project, you can use a special <code>gh-pages</code> branch
** Pushing commits to this branch will cause web content to get hosted at '''http://username.github.io/repository'''
<!--