git clone https://github.com/psvmc/RESideMenu_Swift.git ../RESideMenu_Swift
git clone -b 分支名 https://github.com/psvmc/RESideMenu_Swift.git ../RESideMenu_Swift
克隆下来的项目git的配置信息也下载下来了,所以不用
git init
cd /xx/xx
git init
git remote add origin https://github.com/psvmc/RESideMenu_Swift.git
git add .
git commit -m "注释信息"
git push origin master
git pull <远程主机名> <远程主机分支名>:<本地分支名>
比如 取回origin
主机的next
分支,与本地的master
分支合并,需要写成下面这样
git pull origin next:master
cd /xx/xx
git pull origin master
git add .
git commit -m "注释信息"
git push origin master
git push <远程主机名> <本地分支名>:<远程主机分支名>
比如 把本地的master
分支推送到远程my_master
git push origin master:my_master
git commit --amend
git branch <新分支名字>
git checkout <分支名>
该语句和上一个语句可以和起来用一个语句表示:git checkout -b <分支名>
git push origin <本地分支>:<远程分支>
git branch
git branch -a
git branch -d <本地分支>
git push origin :<远程端分支>
develop
),合并到稳定分支(master
),
首先切换的master
分支:git checkout master
。
然后执行合并操作:git merge develop
。
如果有冲突,会提示你,调用git status
查看冲突文件。
解决冲突,然后调用git add
或git rm
将解决后的文件暂存。
所有冲突解决后,git commit
提交更改。 develop
),衍合到稳定分支(master
)。
首先切换的master
分支:git checkout master
。
然后执行衍和操作:git rebase develop
。
如果有冲突,会提示你,调用git status
查看冲突文件。
解决冲突,然后调用git add
或git rm
将解决后的文件暂存。
所有冲突解决后,git rebase --continue
提交更改。 git跟其它版本控制系统一样,可以打标签(tag), 作用是标记一个点为一个版本号,打标签的操作发生在我们commit修改到本地仓库之后
git add .
git commit -m "fixed some bugs"
git tag -a 1.0 -m "Release version 1.0"
git push origin master
git push origin --tags
--tags
参数表示提交所有tag至服务器
普通的git push origin master
操作不会推送标签到服务器端
git tag -d 1.0
git push origin :refs/tags/1.0
commit
Synchronize Workspace
pull
Merge Tool
Use HEAD(the last local version) of conflicting files
Add to Git index
commit and push
git branch master_backup
git reset --hard dca9073
git push origin master:master --force
git fetch --all
git reset --hard origin/master
设置
git config --global user.name "psvmc"
git config --global user.email "183518918@qq.com"
查看
git config --get user.name
git config --get user.email
加入我们在配置.gitignore
文件之前就提交了123.txt
那么即使我们以后.gitignore
中添加上123.txt
该文件依旧会被提交,该怎样解决呢
先移除追踪
git rm --cached 123.txt
在提交
git commit -m "移除追踪"
git update-index --assume-unchanged <PATH>
这样做虽然能达到(暂时的)目的,但并非最正确的做法,这样做是误解了 git update-index
的含义,而且这样做带来的最直接(不良)后果是这样的:
git update-index --assume-unchanged <PATH>
。这是因为即使你让 Git
假装看不见目标文件的改变,但文件本身还是在 Git
的历史记录里的,所以团队的每个人在 fetch
的时候都会拉到目标文件的变更。(但实际上目标文件是根本不想被 Git
记录的,而不是假装看不见它发生了改变)
git update-index --assume-unchanged <PATH>
就直接 push
了,那么接下来所有拉取了最新代码的成员必须重新执行 update-index
,否则 Git
又会开始记录目标文件的变化。这一点实际上很常见的,比如说某成员换了机器或者硬盘,重新 clone
了一份代码库,由于目标文件还在 Git
的历史记录里,所以他/她很可能会忘记 update-index.
如果你修改的一个文件很大,那么你的每一次修改git都保存历史的话,是很慢的所以
git update-index --assume-unchanged
的真正用法是这样的:
git update-index --assume-unchanged
,这样 Git
暂时不会理睬你对文件做的修改;git update-index --no-assume-unchanged
,于是 Git
只需要做一次更新,这是完全可以接受的了;git clone https://github.com/psvmc/psvmc.github.io.git
git filter-branch --tree-filter 'rm -f jekyll-themes/ztheme/images/*.jpg' --tag-name-filter cat -- --all
git push origin --tags --force
git push origin --all --force
注意 这也会对当前的分支进行操作
也就是说 上述的例子也会删除当前分支的图片
如果只想删除历史文件 就要当前的文件先备份一下
不再追踪文件改动
git update-index --assume-unchanged filePath
恢复追踪文件改动
git update-index —no-assume-unchanged filePath
删除被管理的文件
git rm —cached filePath
删除被管理的文件夹
git rm -r -f —cached filePath
当项目过大时会报一下的错误
RPC failed; curl 18 transfer closed with outstanding read data remaining
解决方法
git config --global http.postBuffer 24288000
git config --list
如果还不行呢
git clone http://github.com/myproject --depth 1
cd myproject
git fetch --unshallow
如果上面的还不行 就可能是Nginx做代理缓存设置过小的缘故
把代理中的缓存关闭就行了(折腾了好久,才试出来的)
location / {
proxy_buffering off;
}
查看之前的版本
git reflog
复制完要会退的版本号后 按q
键退出
回退到指定版本
回退到上个版本
HEAD就代表当前,所以上一个版本其实就是当前-1
前者表示只是改变了HEAD的指向,本地代码不会变化,我们使用git status依然可以看到,同时也可以git commit提交。 后者直接回改变本地源码,不仅仅指向变化了,代码也回到了那个版本时的代码,所以使用是一定要小心,想清楚。