因为在开发过程中使用的是sourceTree这种git图形化界面管理工具,导致git命令每隔一段时间就会有点生疏。那么就有了这片写作的动机,试图通过这样一篇文章的总结,让我们从git的第一次安装,到熟练操作git的命令,都能在此得到体现。
一:安装git之后的配置
当我们下载安装好git之后,第一步就是为git设置好用户名和邮箱,这个用户名和邮箱会在提交的日志中显示,如果项目公开了,那么在github中也可以查看到。设置成功之后的信息保存在~/.gitconfig这个文件中。
git config --global user.name "xiaguangcheng"
git config --global user.email "xiaguangcheng@163.com"
git config --global color.ui auto
上面的最后一行命令将命令行的输出显示为自动颜色,这样方便我们阅读。设置完之后,我们就可以查看设置效果:
sublime ~/.gitconfig
由于我对sublime设置了别名,因此可以直接打开sublime编辑器查看。效果如下:
[user]
name = xiaguangcheng
email = xiaguangcheng@163.com
[color]
ui = auto
二:git本地仓库与git远程仓库(github)之间的链接
github是用git来管理的仓库,本地与远程的连接是通过SSH公钥和私钥来完成的。那么如何获取本地电脑的公钥和私钥呢?
ssh-keygen -t rsa -C "xiaguangcheng@163.com"
然后一路回车,如果没有错误提示,就表示生成成功了。生成的文件保存在~/.ssh这个隐藏文件夹下,我们打开这个文件夹会有以下三个文件:
id_rsa
id_rsa.pub
known_hosts
而我们需要的公钥就保存在id_rsa.pub中。我们可以在github的setting中的 SSH Keys中,任意建立一个title当作公钥的名称,然后复制这个id_rsa.pub文件中的内容,到这输入框中。
然后我们就可以通过在本地电脑中测试是否能够与github连接了
ssh -T git@github.com
三:在github中创建新仓库
在github中create一个新的仓库的时候,会有一个initialize this repository with a README选项,我们不建议勾选。因为一旦勾选了,那么这个仓库就有内容了,就失去了原初面目,这样的话,如果本地已经有了一个git项目,想要提交到这里,就需要先拉取再提交,而不能直接提交了。
四:clone远程仓库到本地
git clone url
当我们clone仓库到本地后,可以在仓库中新建一个文件并修改。然后使用
git status
查看本地仓库的状态。通过
git add name.txt
添加name.txt 到暂存区。通过
git commit -m "add file"
将暂存区里面的文件统一提交到本地仓库。再通过
git push
就可以将本地仓库推送到远程仓库了。
五:git详细操作
前面讲解了在先有github的仓库,然后克隆到本地进行修改推送的操作。接下来我们看看先有本地仓库,然后再连接本地和远程仓库,推送到远程仓库的情况。
(一):创建一个本地仓库
mkdir gitTest
cd gitTest
git init
这样就创建了一个本地文件夹,并且在里面进行了初始化。
(二):添加一个本地文件
touch test.txt
echo "first" >> test.txt
cat test.txt //我们可以查看test.txt里面的内容
到这里,我们创建了一个test.txt的文件,并且在里面添加了一个first字符串。此时我们可以通过命令查看当前仓库的情况
git status
image.png
这要得益于我们之前配置的color.ui auto 因此我们可以看到一个红色的标志,上面的文字说明了这个文件没有被track,也就是这个文件独立于这个仓库,并没有被git管理到,那么我们经过以下几个操作,就可以让这个文件处在git的管理中了。
git add test.txt
git commit -m "add first"
git status
image.png
如图所示,我们已经将一个文件添加到git版本控制了。
(三):修改文件并查看修改前后差别,然后提交。
echo "second" >> test.txt
echo "thrid" >> test.txt
git status
git diff
这个时候,我们就可以提交了。但是我们要养成一个习惯,当我们把修改的文件添加到暂存区之后,准备commit的时候,最好先通过git diff HEAD来查看上次提交,和正准备提交的这次,两者之间的差别。这里的HEAD是本分支的最后一次提交的指针。当我们看完之后,才提交就比较安全了。 image.png
我们可以通过下面这个命令,查看属于这个文件的相关日志
git log test.txt
(四):操作分支
git的强大之处表现之一就是分支。比如此时我们使用
git branch
就会显示一个黄绿色的master。表明我们身在master分支中。如果我们想以master分支创建新分支
git checkout -b develop
image.png
此时我们就身在develop分支中了。实际上上面的命令等同于下面的两条命令
git branch develop
git checkout develop
俗话说花开两朵,暂表一枝。咱们先不管master分支,先来培育新建的这个develop分支。下面我们打算修改test.txt,将里面的second修改为forth,然后在提交之前,先通过git diff Head查看和最近一次提交的差别,然后提交。
image.png(五):切换分支
上面我们已经在develop分支中把代码修改完了,此时我们可以使用命令来切换分支,看看master分支有没有受到我们在develop分支上进行改动的影响。
git checkout master
image.png
正如大家所见,刚刚我们在develop分支中,将second修改为了forth,但是在master分支中,second依然为second。
(六):合并分支
现在我们打算将在develop中的修改,应用到master分支上,可以如下操作,记住我们像把a分支合并到b分支上,我们需要把代码切换到b分支上,如果不放心是否在b分支上,可以先git branch一下看看。在merge的过程中,会弹出编辑框,这个编辑框是vi模式,需要懂得vi快捷键才能进行编辑。
git branch
git merge --no-ff develop
git log
合并完成之后,我们也可以通过另外一个命令查看日志
git log --graph
image.png
(七):回溯分支
从上面的图中,我们可以看到当前我们在master分支中,并且在中间又创建了一个新的develop分支。并且在develop分支中对test.txt进行了修改,然后又合并到了master分支中。那么我们现在就是要回溯分支。通过命令在master分支还没有创建develop分支的时候,创建一个online分支,然后修改online分支并提交,再切回到master分支合并develop分支之后的状态,然后再合并online分支。这样听起来有一点yesterday once more的感觉。
我们要回溯分支,需要一个时间点的hash值,这个hash值可以通过git log来获得。通过上图我们可以看出我们实际上是想回到2a95a4...这个节点,现在我们在master分支上
git reset --hard 2a95a4
通过上图的几个命令操作,我们发现此时的master分支上的test.txt内容,已经没有了被之前develop修改的痕迹了,之前develop修改了second为forth,但是此时这个forth就不存在了。
这是我们就可以创建一个新的分支online,然后在online分支上,对这个test.txt进行操作了。
image.png上面操作的命令,就不用具体讲解了,我们最后看到在online分支上的test.txt中的second这个字符串,被我们修改为了online这个字符串。接着我们就提交了这次修改。提交修改后,我们需要切换回master分支,准备再次回到master与develop合并的那个节点。此时的git log命令只能查询当前节点之前的日志,但是当前节点是在master与develop合并之前,所以要查看所有的节点,我们需要引入新的命令
git reflog
image.png
此时我们再使用命令切换,将master分支切换到其与develop 分支合并的地方
git reset --hard 8441ba2
通过log,我们也可以看出,我们已经将当前节点切换到了讲develop合并到master上的地方。其中git log --pretty=short表示我们查看精简版的日志,也就是每条日志不看提交日期。
接下来我们再来将online分支合并到master分支上。
image.png这是我们看到命令提示CONFLICT。表示合并出现来冲突,我们通过sublime打开这个test.txt文件查看冲突,结果如图所示。
image.png
分析如下:在master分支与online分支合并之前,master分支上的test.txt中的second字符串已经被develop字符串修改为forth,但是现在online分支又将之前的second修改为online,所以系统不知道这二者之间到底要保存哪一个?因此出现来冲突。这是需要我们自己手动解决冲突,我们可以保留forth,也可以保留online,也可以两者都保留,或者两者都不保留。这里我们就保留online吧。
记得将git的冲突标志以及不需要的代码删除,结果如下
image.png然后我们提交修改之后的内容,并查看结果
image.png(八):修改提交信息
我们通过git log --graph 查看日志,发现上次提交叫做“conflict”不太合适,于是我们想要补充这次提交的日志。我们可以使用新命令
git commit --amend
image.png
(九):修改日志
修改提交日志可以使用git rebase 命令,比如我们要将一个变量换一个名字等。
image.png如图所示,我们这里产生了两次提交,第一次提交添加了一个develop,第二次提交修改develop为develop_b,下面我们通过命令将这两个提交进行合并
git rebase -i HEAD~2
此时会弹出一个编辑框,我们把编辑框里面的需要修改的日志前面的pick改成fixup即可,保存退出编辑框。我们通过命令查看
image.png但是如果我们使用git reflog查看的话,我们的修改动作,一目了然
image.png六:推送本地仓库到远程
我们推送本地仓库到远程,首先需要确保有本地仓库和远程仓库。远程仓库作为一个刚刚初始化的仓库,最好不要创建任何东西在里面,连README.md最好也不要有。那么我们就可以通过下面的命令将远程仓库设置为本地仓库的远程仓库
git remote add origin git@github.com:xiaguangcheng/gitTest.git
现在我们回到master分支,通过命令
git push -u origin master
开始推送本地仓库。
如果我们想推送其他分支
git check out develop
git push -u origin develop
这样就可以了。然后我们可以通过命令查看是否是否推送成功
git branch -a
如果我们想从远程检出新分支,那么我们可以
git checkout -b develop_c origin/develop_c
这个命令表示,我们从远程检出一个名为develop_c的分支,并且保存在本地仓库,同时也命名为develop_c。
记住,我们在哪个分支上使用
git push
就会推送本分支到本分支远程的分支上。git pull 和git push同理。
网友评论