Git basic commands
增删改查当前版本文件 从 XX地方作用到 XX地方(合并两者)Gti merge Git clone (default local folder)Git pullGit push Git pull = git fetch + git merge 修复冲突 分支的增删改查 代码生效checkinwe can
·
增删改查
当前版本文件
从 XX 地方 作用到 XX 地方 ( 合并两者 )
Gti merge
Git clone (default local folder)
Git pull
Git push
Git pull = git fetch + git merge
修复冲突
分支的增删改查
代码生效 checkin
we can treat git commit as a checkin to local repository
Commit 中文翻译就是版本库的一次更新
Git clone http://XXX -b apk-oct
Clone remote apk-oct branch to local folder, and local's branch name is also apk-oct
Clone should has 4 arguments, remote server path, remote branch, local new branch name , local folder path
Origin is the default remote repository http://XXX alias
git fetch
The resulting commits are stored as remote branches instead of the normal local branches that we’ve been working with. This gives you a chance to review changes before integrating them into your copy of the project.
如果不加任何参数，会受 git config 影响， 默认拉 origin apk-oct 到本地 apk-oct
git fetch <remote>
Git fetch origin
Fetch all of the branches from the repository. This also downloads all of the required commits and files from the other repository.
如果第一次 clone 或者 改变了 origin 的地址，都要 run 这步
git fetch <remote> <branch>
Same as the above command, but only fetch the specified branch.
并在本地生成一个 origin/apk-oct 一个临时的本地只读 branch
Git log
参数 分支 1 分支 2 版本 1 版本 2
git log origin/ apk-oct
Check the history of origin/apk-oct (you git fetch origin/apk-oct to the local)
Git log origin apk-oct
Check the remote origin apk-oct change history
git log --oneline apk-oct.. origi n/apk-oct
git log -p origin/ apk-oct..apk-oct
Check the history from start time local apk-oct to latest remote apk-oct
好像 origin/apk-oct apk-oct 先后顺序没有关系
git log --graph --pretty=oneline --abbrev-commit
git log -p -2
Check the last time detailed changes
Git view history for log
git log -- path/to/folder/*
Git diff
Must ensure your changes has git add
Git diff apk-oct origin/apk-oct
After git fetch remote
Old in the first place, new in the second place
Git diff 默认用的好像不是当前的分支和 origin/ 当前分支进行比较
git diff HEAD -- readme.txt 命令可以查看工作区和版本库里面最新版本的区别
git diff 显示工作目录与索引区文件之间的差异
git diff --cached显示索引区与 git仓库之间的差异
git diff HEAD 显示工作目录与 git仓库之间的差异
git diff HEAD^ 比较上次提交
git diff HEAD~2 比较上 2次提交
--diff-filter=[ACDMRTUXB*]
显示指定状态的文件： Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), changed (T), are Unmerged (U), are Unknown (X)
git difftool 使用图形工具显示文件之间的差异
git diff --stat 列出文件
git diff -- filename 只对比给定的文件
历史提交对比：
$ git diff commit 将所指定的某次提交与当前工作目录进行对比。
$ git diff commit1 commit2 将 2次提交的内容进行对比
等价于
$ git diff commit1..commit2 如果省略任意一个 commit，默认将使用HEAD代替
commit可以是简写的 commit哈希值，也可是是HEAD。其中HEAD代表最后一次提交，HEAD^代表最后一次提交的父提交，HEAD~1>等价于HEAD^,HEAD~2为倒数第二次提交，以此类推。
Compare same file of in two branches
git diff mybranch master -- myfile.cs
git diff branch1:file branch2:file
Compare two branches
git diff branch_1..branch_2
That will produce the diff between the tips of the two branches. If you'd prefer to find the diff from their common ancestor to test, you can use three dots instead of two:
git diff branch_1...branch_2
Git diff --name-only
Git status
Will show the
1 your branch back-ward how many commits
2. changes not staged for commit
3. changes for commit
4. untracked files
staging area: This is the area for files that you are about to commit.
Untracked the file: git does not treat files on the filesystem as automatically included in the version control system, you have to add things explicitly into the git repository (as you are doing by adding the current directory with git add .).
git rm --cached README.txt” 命令，可以将 changes for commit 文件状态还原为未暂存状态，即回到 "Untracked files" 文件状态
“Changes not staged for commit” 状态，表明文件已经修改，但是还没有放入暂存区域，也就是没生成快照。如果现在进行 commit 操作，只是将修改之前的文件快照提交到了 git 目录，一定记住：只有暂存区域的文件（即：文件状态为 “Changes to be committed” ）才会被提交。正如提示，通过 “git add README.txt” 命令将已修改文件更新到暂存区域中，如果想撤销修改，可以使用 “git checkout -- README.txt” 命令。
1 ） Untracked files → 文件未被跟踪；
2 ） Changes to be committed → 文件已暂存，这是下次提交的内容；
3) Changes but not updated → 文件被修改，但并没有添加到暂存区。如果 commit 时没有带 -a 选项，这个状态下的文件不会被提交。
Git co -- .
Discard all changes not added in current branch
Git merge origin/master
会默认将 origin/master merge 到本地 master, 是否跟 git config 有关？
合并某分支到当前分支： git merge <name>
Git branch
在 apk-oct branch 执行 git branch wiwu-apk-oct 就会根据 apk-oct 复制出一份 wiwu-apk-oct branch
应该有两个参数
1. 老分支
2. 新分支
git branch -m | -M oldbranch newbranch 重命名分支，如果 newbranch 名字分支已经存在，则需要使用 -M 强制重命名，否则，使用 -m 进行重命名。
git branch -d | -D branchname 删除 branchname 分支
git branch -d -r branchname 删除远程 branchname 分支
Git branch -r
有人说是查看远端的分支情况，但是即使远端是删除了，这个命令还可以使用，所以应该是查看 git fetch 后在本地的所有的只读分支
并且换掉了 origin 地址后，这条命令显示为空， 所以应该是查看 git fetch 后所有留在本地的只读 branch
Rename
git branch -m old_branch new_branch
Git checkout projw
默认操作是切换本地分支
拉了远端的 apk-oct branch 现在希望再拉远端的 projw branch ，通过 git checkout projw, 发现你本地没有 projw 自动从 origin/projw 中拉出你的 branch
创建 + 切换分支： git checkout -b <name>
git rm 有两种选择
一种是 git rm --cached " 文件路径 " ，不删除物理文件，仅将该文件从缓存中删除；
如果修改了一个文件， git add , 然后 git rm --cached, 这个文件就会显示 deleted in staged area
一种是 git rm --f " 文件路径 " ，不仅将该文件从缓存中删除，还会将物理文件删除（不会回收到垃圾桶）。
git rm --cached doesn't unstage a file. It stages the removal of the file from the repo and leaves the file in your working tree, leaving you with an untracked file. git reset on the other hand, will unstage any staged changes for a given file.
Git clean
git clean -f
remove local (untracked) files from my current Git branch?
Git config
git config --get-regexp alias
查看所有配置的 alias
git config --global -l
git config --global -e
Git remote -v
To get the remote alais like origin's config
Git remote show origin
Show the remote origin state
Change the origin server
git remote rm origin
git remote add origin http://vstfbing:8080/tfs/Bing/repo.DSS/_git/<repo_name>
Git checkout
git checkout -b 本地分支名 远程分支名
必须保证已经 run 过了 git fetch 命令，已经将所有的远程分支拉到了本地
git branch –r 所 列出的是经过 git fetch origin 拿到本地的所有 origin/Xxx 的列表， 即他们是本地的那些只读 branch
git co -b coa_release origin/coa_release
Git checkout -b 新分支名
从当前分支复制出一份新的分支， 并切换到这个新分支去
Git merge
提示 Conflict 的文件就是有冲突并且系统自己不能解决，用 vim 去修改那些文件解决冲突
然后执行一次 commit
Git push
$ git push origin test:master // 提交本地 test 分支作为远程的 master 分支
$ git push origin test:test // 提交本地 test 分支作为远程的 test 分支
如果想删除远程的分支呢？类似于上面，如果 : 左边的分支为空，那么将删除 : 右边的远程的分支。
$ git push origin :test // 刚提交到远程的 test 将被删除，但是本地还会保存的，不用担心。
Git 删除本地分支
git br -d test
git br - D test 强制删除
Git add
Git add 后可以切换分支， add 的 change 会被带入新的分支
Git
会把 add 到 stage 状态的也保存在 stash 里面
Git change commit author
Interactive rebase off of a point earlier in the history than the commit you need to modify (git rebase -i <earliercommit>). In the list of commits being rebased, change the text from pick to edit next to the hash of the one you want to modify. Then when git prompts you to change the commit, use this:
git commit --amend --author="Author Name <email@address.com>"
For example, if your commit history is A-B-C-D-E-F with F as HEAD, and you want to change the author of C and D, then you would...
Specify git rebase -i B
change the lines for both C and D to edit
Once the rebase started, it would first pause at C
You would git commit --amend --author="Author Name <email@address.com>"
Then git rebase --continue
It would pause again at D
Then you would git commit --amend --author="Author Name <email@address.com>" again
git rebase --continue
The rebase would complete.
Git merge two commit
Get back to where you started with
$ git rebase --abort
Say your history is
$ git log --pretty=oneline
a931ac7c808e2471b22b5bd20f0cad046b1c5d0d c
b76d157d507e819d7511132bdb5a80dd421d854f b
df239176e1a2ffac927d8b496ea00d5488481db5 a
That is, a was the first commit, then b, and finally c.
Running git rebase --interactive HEAD~2 gives you an editor with
pick b76d157 b
pick a931ac7 c
# Rebase df23917..a931ac7 onto df23917
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
Changing b's pick to squash will result in the error you saw, but if instead you squash c into b by changing the text to
pick b76d157 b
s a931ac7 c
and save-quitting your editor, you'll get another editor whose contents are
# This is a combination of 2 commits.
# The first commit's message is:
b
# This is the 2nd commit message:
c
When you save and quit, the contents of the edited file become commit message of the new combined commit:
$ git log --pretty=oneline
18fd73d3ce748f2a58d1b566c03dd9dafe0b6b4f b and c
df239176e1a2ffac927d8b496ea00d5488481db5 a
From < http://stackoverflow.com/questions/2563632/how-can-i-merge-two-commits-into-one >
Git exchange two commit order
In your case, you can rebase interactive: git rebase -i HEAD~4 Then you can just reorder your picks
For example lets add three more files to our branch:
git add A
git commit -m "A"
git add B
git commit -m "B"
git add C
git commit -m "C"
Your shortlog will be:
$ git shortlog
(3):
A
B
C
If you want to reorder B with C:
$ git rebase -i HEAD~2
pick 1f9133d B
pick 33f41be C
You just re-order them to be:
pick 33f41be C
pick 1f9133d B
After your done writing, see the shortlog:
$ git shortlog
(3):
A
C
B
From < http://stackoverflow.com/questions/4981061/how-to-re-order-commits-in-git-non-interactively >
Git delete one commit
From < http://stackoverflow.com/questions/1338728/delete-commits-from-a-branch-in-git >
git 删除远程分支
一不小心把本地的临时分支 push 到 server 上去了，想要删除。
一开始用
git branch -r -d origin/branch-name
不成功，发现只是删除的本地对该远程分支的 track ，正确的方法应该是这样：
git push origin :branch-name ( 中间必须有空格 )
冒号前面的空格不能少，原理是把一个空分支 push 到 server 上，相当于删除该分支。
Git stash
$git stash
$do some work
$git stash pop
From < http://blog.csdn.net/wh_19910525/article/details/7784901 >
git stash save "work in progress for foo feature"
当你多次使用’ git stash’ 命令后 ，你的栈里将充满了未提交的代码，这时候你会对将哪个版本应用回来有些困惑，
’ git stash list ’ 命令可以将当前的 Git 栈信息打印出来，你只需要将找到对应的版本号，例如使用’ git stash apply stash@{1}’ 就可以将你指定版本号为 stash@{1} 的工作取出来 ，当你将所有的栈都应用回来的时候，可以使用’ git stash clear ’ 来将栈清空。
From < http://blog.csdn.net/wh_19910525/article/details/7784901 >
git stash show -p stash@{0}
From < http://stackoverflow.com/questions/7677736/git-diff-against-a-stash >
git push origin HEAD
A handy way to push the current
branch to the same name on the remote.
From < http://stackoverflow.com/questions/23241052/git-push-origin-head >
HEAD points to the top of the current branch. git can obtain the branch name from that. So it's the same as:
git push origin CURRENT_BRANCH_NAME
From < http://stackoverflow.com/questions/23241052/git-push-origin-head >
fetch vs pull
fetch will download any changes from the remote branch, updating your repository data, but leaving your local branch unchanged.
pull will perform a fetch and additionally merge the changes into your local branch.
What's the difference? pull updates you local branch with changes from the pulled branch. A fetch does not advance your local branch.
merge vs rebase (SD 没有这个问题，因为本地只有一个 version ， 即 c d e 合成一个 )
Given the following history:
C---D---E local
/
A---B---F---G remote
merge joins two development histories together. It does this by replaying the changes that occurred on your local branch after it diverged on top of the remote branch, and record the result in a new commit. This operation preserves the ancestry of each commit.
The effect of a merge will be:
C---D---E local
/ \
A---B---F---G---H remote
rebase will take commits that exist in your local branch and re-apply them on top of the remote branch. This operation re-writes the ancestors of your local commits.
The effect of a rebase will be:
C'--D'--E' local
/
A---B---F---G remote
What's the difference? A merge does not change the ancestry of commits. A rebase rewrites the ancestry of your local commits.
From < http://stackoverflow.com/questions/14894768/git-fetch-vs-pull-merge-vs-rebase >
Pull with rebase instead of merge
$ git pull --rebase
# e.g. if on branch "master": performs a ` git fetch origin `,
# then ` git rebase origin/master `
Because branch merges in git are recorded with a merge commit, they are supposed to be meaningful — for example, to indicate when a feature has been merged to a release branch. However, during a regular daily workflow where several team members sync a single branch often, the timeline gets polluted with unnecessary micro-merges on regular git pull . Rebasing ensures that the commits are always re-applied so that the history stays linear.
You can configure certain branches to always do this without the --rebase flag:
# make `git pull` on master always use rebase
$ git config branch.master.rebase true
You can also set up a global option to set the last property for every new tracked branch:
# setup rebase for every tracking branch
$ git config --global branch.autosetuprebase always
From < http://mislav.uniqpath.com/2010/07/git-tips/ >
Tutor:
https://www.atlassian.com/git/tutorials/syncing/git-fetch
Git 相比 TFS, SD 有更多的分支操作
Git with winmerge
http://cuppster.com/2011/02/08/how-to-setup-gits-difftool-on-windows/
git config --global difftool.winmerge.cmd "C:/git-difftool.bat \"\$LOCAL\" \"\$REMOTE\""
Git br -vv
Check the remote branch that current local branch track
Git reset HEAD -- "*.iml"
Remove all *.iml from git add
Undo the last commit and put them into git add .
git reset --soft HEAD~
Combine several merges into one
git reset --soft HEAD~3 &&
git commit
Git cherry pick commit from coa_develop to coa_release
Git combine last several times commit
# Reset the current branch to the commit just before the last 12:
git reset --hard HEAD~12
# HEAD@{1} is where the branch was just before the previous command.
# This command sets the state of the index to be as it would just
# after a merge from that commit:
git merge --squash HEAD@{1}
# Commit those squashed changes. The commit message will be helpfully
# prepopulated with the commit messages of all the squashed commits:
git commit
From < http://stackoverflow.com/questions/5189560/squash-my-last-x-commits-together-using-git >
Dev process
Note: The yellow portion of the git commands below is for instruction purpose and should be replaced with the actual value.
git commit -m “my fancy feature1”
git pull
git checkout devname/feature1
git rebase develop
git rebase -i HEAD~5 <-- Combine the last 5 (an example) commits into one commit.
git push origin devname/feature1: devname/feature1 –force
git merge devname/feature1
git push origin develop:develop
For hotfix to the release branch the target branch is release (or the change can be made directly in the release branch without using the private dev branch).
Track new remote
git branch branch_name --set-upstream-to your_new_remote/branch_name
From < http://stackoverflow.com/questions/4878249/how-do-i-change-the-remote-a-git-branch-is-tracking >
git clean
从 XX 地方 作用到 XX 地方 ( 合并两者 )
Gti merge
Git clone (default local folder)
Git pull
Git push
Git pull = git fetch + git merge
修复冲突
分支的增删改查
代码生效 checkin
we can treat git commit as a checkin to local repository
Commit 中文翻译就是版本库的一次更新
Git clone http://XXX -b apk-oct
Clone remote apk-oct branch to local folder, and local's branch name is also apk-oct
Clone should has 4 arguments, remote server path, remote branch, local new branch name , local folder path
Origin is the default remote repository http://XXX alias
git fetch
The resulting commits are stored as remote branches instead of the normal local branches that we’ve been working with. This gives you a chance to review changes before integrating them into your copy of the project.
如果不加任何参数，会受 git config 影响， 默认拉 origin apk-oct 到本地 apk-oct
git fetch <remote>
Git fetch origin
Fetch all of the branches from the repository. This also downloads all of the required commits and files from the other repository.
如果第一次 clone 或者 改变了 origin 的地址，都要 run 这步
git fetch <remote> <branch>
Same as the above command, but only fetch the specified branch.
并在本地生成一个 origin/apk-oct 一个临时的本地只读 branch
Git log
参数 分支 1 分支 2 版本 1 版本 2
git log origin/ apk-oct
Check the history of origin/apk-oct (you git fetch origin/apk-oct to the local)
Git log origin apk-oct
Check the remote origin apk-oct change history
git log --oneline apk-oct.. origi n/apk-oct
git log -p origin/ apk-oct..apk-oct
Check the history from start time local apk-oct to latest remote apk-oct
好像 origin/apk-oct apk-oct 先后顺序没有关系
git log --graph --pretty=oneline --abbrev-commit
git log -p -2
Check the last time detailed changes
Git view history for log
git log -- path/to/folder/*
Git diff
Must ensure your changes has git add
Git diff apk-oct origin/apk-oct
After git fetch remote
Old in the first place, new in the second place
Git diff 默认用的好像不是当前的分支和 origin/ 当前分支进行比较
git diff HEAD -- readme.txt 命令可以查看工作区和版本库里面最新版本的区别
git diff 显示工作目录与索引区文件之间的差异
git diff --cached显示索引区与 git仓库之间的差异
git diff HEAD 显示工作目录与 git仓库之间的差异
git diff HEAD^ 比较上次提交
git diff HEAD~2 比较上 2次提交
--diff-filter=[ACDMRTUXB*]
显示指定状态的文件： Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), changed (T), are Unmerged (U), are Unknown (X)
git difftool 使用图形工具显示文件之间的差异
git diff --stat 列出文件
git diff -- filename 只对比给定的文件
历史提交对比：
$ git diff commit 将所指定的某次提交与当前工作目录进行对比。
$ git diff commit1 commit2 将 2次提交的内容进行对比
等价于
$ git diff commit1..commit2 如果省略任意一个 commit，默认将使用HEAD代替
commit可以是简写的 commit哈希值，也可是是HEAD。其中HEAD代表最后一次提交，HEAD^代表最后一次提交的父提交，HEAD~1>等价于HEAD^,HEAD~2为倒数第二次提交，以此类推。
Compare same file of in two branches
git diff mybranch master -- myfile.cs
git diff branch1:file branch2:file
Compare two branches
git diff branch_1..branch_2
That will produce the diff between the tips of the two branches. If you'd prefer to find the diff from their common ancestor to test, you can use three dots instead of two:
git diff branch_1...branch_2
Git diff --name-only
Git status
Will show the
1 your branch back-ward how many commits
2. changes not staged for commit
3. changes for commit
4. untracked files
staging area: This is the area for files that you are about to commit.
Untracked the file: git does not treat files on the filesystem as automatically included in the version control system, you have to add things explicitly into the git repository (as you are doing by adding the current directory with git add .).
git rm --cached README.txt” 命令，可以将 changes for commit 文件状态还原为未暂存状态，即回到 "Untracked files" 文件状态
“Changes not staged for commit” 状态，表明文件已经修改，但是还没有放入暂存区域，也就是没生成快照。如果现在进行 commit 操作，只是将修改之前的文件快照提交到了 git 目录，一定记住：只有暂存区域的文件（即：文件状态为 “Changes to be committed” ）才会被提交。正如提示，通过 “git add README.txt” 命令将已修改文件更新到暂存区域中，如果想撤销修改，可以使用 “git checkout -- README.txt” 命令。
1 ） Untracked files → 文件未被跟踪；
2 ） Changes to be committed → 文件已暂存，这是下次提交的内容；
3) Changes but not updated → 文件被修改，但并没有添加到暂存区。如果 commit 时没有带 -a 选项，这个状态下的文件不会被提交。
Git co -- .
Discard all changes not added in current branch
Git merge origin/master
会默认将 origin/master merge 到本地 master, 是否跟 git config 有关？
合并某分支到当前分支： git merge <name>
Git branch
在 apk-oct branch 执行 git branch wiwu-apk-oct 就会根据 apk-oct 复制出一份 wiwu-apk-oct branch
应该有两个参数
1. 老分支
2. 新分支
git branch -m | -M oldbranch newbranch 重命名分支，如果 newbranch 名字分支已经存在，则需要使用 -M 强制重命名，否则，使用 -m 进行重命名。
git branch -d | -D branchname 删除 branchname 分支
git branch -d -r branchname 删除远程 branchname 分支
Git branch -r
有人说是查看远端的分支情况，但是即使远端是删除了，这个命令还可以使用，所以应该是查看 git fetch 后在本地的所有的只读分支
并且换掉了 origin 地址后，这条命令显示为空， 所以应该是查看 git fetch 后所有留在本地的只读 branch
Rename
git branch -m old_branch new_branch
Git checkout projw
默认操作是切换本地分支
拉了远端的 apk-oct branch 现在希望再拉远端的 projw branch ，通过 git checkout projw, 发现你本地没有 projw 自动从 origin/projw 中拉出你的 branch
创建 + 切换分支： git checkout -b <name>
git rm 有两种选择
一种是 git rm --cached " 文件路径 " ，不删除物理文件，仅将该文件从缓存中删除；
如果修改了一个文件， git add , 然后 git rm --cached, 这个文件就会显示 deleted in staged area
一种是 git rm --f " 文件路径 " ，不仅将该文件从缓存中删除，还会将物理文件删除（不会回收到垃圾桶）。
git rm --cached doesn't unstage a file. It stages the removal of the file from the repo and leaves the file in your working tree, leaving you with an untracked file. git reset on the other hand, will unstage any staged changes for a given file.
Git clean
git clean -f
remove local (untracked) files from my current Git branch?
Git config
git config --get-regexp alias
查看所有配置的 alias
git config --global -l
git config --global -e
Git remote -v
To get the remote alais like origin's config
Git remote show origin
Show the remote origin state
Change the origin server
git remote rm origin
git remote add origin http://vstfbing:8080/tfs/Bing/repo.DSS/_git/<repo_name>
Git checkout
git checkout -b 本地分支名 远程分支名
必须保证已经 run 过了 git fetch 命令，已经将所有的远程分支拉到了本地
git branch –r 所 列出的是经过 git fetch origin 拿到本地的所有 origin/Xxx 的列表， 即他们是本地的那些只读 branch
git co -b coa_release origin/coa_release
Git checkout -b 新分支名
从当前分支复制出一份新的分支， 并切换到这个新分支去
Git merge
提示 Conflict 的文件就是有冲突并且系统自己不能解决，用 vim 去修改那些文件解决冲突
然后执行一次 commit
Git push
$ git push origin test:master // 提交本地 test 分支作为远程的 master 分支
$ git push origin test:test // 提交本地 test 分支作为远程的 test 分支
如果想删除远程的分支呢？类似于上面，如果 : 左边的分支为空，那么将删除 : 右边的远程的分支。
$ git push origin :test // 刚提交到远程的 test 将被删除，但是本地还会保存的，不用担心。
Git 删除本地分支
git br -d test
git br - D test 强制删除
Git add
Git add 后可以切换分支， add 的 change 会被带入新的分支
Git
会把 add 到 stage 状态的也保存在 stash 里面
Git change commit author
Interactive rebase off of a point earlier in the history than the commit you need to modify (git rebase -i <earliercommit>). In the list of commits being rebased, change the text from pick to edit next to the hash of the one you want to modify. Then when git prompts you to change the commit, use this:
git commit --amend --author="Author Name <email@address.com>"
For example, if your commit history is A-B-C-D-E-F with F as HEAD, and you want to change the author of C and D, then you would...
Specify git rebase -i B
change the lines for both C and D to edit
Once the rebase started, it would first pause at C
You would git commit --amend --author="Author Name <email@address.com>"
Then git rebase --continue
It would pause again at D
Then you would git commit --amend --author="Author Name <email@address.com>" again
git rebase --continue
The rebase would complete.
Git merge two commit
Get back to where you started with
$ git rebase --abort
Say your history is
$ git log --pretty=oneline
a931ac7c808e2471b22b5bd20f0cad046b1c5d0d c
b76d157d507e819d7511132bdb5a80dd421d854f b
df239176e1a2ffac927d8b496ea00d5488481db5 a
That is, a was the first commit, then b, and finally c.
Running git rebase --interactive HEAD~2 gives you an editor with
pick b76d157 b
pick a931ac7 c
# Rebase df23917..a931ac7 onto df23917
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
Changing b's pick to squash will result in the error you saw, but if instead you squash c into b by changing the text to
pick b76d157 b
s a931ac7 c
and save-quitting your editor, you'll get another editor whose contents are
# This is a combination of 2 commits.
# The first commit's message is:
b
# This is the 2nd commit message:
c
When you save and quit, the contents of the edited file become commit message of the new combined commit:
$ git log --pretty=oneline
18fd73d3ce748f2a58d1b566c03dd9dafe0b6b4f b and c
df239176e1a2ffac927d8b496ea00d5488481db5 a
From < http://stackoverflow.com/questions/2563632/how-can-i-merge-two-commits-into-one >
Git exchange two commit order
In your case, you can rebase interactive: git rebase -i HEAD~4 Then you can just reorder your picks
For example lets add three more files to our branch:
git add A
git commit -m "A"
git add B
git commit -m "B"
git add C
git commit -m "C"
Your shortlog will be:
$ git shortlog
(3):
A
B
C
If you want to reorder B with C:
$ git rebase -i HEAD~2
pick 1f9133d B
pick 33f41be C
You just re-order them to be:
pick 33f41be C
pick 1f9133d B
After your done writing, see the shortlog:
$ git shortlog
(3):
A
C
B
From < http://stackoverflow.com/questions/4981061/how-to-re-order-commits-in-git-non-interactively >
Git delete one commit
| 215down vote | Another possibility is one of my personal favorite commands: git rebase -i <commit>~1 This will start the rebase in interactive mode -i at the point just before the commit you want to whack. The editor will start up listing all of the commits since then. Delete the line containing the commit you want to obliterate and save the file. Rebase will do the rest of the work, deleting only that commit, and replaying all of the others back into the log. |
From < http://stackoverflow.com/questions/1338728/delete-commits-from-a-branch-in-git >
git 删除远程分支
一不小心把本地的临时分支 push 到 server 上去了，想要删除。
一开始用
git branch -r -d origin/branch-name
不成功，发现只是删除的本地对该远程分支的 track ，正确的方法应该是这样：
git push origin :branch-name ( 中间必须有空格 )
冒号前面的空格不能少，原理是把一个空分支 push 到 server 上，相当于删除该分支。
Git stash
$git stash
$do some work
$git stash pop
From < http://blog.csdn.net/wh_19910525/article/details/7784901 >
git stash save "work in progress for foo feature"
当你多次使用’ git stash’ 命令后 ，你的栈里将充满了未提交的代码，这时候你会对将哪个版本应用回来有些困惑，
’ git stash list ’ 命令可以将当前的 Git 栈信息打印出来，你只需要将找到对应的版本号，例如使用’ git stash apply stash@{1}’ 就可以将你指定版本号为 stash@{1} 的工作取出来 ，当你将所有的栈都应用回来的时候，可以使用’ git stash clear ’ 来将栈清空。
From < http://blog.csdn.net/wh_19910525/article/details/7784901 >
git stash show -p stash@{0}
From < http://stackoverflow.com/questions/7677736/git-diff-against-a-stash >
git push origin HEAD
A handy way to push the current
branch to the same name on the remote.
From < http://stackoverflow.com/questions/23241052/git-push-origin-head >
HEAD points to the top of the current branch. git can obtain the branch name from that. So it's the same as:
git push origin CURRENT_BRANCH_NAME
From < http://stackoverflow.com/questions/23241052/git-push-origin-head >
fetch vs pull
fetch will download any changes from the remote branch, updating your repository data, but leaving your local branch unchanged.
pull will perform a fetch and additionally merge the changes into your local branch.
What's the difference? pull updates you local branch with changes from the pulled branch. A fetch does not advance your local branch.
merge vs rebase (SD 没有这个问题，因为本地只有一个 version ， 即 c d e 合成一个 )
Given the following history:
C---D---E local
/
A---B---F---G remote
merge joins two development histories together. It does this by replaying the changes that occurred on your local branch after it diverged on top of the remote branch, and record the result in a new commit. This operation preserves the ancestry of each commit.
The effect of a merge will be:
C---D---E local
/ \
A---B---F---G---H remote
rebase will take commits that exist in your local branch and re-apply them on top of the remote branch. This operation re-writes the ancestors of your local commits.
The effect of a rebase will be:
C'--D'--E' local
/
A---B---F---G remote
What's the difference? A merge does not change the ancestry of commits. A rebase rewrites the ancestry of your local commits.
From < http://stackoverflow.com/questions/14894768/git-fetch-vs-pull-merge-vs-rebase >
Pull with rebase instead of merge
$ git pull --rebase
# e.g. if on branch "master": performs a ` git fetch origin `,
# then ` git rebase origin/master `
Because branch merges in git are recorded with a merge commit, they are supposed to be meaningful — for example, to indicate when a feature has been merged to a release branch. However, during a regular daily workflow where several team members sync a single branch often, the timeline gets polluted with unnecessary micro-merges on regular git pull . Rebasing ensures that the commits are always re-applied so that the history stays linear.
You can configure certain branches to always do this without the --rebase flag:
# make `git pull` on master always use rebase
$ git config branch.master.rebase true
You can also set up a global option to set the last property for every new tracked branch:
# setup rebase for every tracking branch
$ git config --global branch.autosetuprebase always
From < http://mislav.uniqpath.com/2010/07/git-tips/ >
Tutor:
https://www.atlassian.com/git/tutorials/syncing/git-fetch
Git 相比 TFS, SD 有更多的分支操作
Git with winmerge
http://cuppster.com/2011/02/08/how-to-setup-gits-difftool-on-windows/
git config --global difftool.winmerge.cmd "C:/git-difftool.bat \"\$LOCAL\" \"\$REMOTE\""
Git br -vv
Check the remote branch that current local branch track
Git reset HEAD -- "*.iml"
Remove all *.iml from git add
Undo the last commit and put them into git add .
git reset --soft HEAD~
Combine several merges into one
git reset --soft HEAD~3 &&
git commit
Git cherry pick commit from coa_develop to coa_release
- git checkout coa_develop
- git commit
- git push origin coa_develop:coa_develop
- (remember your commit id just now)
- git checkout coa_release
- git cherry-pick <commit id>
- git push origin coa_release:coa_release
Git combine last several times commit
# Reset the current branch to the commit just before the last 12:
git reset --hard HEAD~12
# HEAD@{1} is where the branch was just before the previous command.
# This command sets the state of the index to be as it would just
# after a merge from that commit:
git merge --squash HEAD@{1}
# Commit those squashed changes. The commit message will be helpfully
# prepopulated with the commit messages of all the squashed commits:
git commit
From < http://stackoverflow.com/questions/5189560/squash-my-last-x-commits-together-using-git >
Dev process
Note: The yellow portion of the git commands below is for instruction purpose and should be replaced with the actual value.
- Dev can check into his/her private dev branch freely at will.
git commit -m “my fancy feature1”
- Dev issues a CR based on the private dev branch and let it go through the CR process.
- After CR is signed off dev performs a merge or rebase of the private dev branch against the official dev branch (develop)
- Rebase is preferred since it helps to preserve a clean linear commit history.
- Small intermediate commit should be combined into a single commit.
git pull
git checkout devname/feature1
git rebase develop
git rebase -i HEAD~5 <-- Combine the last 5 (an example) commits into one commit.
git push origin devname/feature1: devname/feature1 –force
- Dev integrates the private dev branch to the official dev branch (develop).
- If rebase is performed at the previous step then the merge should be a simple fast forward merge.
git merge devname/feature1
git push origin develop:develop
For hotfix to the release branch the target branch is release (or the change can be made directly in the release branch without using the private dev branch).
Track new remote
git branch branch_name --set-upstream-to your_new_remote/branch_name
From < http://stackoverflow.com/questions/4878249/how-do-i-change-the-remote-a-git-branch-is-tracking >
git clean
瓜分20万奖金 获得内推名额 丰厚实物奖励 易参与易上手
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)