优达学城《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.
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
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
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 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
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 CommitI'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之一。
问题：C盘、HomeDirectory、WorkingDirectory中的配置文件有何区别
PS: .bash_profile文件存储了git的config, .bash_profile是需要放在HomeDirectory里的