git

SCM that you should use every day

Git environment configuration

[global]
    git config --global user.name "Zhou Peng"
    git config --global user.email "[email protected]"

    git config --global color.ui auto
    git config --global core.editor vim

    git config --global merge.tool vimdiff
    git config --global mergetool.prompt false

[project]
    git config core.autocrlf false

[env]
    git config --list

.gitignore

[Git internal]

    Git is designed for #TEXT# file version managment; Binary file is not good
    for Git, which can slow down git speed heavily.

[What's text file]

    Files that can be open by Notepad++, VIM etc. Most important, can be read
    and unstandand by human directly. Such as C/C++/Java/C# source code, XML
    CSS.

[What's binary file]

    All files but text file, such as executable file, picture, tar, rar, zip,
    word, excel, ppt, chm, pdf, iso, ..., too much, too dangerous.

[HOW-TO]

    Write .gitignore to ignore unwanted files, make the word clean and better.

[.gitignore]

  +------------------------------------------------------------+
  |  # Comment - ignore                                        |
  |                                                            |
  |  # ignore all file suffix by .a or .o                      |
  |  *.[oa]                                                    |
  |                                                            |
  |  # keep lib.a                                              |
  |  !lib.a                                                    |
  |                                                            |
  |  # ignore TODO only under root direcotry, no subdir/TODO   |
  |  /TODO                                                     |
  |                                                            |
  |  # ignore all files under build/ directory                 |
  |  build/                                                    |
  |                                                            |
  |  # ignore doc/notes.txt, no doc/server/arch.txt            |
  |  doc/*.txt                                                 |
  |                                                            |
  |  # ignore all .txt files in the doc/ directory             |
  |  doc/**/*.txt                                              |
  +------------------------------------------------------------+

git commit guide

1. Don't submit any whitespace errors, git provides an easy way
   to check for this, before you commit, run

        git diff --check

   which identifies possible whitespace errors and lists them
   for you.

2. Try to make each commit a logically separate changeset. If
   you can, try to make your changes digestible - don't code for
   a whole weekend on five different issues and then submit them
   all as one massive commit on Monday. Even if you don't commit
   during the weekend, use the staging area on Monday to split
   your work into at least one commit per issue, with a userfull
   message per commit. If some of the changes modify the same
   file, try to use git add --patch to partially stage files.

3. As a general rule, your messages should start with a single
   line that's no more than about 50 characters and that
   describes the changeset concisely, followed by a blank line,
   followed by a more detailed explanation. Template written by
   Tim Pope:


   Short (50 chars or less) summary of changes

   More detailed explanatory text, if necessary. Wrap it to
   about 72 characters or so. In some contexts, the first line
   is treated as the subject of an email and the reset of the
   text as the body. The blank line separating the summary from
   the body is critical (unless you omit the body entirely).
   tools like rebase can get confused if you run the two
   tegether.

   Further paragraphs come after blank lines.

     - Bullet points are okay, too

     - Typically a hyphen or asterisk is used for the bullet,
       preceded by a single space, with blank lines in between,
       but conventions vary here

git tricks

1. Who changed my code?

    git blame [COMMIT-SHA1 --] file-name

2. Review repository log?

    git log --oneline --graph --decorate [--all|COMMIT-SHA1]

3. Partly commit a file?

    git add -p file-name

4. Squash commits?

    git rebase -i HEAD~[n]

5. Stash uncommit change?

    git stash [list|apply|pop]

6. Commit lost+found?

    git fsck --lost-found

7. Choose what to merge?

    git cherry-pick COMMIT-SHA1

8. Checkout to last branch?

    git checkout -

results matching ""

    No results matching ""