初始化一个Git仓库,使用git init命令。
添加文件到Git仓库,分两步:
git add <file> git commit -m <message>
HEAD指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭,使用命令 git reset --hard commit_id
。
穿梭前,用 git log
可以查看提交历史,以便确定要回退到哪个版本。
要重返未来,用 git reflog
查看命令历史,以便确定要回到未来的哪个版本。
场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令 git checkout -- readme.txt
意思就是,把readme.txt文件在工作区的修改全部撤销,这里有两种情况:
总之,就是让这个文件回到最近一次git commit或git add时的状态。
场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令 git reset HEAD <file>
,就回到了场景1,第二步按场景1操作。
场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退一节(使用命令 git reset --hard commit_id
),不过前提是没有推送到远程库。
当你要删除文件的时候,可以采用命令: rm test.txt
这个时候(也就是说这个时候只执行了rm test.txt)有两种情况
git rm test.txt
git commit -m "remove test.txt"
然后文件就被删掉了 git branch
git branch <name>
git checkout <name>
或者 git switch <name>
git checkout -b <name>
或者 git switch -c <name>
git merge <name>
git branch -d <name>
当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容,再提交。用 git log --graph
命令可以看到分支合并图(用 git log --graph --pretty=oneline --abbrev-commit
可以查看简化形式的分支合并图)。
在实际开发中,我们应该按照几个基本原则进行分支管理:首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。所以,团队合作的分支看起来就像这样:
合并分支时,加上—no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并(通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。)。
git stash
一下,然后去修复bug,修复后,再 git stash pop
,回到工作现场; git cherry-pick <commit>
命令,把bug提交的修改“复制”到当前分支,避免重复劳动。 注释:总的来说,就是,在分支下进行的工作,如果不commit的话,回到master,就会显示出你在分支下你添加的工作。这个时候,你在master下修改完bug提交后,正在分支进行的工作也会提交了。为了避免这个情况,你就在分支下,git stash将工作隐藏,这个时候,切换到master时候,修改了bug,提交。分支的内容不会被提交上去。
开发一个新feature,最好新建一个分支;如果要丢弃一个没有被合并过的分支,可以通过 git branch -D <name>
强行删除。
当你从远程仓库克隆时,实际上Git自动把本地的master分支和远程的master分支对应起来了,并且,远程仓库的默认名称是origin。
要查看远程库的信息,用 git remote -v
:
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上: git push origin master
如果要推送其他分支,比如dev,就改成: git push origin dev
但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
多人协作的工作模式通常是这样:
git push origin <branch-name> git pull git push origin <branch-name>
如果 git pull
提示 no tracking information,则说明本地分支和远程分支的链接关系没有创建,用命令 git branch --set-upstream-to <branch-name> origin/<branch-name>
。
sudo apt-get install git
sudo adduser git
/home/git/.ssh/authorized_keys
文件里,一行一个。 /srv/sample.git
,在/srv目录下输入命令: sudo git init --bare sample.git
Git就会创建一个裸仓库,裸仓库没有工作区,因为服务器上的Git仓库纯粹是为了共享,所以不让用户直接登录到服务器上去改工作区,并且服务器上的Git仓库通常都以.git结尾。然后,把owner改为git: sudo chown -R git:git sample.git
git:x:1001:1001:,,,:/home/git:/bin/bash
改为: git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell
这样,git用户可以正常通过ssh使用git,但无法登录shell,因为我们为git用户指定的git-shell每次一登录就自动退出。 git clone git@server:/srv/sample.git
。我们的ssh端口可能不是22,那么在填写url的时候就要做出一定的改变的: ssh://用户名@主机IP(或域名):端口号/git目录地址
管理公钥:如果团队很小,把每个人的公钥收集起来放到服务器的 /home/git/.ssh/authorized_keys
文件里就是可行的。如果团队有几百号人,这时,可以用Gitosis来管理公钥。
管理权限:可以在服务器端编写一系列脚本来控制提交等操作,达到权限控制的目的。Gitolite就是这个工具。
使用git pull之后出现冲突error: Your local changes to the following files would be overwritten by merge:
原因:其他人修改了A文件并提交到版本库中去了,而你本地也修改了A文件,这时候你进行 git pull
操作就好出现冲突了。
解决办法:
方法一:服务器代码合并本地代码(推荐)
$ git stash //暂存当前正在进行的工作。 $ git pull origin master //拉取服务器的代码 $ git stash pop //合并暂存的代码
方法二:服务器代码覆盖本地代码
$git reset --hard //回滚到上一个版本 $git pull origin master
我来评几句
登录后评论已发表评论数()