优达学城《Version control with Git》笔记

Git lifecycle:

git config --list  :  list all the configurations

git config --global color.ui auto  :  initiate the color display 

git log  :  check the log of commit

git log -p (git log --patch)  :  compare the diff of commits

git log --oneline  :  show log in one line

git log --p -w (ignore whitespace)   :  compare the difference of commits wiht ignoring the whitespace, only show the different part instead of all the different lines

git init  :  initiate an empty new repo

git clone  :  clone a repo from somewhere 

git statu  :  show status

git log --stat  :  show statistics

git show  <ID>:  show difference between ID and its parent

git add   : Add files from the working directory to the staging index

git add.   :staging all files

git rm --cached: Removes files from the staging index

git commit: Take files from the staging index and save them in the repository (makes a commit),  this command will open the code editor that is specified in your configuration.  Commit is like a checkpoint

if you want to explain the detaisl of the commit, you can write the details below the message with a blank line in between. In that case, git log can show you both the message and the details, while the git log --oneline can just show you the message

git commit -m "Initial commit" （directtly write message instead of poping editor）

git diff <Commit1><Commit2>: get difference from two files 功能和 git log -p一样

git diff :  After changing the files, first you can use git status to check which file has been changes, then you can use the git diff to check where has been changed.

More about diff

git diff --staged  :  compare the difference between staging area and repository

touch .gitignore   :create the .ignore file which can help ignore some files (dont track). Put the names of the files you want to ignore into the .gitignore file. Done

More about ignore

git tag: add tage to specific commit, make this commit (for instance Version 1.0) stand out 

git tag -a V1.0       pop editor to write the message fot tag, <-a>means annotated,always use <-a>

git tag  :verify tag adding success

git tag -d V1.0       delete tag

git tag -a V0.0 <SHA>   add tag to past commit

git branch: multiple path of development simutanuously

git branch  :list the branches

git branch <name>  :creat a branch, after creating the branch, the head is still directing Master

git checkout <branch name>: switch between different branches. this will remove all of the files that are referenced by commits in the master branch. It will replace them with the files that are referenced by the commits in the sidebar branch. The funny thing, though, is that both sidebar and master are pointing at the same commit, so it will look like nothing changes when you switch between them. But the command prompt will show "sidebar"

git checkout <ID in a branch>  ;  checkout a commit in a branch

git checkout can also be used to create a new branch by <-b>:  <git checkout -b richards-branch-for-awesome-changes>

git log --oneline --graph --all   : list all the branches graphiclly

In the output above, notice how the special "HEAD" indicator we saw earlier has an arrow pointing to the sidebar branch. It's pointing to sidebar because the sidebar branch is the current branch, and any commits made right now will be added to the sidebar branch.

<git branch> can be used to check which branch is activated

giti branch -d <branch name>    ：delete branch , deleted branches will not show in the git log, but you still can access it

One thing to note is that you can't delete a branch that you're currently on. So to delete the sidebar branch, you'd have to switch to either the master branch or create and switch to a new branch.

giti branch -D <branch name>  :  Capital D can help to TOTALLY delete a branch

git merge <name-of-branch-to-merge-in>  : combines changes on different branches more . After merging a branch into master, you can delete(-d) the branch, but still can reach it by ID. If conflict occures, edite the files and save, then the IDLE will tell you "both modified : <file name>".  Then git add, then git commit

git reset --merge   :  if "you need to resolve your current index first. Needs merge" occurs, use this command to return back to the before-merge state

git amend  :  replace the most recent commit messsage or  after commitiing  1,edite file 2, save file 3, git add file 4, git ammend  ----alter the last commit instead of creat a new one

git revert <SHA>  :  will undo the changes that were made by the provided commit and creates a new commit to record the change

git reset  :  delete commit

git reset --merge  :  if merge conflict occurs, and you don't want to edit the file in order to solve the conflict, use this command to roll back to the before-merge state 

git reset --hard <reference to commit>  :  erase commits 

git rest --hard  :  erase the change in working directory and staging area, ie. the working directory, staging area and repository are reset as the same

git reset --soft <reference to commit>  :  moves committed changes to the staging

git reset (--mixed) <reference to commit>  :  unstages committed changes

<reference to commit>  :  

• ^ – indicates the parent commit

• ~ – indicates the first parent commit

for example :  

HEAD^ means parent

HEAD~means parent

HEAD^^ means grandparent

HEAD~~means grandparent

if there commit is a merged commit, then it has two parents:

HEAD^ means first parent

HEAD^2 means second parent

HEAD~means first parent

git remote add <name > <URL of repository on Github>  :   add remote name 

git remote  :  display all the remote

git remote -v  :  check the remote names and its corresponding URLs

git push <remote name> <local branch name>  :  push the local branch to the repository that connected to the remote name. 

git pull <remote name> <online branch name>  :  pull the updated branch from Github to local computer

when git clone, it will create a master branch as well as origin/master branch. Only when you push the altered master branch, the origin/master branch as well as the remote master branch in Github will be updated.

git fetch <remote name> :  create a origin/master branch locally which is the same to the remote master branch     

Fork  :  copy reposity online on Github

Pull Request  :  Click here

git config --global core.editor <'your-editor's-config-went-here'>  -w    :configure editor

-w means "Wait for the file to be closed before returning

git config --global core.autocrlf true ：  core.autocrlf是git中负责处理line endings的变量，可以设置三个值--true,inout,false

CRLF 是carriage return line feed。中文意思是回车换行
Windows操作系统下面是： CRLF （ CR  ASCII 为 13 即 \r  回车，LF ASCII 为 10 即 \n 换行），\r\n
Unix/Linux操作系统下是：   LF  (LF ASCII 为 10 即 \n 换行)
Apple操作系统下面是：       CR (CR  ASCII 为 13 即 \r  回车)

mv  :  <filename1> <filename2>  : change the file name

mv  :  <path><filename>  :  move the file in <path> to the pwd and change the name to <filename>

cd <path>  :  change directory

ls  :  list all the files in the working directory

ls -a  :  list all the files including hidden files

pwd  :  present working directory

subl <Name of File>  :  using sublime to open the file

the <.bash_profile> in the home directory may control some config, details

shortcut：

copy/paste = shift+insert

TIPS ： Why design a staging step

The commit step is ought to commit one logical change at one time. If you have more than one files in the repository and only one file changed, only this changed file should be committed, and the staging step can handle this.

TIPS  :  "You are in 'detached HEAD' state"

the commit has not been created a branch, without a branch name. This commit cannot be reached, will not show in the git log. <git checkout -b new_branch_name> can be used the create this new branch, which equals to <git branch new_branch_name> + <git checkout new_branch_name>

TIPS :  "remote branch"

remote branch means branch created by someone else

TIPS :  What To Include In A Commit
I've been telling you what files to create, giving you the content to include, and telling you when you should make commits. But when you're on your own, how do you know what you should include in a commit and when/how often you should make commits?
The goal is that each commit has a single focus. Each commit should record a single-unit change. Now this can be a bit subjective (which is totally fine), but each commit should make a change to just one aspect of the project.
Now this isn't limiting the number of lines of code that are added/removed or the number of files that are added/removed/modified. Let's say you want to change your sidebar to add a new image. You'll probably:
add a new image to the project files
alter the HTML
add/modify CSS to incorporate the new image
A commit that records all of these changes would be totally fine!
Conversely, a commit shouldn't include unrelated changes - changes to the sidebar and rewording content in the footer. These two aren't related to each other and shouldn't be included in the same commit. Work on one change first, commit that, and then change the second one. That way, if it turns out that one change had a bug and you have to undo it, you don't have to undo the other change too.

The best way that I've found to think about what should be in a commit is to think, "What if all changes introduced in this commit were erased?". If a commit were erased, it should only remove one thing.

git 是一种配置管理(软件变更，集成，发布)工具, linux kernel, android的代码就是用git管理的（不是简单地存放在硬盘上）。
shell是linux/unix系统的外壳，也可以理解为命令行借口，就是你输入并执行命令行的地方
bash是shell的一种，最常用的shell之一。

问题：配置方法1 与 配置方法2 有何区别？

问题：C盘、HomeDirectory、WorkingDirectory中的配置文件有何区别

PS: .bash_profile文件存储了git的config,                      .bash_profile是需要放在HomeDirectory里的