667
edits
Changes
no edit summary
*** Conflict markers <code><<<<<<<<<</code>, <code>=============</code>, <code>>>>>>>>>>>>></code>
** [https://blog.humphd.org/fearless-merges/ Doing big merges in git]
== Week 6 ==
* 0.2 Updates
** Interesting projects you've found?
** Update your Info on the 0.2 wiki with status blog post, PR(s)
* <code>git rebase branch</code>
** Replay commits on a new base branch/commit
** Process goes like this:
*** git finds a common ancestor commit of the branch you're on, and the one you're rebasing onto
*** git calculates DIFFs for each, saves them to disk
*** git checks out the commit you want to branch onto, and begins to replay those diffs one by one
*** if there is a merge conflict, the rebase pauses so you can fix things
*** use <code>git rebase --continue</code> or <code>git rebase --abort</code> to move forward after such a pause
*** use <code>git rebase --skip</code> to ignore the current commit and keep going
** Never rebase commits that are shared publicly in another repo. Only do it on commits you own locally (e.g., a topic branch you are working on)
** Don't use rebase to get rid of commits in a public branch, use <code>git revert commit-sha</code> instead to apply an inverse commit
** If you rebase a branch you've pushed (e.g., for a pull request), when you push, use <code>git push origin branch-name -f</code> (f means force and will overwrite)
** <code>git rebase -i</code> for interactive rebase
*** shows a script of all commits in reverse order (order they will be replayed). You can hand edit this to remove, re-order, or combine commits
** You can squash on the same branch by rebasing on <code>HEAD~n</code> where n is how many commits back from HEAD to go
