git版本控制器简单使用

Git Usage

 

1. Checkout source code

 $> git clone git@gitserver:job.git  ([e-mail]:job.git)
 
 # config git with your name and email 
 $> git config --global user.name  "your real name" 
 $> git config --global user.email "your company email address" 
 
 # config reviewboard url  
 $> git config reviewboard.url http://xxxxxx.com 
 
 # install code review tool 
 $> sudo yum install RBTools
 $> sudo easy_install -U RBTools  

2. Make changes and submit a patch

 $> git pull --rebase # get latest code from server to apply to current branch  
 $> ... edit your files...
 $> git status # verify all changes 
 $> git diff # carefully check whether all changes are valid or not 
 $> git commit -am "the message of changes" 
 $> git format-patch -k -1 # pust last commit in local tree to a patch 

3. Create a branch to do development

 $> git checkout -fb develop origin/develop #  develop to track original develop
 $> git checkout -fb bug<num> origin/develop # create a feature or bug branch based on develop
  
 $> ... edit your files   
 # ready to checkin
 $> git add <files to checkin> 
 $> git commit -m "message" 
  
 # some other developers certainly have updated the code. pull that first and do rebase on mydevelop branch 
 # first go into develop branch for quick forward (assume there was NO change in develop branch)
 $> git checkout develop; git pull --rebase
 
 # if there are changes, do rebase on bug<num> 
 $> git checkout bug<num>; git rebase develop 
 $> ... fix any conflict during rebase 
  
 # submit for review 
 $> post-review --tracking-branch=origin/develop 
 # if post review to existing review request, do:
 $> post-review --diff-only -r <existing review id> --tracking-branch=origin/develop
  
 # after review shows no problem merge back to develop 
 $> git checkout develop; git merge --squash bug<num>; 
 # squash will merge a few commit into one. If there is only one commit, squash is not needed 
 
 # if --squash is used (combine a few commits from bug branch into one commit), need to run git commit again with real message 
 $> git commit -m "real message for the bug" 

 # before final push, do rebase pull again to make sure things are clean 
 $> git pull --rebase
 
 # if it's good to go, run push 
 $> git push
 
 # delete this old branch
 $> git branch -d bug<num> # delete this bug branch 
 
 

4. Revert a change

 $> git checkout -- <file> # if file has local changes but no confilict 
 $> git checkout HEAD <file> # if a file has conflict 

5. Ｒevert a commited change but not in server

 $> git reset --soft HEAD^  # revert to prior the commit and keep the local change 
 $> git reset --hard HEAD   # discard everything in last commit 

6. Revert a change in server

 $> git revert HEAD 

7. Apply a patch

 $> git apply --stat <patch file>  # check status of the patch 
 $> git apply --check <patch file> # dry-run 
 $> git apply --apply <patch file> # real deal 
 
 # if the patch has signoff information, do: 
 $> git am --signoff --whilespace=fix <patch file>

8. Remove a file

 $> git rm <file name> 

9. Undo a commit and redo

 $> git commit ...
 $> git reset --soft HEAD^  # revert back to prior stage 
 $> edit other files 
 $> git add ....    
 $> git commit -c ORIG_HEAD
 This is most often done when you remembered what you just committed is incomplete,
 or you misspelled your commit message, or both. Leaves working tree as it was before "reset".
 
 Make corrections to working tree files.
 Stage changes for commit.  "reset" copies the old head to .git/ORIG_HEAD;
 redo the commit by starting with its log message. If you do not need to edit the message further, you can give -C option instead.

10. Recovering from a bad git-rebase

 $> git checkout bug123
 $> git reflog 
 # if the branch bug123 has bad rebase, and want to return to prior rebase state, do:
 $> git reset --hard head@{1}