GitUse - Revision history

FunPika: added Category:Development using HotCat

2014-03-15T15:34:02Z

← Older revision		Revision as of 15:34, 15 March 2014
Line 69:		Line 69:
	* git blame <filename>		* git blame <filename>
	Shows the commit where each line of code appeared in its current form. Use git show <hash> to see the whole patch where that line was added/changed, and see if you can work out what's what.		Shows the commit where each line of code appeared in its current form. Use git show <hash> to see the whole patch where that line was added/changed, and see if you can work out what's what.

			[[Category:Development]]

24.64.164.166: /* Resources */

2014-03-15T00:20:20Z

Resources

← Older revision		Revision as of 00:20, 15 March 2014
Line 3:		Line 3:

	== Resources ==		== Resources ==
	This book is essential reading for users of all levels [[http://git-scm.com/book]]		This book is essential reading for users of all levels [http://git-scm.com/book]

	== Principles ==		== Principles ==

FatPhil: git blame

2014-03-14T11:58:44Z

git blame

← Older revision		Revision as of 11:58, 14 March 2014
Line 65:		Line 65:

	This scenario reinforces the "always work on a branch" policy. You don't want to accidentally rewrite the history of a branch (master, which you pulled from upstream) that isn't yours.		This scenario reinforces the "always work on a branch" policy. You don't want to accidentally rewrite the history of a branch (master, which you pulled from upstream) that isn't yours.

			== What Idiot Wrote That? ==
			* git blame <filename>
			Shows the commit where each line of code appeared in its current form. Use git show <hash> to see the whole patch where that line was added/changed, and see if you can work out what's what.

FatPhil: The "Oh shit!" scenario

2014-03-14T11:51:18Z

The "Oh shit!" scenario

← Older revision		Revision as of 11:51, 14 March 2014
Line 56:		Line 56:
	Of course, you can delete your local branches with		Of course, you can delete your local branches with
	* git branch -D <branchname>		* git branch -D <branchname>

			== Oh Shit. Oh Shit Oh Shit. Oh Shiiiiiiit!!!! ==
			Yup, you've chopped a limb off. git rebase --abort and git merge --abort not there to save the day? Don't panic! If you remember the last commit you made that you'd be happy to return to, then use:
			* git reflog
			It will show you everything you've done recently. You can then:
			* git reset --hard <hash>
			To just jump back in time to that commit, and start again.

			This scenario reinforces the "always work on a branch" policy. You don't want to accidentally rewrite the history of a branch (master, which you pulled from upstream) that isn't yours.

FatPhil: more of everything...

2014-03-14T00:53:09Z

more of everything...

@@ Line 4: / Line 4: @@
 == Resources ==
 This book is essential reading for users of all levels [[http://git-scm.com/book]]
 == Principles ==
@@ Line 21: / Line 11: @@
 * Write meaningful commit messages. [[http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html]] [[http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message]]
 * One patch one change. I mean it.
 Do not worry about having lots of small patches - every single one will hopefully be utterly trivial to review and verify to be correct.
 == Splitting Edits Into Multiple Commits ==
@@ Line 46: / Line 50: @@
 It is possible to do all kinds of clever things in the middle of a rebase. Sometimes you can get carried away and forget you're in the middle of a rebase. This can lead to confusion, and the inability to do various things, so I find it best to keep my rebases quick and simple, done in one session.
-...
+== Deleting Branches From Your Public Repo ==

Paulej72: /* Undoiing a change you've just committed */

2014-03-14T00:34:11Z

Undoiing a change you've just committed

← Older revision		Revision as of 00:34, 14 March 2014
Line 31:		Line 31:
	Add your meaningful commit message, then GOTO 10		Add your meaningful commit message, then GOTO 10

	== ~~Undoiing~~ a change you've just committed ==		== Undoing a change you've just committed ==
	Undo it in the editor, and then use git add (possibly add -p as above) to stage that change, and then git commit --amend to squash that change into the previous commit.		Undo it in the editor, and then use git add (possibly add -p as above) to stage that change, and then git commit --amend to squash that change into the previous commit.

Paulej72 at 00:33, 14 March 2014

2014-03-14T00:33:22Z

← Older revision		Revision as of 00:33, 14 March 2014
Line 1:		Line 1:
	~~= Git Use =~~
			[[Development]] - parent

	== Resources ==		== Resources ==

FatPhil: /* Principles */ fix list

2014-03-14T00:25:55Z

Principles: fix list

← Older revision		Revision as of 00:25, 14 March 2014
Line 15:		Line 15:

	== Principles ==		== Principles ==
	A) One patch one change. E.g. don't change the URLs in the HTML and the indenting in the same patch, first do the whitespace changes, then do the content changes. This requires self control, but is made much easier one you know how to split your edits into multiple commits. (See below)		* One patch one change. E.g. don't change the URLs in the HTML and the indenting in the same patch, first do the whitespace changes, then do the content changes. This requires self control, but is made much easier one you know how to split your edits into multiple commits. (See below)
	B) In a patchset, do non-functional cleanup/cosmetic changes, or anything that will make the subsequent patches easier to review, first. Then do bugfix changes. Then do feature adds.		* In a patchset, do non-functional cleanup/cosmetic changes, or anything that will make the subsequent patches easier to review, first. Then do bugfix changes. Then do feature adds.
	C) One patch one change.		* One patch one change.
	D) Write meaningful commit messages. [[http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html]] [[http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message]]		* Write meaningful commit messages. [[http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html]] [[http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message]]
	E) One patch one change. I mean it.		* One patch one change. I mean it.

	Do not worry about having lots of small patches - every single one will hopefully be utterly trivial to review and verify to be correct.		Do not worry about having lots of small patches - every single one will hopefully be utterly trivial to review and verify to be correct.

FatPhil: Some handy commands for git

2014-03-14T00:25:13Z

Some handy commands for git

New page

= Git Use =

== Resources ==
This book is essential reading for users of all levels [[http://git-scm.com/book]]

== Common Tasks ==
I'm presuming you know how to:
* clone a repo
* make a branch, and switch between branches
* commit changes
* create a patchset for review, and mail that patchset to a mailing list
* create a pull request

I can expand on any of those if needed.

== Principles ==
A) One patch one change. E.g. don't change the URLs in the HTML and the indenting in the same patch, first do the whitespace changes, then do the content changes. This requires self control, but is made much easier one you know how to split your edits into multiple commits. (See below)
B) In a patchset, do non-functional cleanup/cosmetic changes, or anything that will make the subsequent patches easier to review, first. Then do bugfix changes. Then do feature adds.
C) One patch one change.
D) Write meaningful commit messages. [[http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html]] [[http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message]]
E) One patch one change. I mean it.

Do not worry about having lots of small patches - every single one will hopefully be utterly trivial to review and verify to be correct.

== Splitting Edits Into Multiple Commits ==
You've changed several things in a single, or multiple files, and you realise that really they ought to be in separate patches. Solution:
* git add -p
You can select each hunk, and even recurse into each hunk if it includes multiple changed parts. Once you've added all the bits that belong in the first patch:
* git commit -s
Add your meaningful commit message, then GOTO 10

== Undoiing a change you've just committed ==
Undo it in the editor, and then use git add (possibly add -p as above) to stage that change, and then git commit --amend to squash that change into the previous commit.

== Rewriting History ==
You can edit old commit messages, tweak old patches, squash two adjacent patches together, and even reorder the patches with git rebase -i

To re-order the last 6 patches:
* git rebase -i HEAD~6
If the patches touch the same code, you might need to deal with merge conflicts - search for <<< in the affected file(s), git add that file(s), then git rebase --continue.
If the conflicts are too hard to resolve - just abort the whole rebase with git merge --abort

Do not rewrite any history that you've shared with anyone else, so anything that you've pushed to an externally-facing repo.

It is possible to do all kinds of clever things in the middle of a rebase. Sometimes you can get carried away and forget you're in the middle of a rebase. This can lead to confusion, and the inability to do various things, so I find it best to keep my rebases quick and simple, done in one session.

...