甘肃建设厅网站执法局,网站制作价格便宜,做spa的网站怎么推广,做网站网页需要学些什么建立版本库
创建一个版本库非常简单#xff0c;首先#xff0c;选择一个合适的地方#xff0c;创建一个空目录#xff08;repository#xff09;#xff1a;
$ mkdir learngit //创建learngit目录
$ cd learngit //切换当前目录为learngit目录
$ pwd //用于显示当…建立版本库
创建一个版本库非常简单首先选择一个合适的地方创建一个空目录repository
$ mkdir learngit //创建learngit目录
$ cd learngit //切换当前目录为learngit目录
$ pwd //用于显示当前目录
/Users/michael/learngit //最终路径
第二步通过git init命令把这个目录变成Git可以管理的仓库
$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/ 瞬间Git就把仓库建好了。如果你没有看到子目录.git那是因为这个目录默认是隐藏的用ls -ah命令就可以看见。
把文件添加到版本库
先编写一个readme.txt文件内容如下
Git is a version control system.
Git is free software.一定要放到learngit目录下子目录也行因为这是一个Git仓库放到其他地方Git再厉害也找不到这个文件。
第一步用命令git add告诉Git把文件添加到仓库
$ git add readme.txt
第二步用命令git commit告诉Git把文件提交到仓库
$ git commit -m wrote a readme file
[master (root-commit) eaadf4e] wrote a readme file1 file changed, 2 insertions()create mode 100644 readme.txt简单解释一下git commit命令-m后面输入的是本次提交的说明可以输入任意内容当然最好是有意义的这样你就能从历史
记录里方便地找到改动记录。
git commit命令执行成功后会告诉你1 file changed1个文件被改动我们新添加的readme.txt文件2 insertions插入
了两行内容readme.txt有两行内容。
为什么Git添加文件需要addcommit一共两步呢因为commit可以一次提交很多文件所以你可以多次add不同的文件比如
$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m add 3 files.
小结
现在总结一下今天学的两点内容
初始化一个Git仓库使用git init命令。
添加文件到Git仓库分两步
使用命令git add file注意可反复多次使用添加多个文件使用命令git commit -m message完成。我们继续修改readme.txt文件改成如下内容
Git is a distributed version control system.
Git is free software.现在运行git status命令看看结果
$ git status
On branch master
Changes not staged for commit:(use git add file... to update what will be committed)(use git checkout -- file... to discard changes in working directory)modified: readme.txtno changes added to commit (use git add and/or git commit -a)git status命令可以让我们时刻掌握仓库当前的状态上面的命令输出告诉我们readme.txt被修改过了但还没有准备提交的
修改。
看看具体修改了什么内容需要用git diff这个命令看看
$ git diff readme.txt
diff --git a/readme.txt b/readme.txt
index 46d49bf..9247db6 100644
--- a/readme.txtb/readme.txt-1,2 1,2
-Git is a version control system.
Git is a distributed version control system.Git is free software.git diff顾名思义就是查看difference显示的格式正是Unix通用的diff格式可以从上面的命令输出看到我们在第一行添加了
一个distributed单词。
提交修改和提交新文件是一样的两步第一步是git add
$ git add readme.txt同样没有任何输出。在执行第二步git commit之前我们再运行git status看看当前仓库的状态
$ git status
On branch master
Changes to be committed:(use git reset HEAD file... to unstage)modified: readme.txtgit status告诉我们将要被提交的修改包括readme.txt下一步就可以放心地提交了
$ git commit -m add distributed
[master e475afc] add distributed1 file changed, 1 insertion(), 1 deletion(-)提交后我们再用git status命令看看仓库的当前状态
$ git status
On branch master
nothing to commit, working tree cleanGit告诉我们当前没有需要提交的修改而且工作目录是干净working tree clean的。
小结 要随时掌握工作区的状态使用git status命令。 如果git status告诉你有文件被修改过用git diff可以查看修改内容。 在Git中我们用git log命令查看历史记录
$ git log
commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD - master)
Author: Michael Liao askxuefenggmail.com
Date: Fri May 18 21:06:15 2018 0800append GPLcommit e475afc93c209a690c39c13a46716e8fa000c366
Author: Michael Liao askxuefenggmail.com
Date: Fri May 18 21:03:36 2018 0800add distributedcommit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
Author: Michael Liao askxuefenggmail.com
Date: Fri May 18 20:59:18 2018 0800wrote a readme filegit log命令显示从最近到最远的提交日志我们可以看到3次提交最近的一次是append GPL上一次是add distributed最
早的一次是wrote a readme file。
如果嫌输出信息太多看得眼花缭乱的可以试试加上--prettyoneline参数
$ git log --prettyoneline
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD - master) append GPL
e475afc93c209a690c39c13a46716e8fa000c366 add distributed
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file
需要友情提示的是你看到的一大串类似1094adb...的是commit id版本号
把readme.txt回退到上一个版本也就是add distributed的那个版本
首先Git必须知道当前版本是哪个版本在Git中用HEAD表示当前版本也就是最新的提交1094adb...注意我的提交ID和你
的肯定不一样上一个版本就是HEAD^上上一个版本就是HEAD^^当然往上100个版本写100个^比较容易数不过来所以写成
HEAD~100。
现在我们要把当前版本append GPL回退到上一个版本add distributed就可以使用git reset命令
$ git reset --hard HEAD^
HEAD is now at e475afc add distributed
看看readme.txt的内容是不是版本add distributed
$ cat readme.txt
Git is a distributed version control system.
Git is free software.果然被还原了。
我们用git log再看看现在版本库的状态
$ git log
commit e475afc93c209a690c39c13a46716e8fa000c366 (HEAD - master)
Author: Michael Liao askxuefenggmail.com
Date: Fri May 18 21:03:36 2018 0800add distributedcommit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
Author: Michael Liao askxuefenggmail.com
Date: Fri May 18 20:59:18 2018 0800wrote a readme file最新的那个版本append GPL已经看不到了好比你从21世纪坐时光穿梭机来到了19世纪想再回去已经回不去了肿么办
办法其实还是有的只要上面的命令行窗口还没有被关掉你就可以顺着往上找啊找啊找到那个append GPL的commit id是
1094adb...于是就可以指定回到未来的某个版本
$ git reset --hard 1094a
HEAD is now at 83b0afe append GPL版本号没必要写全前几位就可以了Git会自动去找。当然也不能只写前一两位因为Git可能会找到多个版本号就无法确定
是哪一个了。
再小心翼翼地看看readme.txt的内容
$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL. 可以
现在你回退到了某个版本关掉了电脑第二天早上就后悔了想恢复到新版本怎么办找不到新版本的commit id怎么办
在Git中总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到add distributed版本时再想恢复到append GPL
就必须找到append GPL的commit id。Git提供了一个命令git reflog用来记录你的每一次命令
$ git reflog
e475afc HEAD{1}: reset: moving to HEAD^
1094adb (HEAD - master) HEAD{2}: commit: append GPL
e475afc HEAD{3}: commit: add distributed
eaadf4e HEAD{4}: commit (initial): wrote a readme file终于舒了口气从输出可知append GPL的commit id是1094adb现在你又可以乘坐时光机回到未来了。 小结 HEAD指向的版本就是当前版本因此Git允许我们在版本的历史之间穿梭使用命令git reset --hard commit_id。 穿梭前用git log可以查看提交历史以便确定要回退到哪个版本。 要重返未来用git reflog查看命令历史以便确定要回到未来的哪个版本。 工作区和暂存区 撤销修改
场景1当你改乱了工作区某个文件的内容想直接丢弃工作区的修改时用命令git checkout -- file。
场景2当你不但改乱了工作区某个文件的内容还添加到了暂存区时想丢弃修改分两步第一步用命令git reset HEAD
file就回到了场景1第二步按场景1操作。
场景3已经提交了不合适的修改到版本库时想要撤销本次提交参考版本回退一节不过前提是没有推送到远程库。 删除文件
一般情况下你通常直接在文件管理器中把没用的文件删了或者用rm命令删了
$ rm test.txt
这个时候Git知道你删除了文件因此工作区和版本库就不一致了git status命令会立刻告诉你哪些文件被删除了
$ git status
On branch master
Changes not staged for commit:(use git add/rm file... to update what will be committed)(use git checkout -- file... to discard changes in working directory)deleted: test.txtno changes added to commit (use git add and/or git commit -a)现在你有两个选择一是确实要从版本库中删除该文件那就用命令git rm删掉并且git commit
$ git rm test.txt
rm test.txt$ git commit -m remove test.txt
[master d46f35e] remove test.txt1 file changed, 1 deletion(-)delete mode 100644 test.txt现在文件就从版本库中被删除了。 小提示先手动删除文件然后使用git rm file和git addfile效果是一样的。
另一种情况是删错了因为版本库里还有呢所以可以很轻松地把误删的文件恢复到最新版本
$ git checkout -- test.txt但是要小心你只能恢复文件到最新版本你会丢失最近一次提交后你修改的内容。
git checkout其实是用版本库里的版本替换工作区的版本无论工作区是修改还是删除都可以“一键还原”。 远程仓库github
在继续阅读后续内容前请自行注册GitHub账号。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的所以需
要一点设置
第1步创建SSH Key。在用户主目录下我的是C:\Users\lw看看有没有.ssh目录如果有再看看这个目录下有没有
id_rsa和id_rsa.pub这两个文件如果已经有了可直接跳到下一步。如果没有在用户主目录下打开ShellWindows下鼠标右
键Git Bash创建SSH Key
$ ssh-keygen -t rsa -C youremailexample.com你需要把邮件地址换成你自己的邮件地址然后一路回车使用默认值即可由于这个Key也不是用于军事目的所以也无需设
置密码。
如果一切顺利的话可以在用户主目录里找到.ssh目录里面有id_rsa和id_rsa.pub两个文件这两个就是SSH Key的秘钥
对id_rsa是私钥不能泄露出去id_rsa.pub是公钥可以放心地告诉任何人。
第2步登陆GitHub打开“settings”“SSH and GPG Keys”页面
然后点“New SSH Key”填上任意Title在Key文本框里粘贴id_rsa.pub文件的内容
点“Add Key”你就应该看到已经添加的Key
为什么GitHub需要SSH Key呢因为GitHub需要识别出你推送的提交确实是你推送的而不是别人冒充的而Git支持SSH协
议所以GitHub只要知道了你的公钥就可以确认只有你自己才能推送。
当然GitHub允许你添加多个Key。假定你有若干电脑你一会儿在公司提交一会儿在家里提交只要把每台电脑的Key都添
加到GitHub就可以在每台电脑上往GitHub推送了。 添加远程库
现在github上创建一个New Repository成功之后页面会提示可以从这个仓库克隆出新的仓库也可以把一个已有的本地仓库
与之关联然后把本地仓库的内容推送到GitHub仓库。
现在我们根据GitHub的提示在本地的learngit仓库下运行命令
$ git remote add origin gitgithub.com:michaelliao/learngit.git
每个新仓库都会有https或者ssh地址复制其中一个替代 gitgithub.com:michaelliao/learngit.git
origin表示远程库这是Git默认的叫法也可以改成别的但是origin这个名字一看就知道是远程库。
下一步就可以把本地库的所有内容推送到远程库上
$ git push -u origin master如果结果不是如下请往下耐心点看
Counting objects: 20, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (20/20), 1.64 KiB | 560.00 KiB/s, done.
Total 20 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To github.com:michaelliao/learngit.git* [new branch] master - master
Branch master set up to track remote branch master from origin.把本地库的内容推送到远程用git push命令实际上是把当前分支master推送到远程。
由于远程库是空的我们第一次推送master分支时加上了-u参数Git不但会把本地的master分支内容推送的远程新的master分
支还会把本地的master分支和远程的master分支关联起来在以后的推送或者拉取时就可以简化命令。
SSH警告
当你第一次使用Git的clone或者push命令连接GitHub时会得到一个警告
The authenticity of host github.com (xx.xx.xx.xx) cant be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?这是因为Git使用SSH连接而SSH连接在第一次验证GitHub服务器的Key时需要你确认GitHub的Key的指纹信息是否真的来自
GitHub的服务器输入yes回车即可。
Git会输出一个警告告诉你已经把GitHub的Key添加到本机的一个信任列表里了
Warning: Permanently added github.com (RSA) to the list of known hosts.这个警告只会出现一次后面的操作就不会有任何警告了。
如果你实在担心有人冒充GitHub服务器输入yes前可以对照GitHub的RSA Key的指纹信息是否与SSH连接给出的一致。 小结
要关联一个远程库使用命令git remote add origin gitserver-name:path/repo-name.git
关联后使用命令git push -u origin master第一次推送master分支的所有内容
此后每次本地提交后只要有必要就可以使用命令git push origin master推送最新修改 从远程库克隆
获取你要克隆的远程库地址用命令git clone克隆一个本地库
$ git clone gitgithub.com:michaelliao/gitskills.git
Cloning into gitskills...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
Receiving objects: 100% (3/3), done.注意把Git库的地址换成你自己的然后进入gitskills目录看看已经有README.md文件了
$ cd gitskills
$ ls
README.md
你也许还注意到GitHub给出的地址不止一个还可以用https://github.com/michaelliao/gitskills.git这样的地址。实际
上Git支持多种协议默认的git://使用ssh但也可以使用https等其他协议。
使用https除了速度慢以外还有个最大的麻烦是每次推送都必须输入口令但是在某些只开放http端口的公司内部就无法使用
ssh协议而只能用https通过ssh支持的原生git协议速度最快。 分支管理
分支在实际中有什么用呢假设你准备开发一个新功能但是需要两周才能完成第一周你写了50%的代码如果立刻提交由
于代码还没写完不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交又存在丢失每天进度的巨大风险。
现在有了分支就不用怕了。你创建了一个属于你自己的分支别人看不到还继续在原来的分支上正常工作而你在自己的分
支上干活想提交就提交直到开发完毕后再一次性合并到原来的分支上这样既安全又不影响别人工作。
创建与合并分支
原理详细请戳这里
Git鼓励大量使用分支
查看分支git branch
创建分支git branch name
切换分支git checkout name
创建切换分支git checkout -b name
合并某分支到当前分支git merge name
删除分支git branch -d name
因为创建、合并和删除分支非常快所以Git鼓励你使用分支完成某个任务合并后再删掉分支这和直接在master分支上工作效
果是一样的但过程更安全。 解决冲突 这种情况下Git无法执行“快速合并”只能试图把各自的修改合并起来但这种合并就可能会有冲突如上图。
git status也可以告诉我们冲突的文件
$ git status
On branch master
Your branch is ahead of origin/master by 2 commits.(use git push to publish your local commits)You have unmerged paths.(fix conflicts and run git commit)(use git merge --abort to abort the merge)Unmerged paths:(use git add file... to mark resolution)both modified: readme.txtno changes added to commit (use git add and/or git commit -a)我们可以直接查看readme.txt的内容
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.HEAD
Creating a new branch is quick simple.Creating a new branch is quick AND simple.feature1Git用标记出不同分支的内容我们修改如下后保存
Creating a new branch is quick and simple.再提交
$ git add readme.txt
$ git commit -m conflict fixed
[master cf810e4] conflict fixed现在master分支和feature1分支变成了下图所示 用带参数的git log也可以看到分支的合并情况
$ git log --graph --prettyoneline --abbrev-commit
* cf810e4 (HEAD - master) conflict fixed
|\
| * 14096d0 (feature1) AND simple
* | 5dc6824 simple
|/
* b17d20e branch test
* d46f35e (origin/master) remove test.txt
* b84166e add test.txt
* 519219b git tracks changes
* e43a48b understand how stage works
* 1094adb append GPL
* e475afc add distributed
* eaadf4e wrote a readme file最后删除feature1分支
$ git branch -d feature1
Deleted branch feature1 (was 14096d0).工作完成。
解决冲突
小结
当Git无法自动合并分支时就必须首先解决冲突。解决冲突后再提交合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容再提交。
用git log --graph命令可以看到分支合并图。 分支管理策略
通常合并分支时如果可能Git会用Fast forward模式但这种模式下删除分支后会丢掉分支信息。
如果要强制禁用Fast forward模式即用--no-ff方式的git mergeGit就会在merge时生成一个新的commit这样从分支历史
上就可以看出分支信息。
如在master分支上合并dev分支请注意--no-ff参数表示禁用Fast forward
$ git merge --no-ff -m merge with no-ff dev
Merge made by the recursive strategy.readme.txt | 1 1 file changed, 1 insertion()因为本次合并要创建一个新的commit所以加上-m参数把commit描述写进去。
合并后我们用git log看看分支历史
$ git log --graph --prettyoneline --abbrev-commit
* e1e9c68 (HEAD - master) merge with no-ff
|\
| * f52c633 (dev) add merge
|/
* cf810e4 conflict fixed
...可以看到不使用Fast forward模式merge后就像这样 分支策略
在实际开发中我们应该按照几个基本原则进行分支管理
首先master分支应该是非常稳定的也就是仅用来发布新版本平时不能在上面干活
那在哪干活呢干活都在dev分支上也就是说dev分支是不稳定的到某个时候比如1.0版本发布时再把dev分支合并到
master上在master分支发布1.0版本
你和你的小伙伴们每个人都在dev分支上干活每个人都有自己的分支时不时地往dev分支上合并就可以了。
所以团队合作的分支看起来就像这样 小结
Git分支十分强大在团队开发中应该充分应用。
合并分支时加上--no-ff参数就可以用普通模式合并合并后的历史有分支能看出来曾经做过合并而fast forward合并就
看不出来曾经做过合并。 Bug分支
在Git中由于分支是如此的强大所以每个bug都可以通过一个新的临时分支来修复修复后合并分支然后将临时分支删除。
当你接到一个修复一个代号101的bug的任务时很自然地你想创建一个分支issue-101来修复它但是如果你当前正在dev上
进行的工作还没有提交并不是你不想提交而是工作只进行到一半还没法提交预计完成还需1天时间。但是必须在两个
小时内修复该bug怎么办
幸好Git还提供了一个stash功能可以把当前工作现场“储藏”起来等以后恢复现场后继续工作
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge现在用git status查看工作区就是干净的除非有没有被Git管理的文件因此可以放心地创建分支来修复bug。
修复完后切换回工作分支用git stash list命令查看之前保存的工作现场
$ git stash list
stash{0}: WIP on dev: f52c633 add merge工作现场还在Git把stash内容存在某个地方了但是需要恢复一下有两个办法
一是用git stash apply恢复但是恢复后stash内容并不删除你需要用git stash drop来删除
另一种方式是用git stash pop恢复的同时把stash内容也删了
$ git stash pop
On branch dev
Changes to be committed:(use git reset HEAD file... to unstage)new file: hello.pyChanges not staged for commit:(use git add file... to update what will be committed)(use git checkout -- file... to discard changes in working directory)modified: readme.txtDropped refs/stash{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)再用git stash list查看就看不到任何stash内容了
$ git stash list你可以多次stash恢复的时候先用git stash list查看然后恢复指定的stash用命令
$ git stash apply stash{0} Feature功能分支以及强制删除
软件开发中总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时你肯定不希望因为一些实验性质的代码把主分支搞乱了所以每添加一个新功能最好新建一个feature
分支在上面开发完成后合并最后删除该feature分支。
当然如果开发完后突然接到上级命令需要取消该功能虽然白干了但是这个包含机密资料的分支还是必须就地销毁
$ git branch -d feature-vulcan
error: The branch feature-vulcan is not fully merged.
If you are sure you want to delete it, run git branch -D feature-vulcan.销毁失败。Git友情提醒feature-vulcan分支还没有被合并如果删除将丢失掉修改如果要强行删除需要使用大写的-D参数。。
现在我们强行删除
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 287773e).终于删除成功 多人协作重要
当你从远程仓库克隆时实际上Git自动把本地的master分支和远程的master分支对应起来了并且远程仓库的默认名称是origin。
要查看远程库的信息用git remote
$ git remote
origin或者用git remote -v显示更详细的信息
$ git remote -v
origin gitgithub.com:michaelliao/learngit.git (fetch)
origin gitgithub.com:michaelliao/learngit.git (push)上面显示了可以抓取和推送的origin的地址。如果没有推送权限就看不到push的地址。
推送分支
推送分支就是把该分支上的所有本地提交推送到远程库。推送时要指定本地分支这样Git就会把该分支推送到远程库对应的远程分支上
$ git push origin master如果要推送其他分支比如dev就改成
$ git push origin dev但是并不是一定要把本地分支往远程推送那么哪些分支需要推送哪些不需要呢 master分支是主分支因此要时刻与远程同步 dev分支是开发分支团队所有成员都需要在上面工作所以也需要与远程同步 bug分支只用于在本地修复bug就没必要推到远程了除非老板要看看你每周到底修复了几个bug feature分支是否推到远程取决于你是否和你的小伙伴合作在上面开发。
抓取分支
多人协作时大家都会往master和dev分支上推送各自的修改。
现在模拟一个你的小伙伴可以在另一台电脑注意要把SSH Key添加到GitHub或者同一台电脑的另一个目录下克隆
$ git clone gitgithub.com:michaelliao/learngit.git
Cloning into learngit...
remote: Counting objects: 40, done.
remote: Compressing objects: 100% (21/21), done.
remote: Total 40 (delta 14), reused 40 (delta 14), pack-reused 0
Receiving objects: 100% (40/40), done.
Resolving deltas: 100% (14/14), done.当你的小伙伴从远程库clone时默认情况下你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看
$ git branch
* master现在你的小伙伴要在dev分支上开发就必须创建远程origin的dev分支到本地于是他用这个命令创建本地dev分支
$ git checkout -b dev origin/dev现在他就可以在dev上继续修改然后时不时地把dev分支push到远程
$ git add env.txt$ git commit -m add env
[dev 7a5e5dd] add env1 file changed, 1 insertion()create mode 100644 env.txt$ git push origin dev
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.gitf52c633..7a5e5dd dev - dev
你的小伙伴已经向origin/dev分支推送了他的提交而碰巧你也对同样的文件作了修改并试图推送
$ cat env.txt
env$ git add env.txt$ git commit -m add new env
[dev 7bd91f1] add new env1 file changed, 1 insertion()create mode 100644 env.txt$ git push origin dev
To github.com:michaelliao/learngit.git! [rejected] dev - dev (non-fast-forward)
error: failed to push some refs to gitgithub.com:michaelliao/learngit.git
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: git pull ...) before pushing again.
hint: See the Note about fast-forwards in git push --help for details.推送失败因为你的小伙伴的最新提交和你试图推送的提交有冲突解决办法也很简单Git已经提示我们先用git pull把最新的提交从origin/dev抓下来然后在本地合并解决冲突再推送
$ git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.git pull remote branchIf you wish to set tracking information for this branch you can do so with:git branch --set-upstream-toorigin/branch devgit pull也失败了原因是没有指定本地dev分支与远程origin/dev分支的链接根据提示设置dev和origin/dev的链接
$ git branch --set-upstream-toorigin/dev dev
Branch dev set up to track remote branch dev from origin.再pull
$ git pull
Auto-merging env.txt
CONFLICT (add/add): Merge conflict in env.txt
Automatic merge failed; fix conflicts and then commit the result.这回git pull成功但是合并有冲突需要手动解决解决的方法和分支管理中的解决冲突完全一样。解决后提交再push
$ git commit -m fix env conflict
[dev 57c53ab] fix env conflict$ git push origin dev
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git7a5e5dd..57c53ab dev - dev
因此多人协作的工作模式通常是这样 首先可以试图用git push origin branch-name推送自己的修改 如果推送失败则因为远程分支比你的本地更新需要先用git pull试图合并 如果合并有冲突则解决冲突并在本地提交 没有冲突或者解决掉冲突后再用git push origin branch-name推送就能成功
如果git pull提示no tracking information则说明本地分支和远程分支的链接关系没有创建用命令--set-upstream-toorigin/branch-name branch name。
这就是多人协作的工作模式一旦熟悉了就非常简单。
小结 查看远程库信息使用git remote -v 本地新建的分支如果不推送到远程对其他人就是不可见的 从本地推送分支使用git push origin branch-name如果推送失败先用git pull抓取远程的新提交 在本地创建和远程分支对应的分支使用git checkout -b branch-name origin/branch-name本地和远程分支的名称最好一致 建立本地分支和远程分支的关联使用git branch --set-upstream-toorigin/branch-name branch name 从远程抓取分支使用git pull如果有冲突要先处理冲突。 创建标签
在Git中打标签非常简单首先切换到需要打标签的分支上
$ git branch
* devmaster
$ git checkout master
Switched to branch master然后敲命令git tag name就可以打一个新标签
$ git tag v1.0可以用命令git tag查看所有标签
$ git tag
v1.0默认标签是打在最新提交的commit上的。有时候如果忘了打标签比如现在已经是周五了但应该在周一打的标签没有打怎么办
方法是找到历史提交的commit id然后打上就可以了
比方说要对add merge这次提交打标签它对应的commit id是f52c633敲入命令
$ git tag v0.9 f52c633再用命令git tag查看标签
$ git tag
v0.9
v1.0注意标签不是按时间顺序列出而是按字母排序的。可以用git show tagname查看标签信息
$ git show v0.9
commit f52c63349bc3c1593499807e5c8e972b82c8f286 (tag: v0.9)
Author: Michael Liao askxuefenggmail.com
Date: Fri May 18 21:56:54 2018 0800add mergediff --git a/readme.txt b/readme.txt
...可以看到v0.9确实打在add merge这次提交上。
还可以创建带有说明的标签用-a指定标签名-m指定说明文字
$ git tag -a v0.1 -m version 0.1 released 1094adb用命令git show tagname可以看到说明文字
$ git show v0.1
tag v0.1
Tagger: Michael Liao askxuefenggmail.com
Date: Fri May 18 22:48:43 2018 0800version 0.1 releasedcommit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (tag: v0.1)
Author: Michael Liao askxuefenggmail.com
Date: Fri May 18 21:06:15 2018 0800append GPLdiff --git a/readme.txt b/readme.txt
...注意标签总是和某个commit挂钩。如果这个commit既出现在master分支又出现在dev分支那么在这两个分支上都可以看到这个标签。 操作标签
如果标签打错了也可以删除
$ git tag -d v0.1
Deleted tag v0.1 (was f15b0dd)因为创建的标签都只存储在本地不会自动推送到远程。所以打错的标签可以在本地安全删除。
如果要推送某个标签到远程使用命令git push origin tagname
$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git* [new tag] v1.0 - v1.0或者一次性推送全部尚未推送到远程的本地标签
$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git* [new tag] v0.9 - v0.9如果标签已经推送到远程要删除远程标签就麻烦一点先从本地删除
$ git tag -d v0.9
Deleted tag v0.9 (was f52c633)然后从远程删除。删除命令也是push但是格式如下
$ git push origin :refs/tags/v0.9
To github.com:michaelliao/learngit.git- [deleted] v0.9要看看是否真的从远程库删除了标签可以登陆GitHub查看。
小结 命令git push origin tagname可以推送一个本地标签 命令git push origin --tags可以推送全部未推送过的本地标签 命令git tag -d tagname可以删除一个本地标签 命令git push origin :refs/tags/tagname可以删除一个远程标签。 忽略特殊文件
有些时候你必须把某些文件放到Git工作目录中但又不能提交它们比如保存了数据库密码的配置文件啦等等
好在Git考虑到了大家的感受这个问题解决起来也很简单在Git工作区的根目录下创建一个特殊的.gitignore文件然后把要忽略的文件名填进去Git就会自动忽略这些文件。
不需要从头写.gitignore文件GitHub已经为我们准备了各种配置文件只需要组合一下就可以使用了。所有配置文件可以直接在线浏览https://github.com/github/gitignore
忽略文件的原则是
忽略操作系统自动生成的文件比如缩略图等忽略编译生成的中间文件、可执行文件等也就是如果一个文件是通过另一个文件自动生成的那自动生成的文件就没必要放进版本库比如Java编译产生的.class文件
忽略你自己的带有敏感信息的配置文件比如存放口令的配置文件。
举个例子
假设你在Windows下进行Python开发Windows会自动在有图片的目录下生成隐藏的缩略图文件如果有自定义目录目录下就会有Desktop.ini文件因此你需要忽略Windows自动生成的垃圾文件
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini然后继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build加上你自己定义的文件最终得到一个完整的.gitignore文件内容如下
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build# My configurations:
db.ini
deploy_key_rsa最后一步就是把.gitignore也提交到Git就完成了当然检验.gitignore的标准是git status命令是不是说working directory clean。
使用Windows的童鞋注意了如果你在资源管理器里新建一个.gitignore文件它会非常弱智地提示你必须输入文件名但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。
有些时候你想添加一个文件到Git但发现添加不了原因是这个文件被.gitignore忽略了
$ git add App.class
The following paths are ignored by one of your .gitignore files:
App.class
Use -f if you really want to add them.如果你确实想添加该文件可以用-f强制添加到Git
$ git add -f App.class或者你发现可能是.gitignore写得有问题需要找出来到底哪个规则写错了可以用git check-ignore命令检查
$ git check-ignore -v App.class
.gitignore:3:*.class App.classGit会告诉我们.gitignore的第3行规则忽略了该文件于是我们就可以知道应该修订哪个规则。
小结 忽略某些文件时需要编写.gitignore .gitignore文件本身要放到版本库里并且可以对.gitignore做版本管理
