增删改查
当前版本文件
从
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_developgit commitgit push origin coa_develop:coa_develop(remember your commit id just now)git checkout coa_releasegit 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 checkout devname/feature1 <-- Assume the branch is already created, otherwise add -b.
git commit -m “my fancy feature1”
Dev issues a CR based on the private dev branch and let it go through the CR process.
CR should be targeted at “Bing” project.
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 checkout develop
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 checkout develop
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
http://stackoverflow.com/questions/61212/how-to-remove-local-untracked-files-from-the-current-git-branch
转载请注明原文地址: https://ju.6miu.com/read-500044.html
