421 Matching Annotations
  1. Nov 2017
    1. $ git log -p [file]

      显示指定文件相关的每一次diff

      显示效果如下,但会显示高亮:

      commit 32e0c4f6bbb91617126b1cf2ab8c403ce7691ffe
      Author: lishuailong <lishuailong@baidu.com>
      Date:   Tue Jul 11 15:14:59 2017 +0800
      
          delete by loc
      
      diff --git a/bin/server_control b/bin/server_control
      index 6d81daa..4cf5106 100755
      --- a/bin/server_control
      +++ b/bin/server_control
      @@ -48,7 +48,7 @@ function cleanup() {
       function realtime_cleanup() {
           mkdir -p ../realtime_delete/data
           DATE_TO_CLEANUP=`date +"%Y%m%d" -d "-7 days"`
      -    cat ../data/*${DATE_TO_CLEANUP}*.succ | $PYTHON_BIN delete_succ.py 2> ../log/realtime_cleanup.log
      +    cat ../data/*${DATE_TO_CLEANUP}*.succ | $PYTHON_BIN delete.py --format json 2> ../log/realtime_cleanup.log
           rm -f ../data/*${DATE_TO_CLEANUP}*
       }
      
      
      commit 47a2565e033dc1ed60a0ffd4df5e760dbcaebad8
      Author: lishuailong <lishuailong@baidu.com>
      Date:   Thu Jul 6 16:18:47 2017 +0800
      
          fix realtime cleanup
      
      diff --git a/bin/server_control b/bin/server_control
      index 13b756f..6d81daa 100755
      --- a/bin/server_control
      +++ b/bin/server_control
      @@ -48,7 +48,7 @@ function cleanup() {
       function realtime_cleanup() {
           mkdir -p ../realtime_delete/data
           DATE_TO_CLEANUP=`date +"%Y%m%d" -d "-7 days"`
      -    cat ../data/*${DATE_TO_CLEANUP}.succ | $PYTHON_BIN delete_succ.py 2> ../log/realtime_cleanup.log
      +    cat ../data/*${DATE_TO_CLEANUP}*.succ | $PYTHON_BIN delete_succ.py 2> ../log/realtime_cleanup.log
           rm -f ../data/*${DATE_TO_CLEANUP}*
       }
      
    1. exists as long as the feature is in development

      When the development of a feature takes a long time, it may be useful to continuously merge from develop into the feature branch. This has the following advantages:

      • We can use the new features introduced in develop in the feature branch.
      • We simplify the integration merge of the feature branch into develop that will happen at a later point.
  2. Feb 2017
    1. Jedi Mind Tricks for Git

      @jankrag & @randomsort (slides, demo-repo)

      Principles which are supported by hooks presented here
      • never commit on master
      • always reference an issue in commit message (via GitHub API)
      • #serverless, #noOps & delivery through ready-branches
      • hook manager: overcommit (via)
      attributes + drivers to improve diff
      • hexdump binaries
      • convert .docx to .md
      • line-wrap paragraphs
      • metadata of images or audio
      • ASCI-ize image
      • xls2csv, unzip
      filter drivers (process BLObs on save or checkout)
      • enforce lint-/formatting
      • Caesar's obfuscation

      also: @_flexbox's sketch notes

    2. Git Simple: Writing primary git functionalities in Ruby
    3. Repo 911
    4. Git and the Terrible, Horrible, No Good, Very Bad Day

      also: @_flexbox's sketch notes

    5. The Battle for Sub-premacy
    6. Greatest Hits of the Git Maintainers Room: 2016
      renamed to: Greatest Hits from the Ask-Git-Core

      also: @_flexbox's sketch notes

  3. Sep 2016
  4. Apr 2016
    1. When .git/HEAD is gone, git doesn't even think your repository is a repository. So really, we must fix this first or else we will not be able to use any git commands to salvage the rest.

      After a recent power outage, a call to 'git status' returned this:

      fatal: Not a git repository (or any of the parent directories): .git

      When I inspected .git/HEAD, it was filled with what looked like binary code, rather than a string like:

      ref: refs/heads/master

      or

      ref: refs/heads/develop

      This:

      echo 'ref: refs/heads/develop' > ./git/HEAD

      did the trick!

  5. Aug 2015
  6. Jun 2015
    1. The best way to find branches I've recently used is to use the following command: git for-each-ref --sort=-committerdate refs/heads/
  7. May 2015
    1. git for-each-ref --sort='-committerdate' --format='%(refname)%09%(committerdate)' refs/heads | sed -e 's-refs/heads/--'
    1. If you want a deeper explanation skip down to "The long version". ref~ is shorthand for ref~1 and means the commit's first parent. ref~2 means the commit's first parent's first parent. ref~3 means the commit's first parent's first parent's first parent. And so on. ref^ is shorthand for ref^1 and means the commit's first parent. But where the two differ is that ref^2 means the commit's second parent (remember, commits can have two parents when they are a merge). The ^ and ~ operators can be combined.
  8. Jan 2015
  9. Nov 2014
  10. Jan 2014
    1. Rule of thumb: When pulling changes from origin/develop onto your local develop use rebase. When finishing a feature branch merge the changes back to develop.
    1. If Master has diverged since the feature branch was created, then merging the fea - ture branch into master will create a merge commit. This is a typical merge.
    1. Git is revolutionary because it gives you the best of both worlds. You can regularly check in changes while prototyping a solution but deliver a clean history when you’re finished. When this is your goal, Git’s defaults make a lot more sense.

      Git gets this basic division of worlds right and is a fundamental departure from other version control systems like SVN. The feature that enables all this is nearly cost-free, instantaneous branching.

      What makes this new world complex is not due to git, but instead because the world is, quite simply, complex! Good tools like git help us manage (some of) the complexity.

    2. If you’re fighting Git’s defaults, ask why. Treat public history as immutable, atomic, and easy to follow. Treat private history as disposable and malleable. The intended workflow is: Create a private branch off a public branch. Regularly commit your work to this private branch. Once your code is perfect, clean up its history. Merge the cleaned-up branch back into the public branch.

      Good defaults are sometimes hard to recognize, especially when the tool is complex.

      Questioning the defaults-- and deciding why you would keep them or change them-- is a good antidote to dismissing something due to not understanding it.

      If you can't understand why you don't like the defaults, then decide what you would choose instead and why you would change the default as it stands. Does the default make it easy to do the "right" thing AND hard to do the "wrong" thing? The second part of that statement is the most important since it might not be obvious what the "right" thing is.

      Even if you don't like the defaults, ask yourself if they continually lead you away from perils and problems that would plague you if a different set of defaults were chosen?