小明发现在实际项目开发过程中,总会遇到各种各样的情况,比如一个大型的项目或版本迭代可能不是一次上线,可能会分好几次上线,这时候就会涉及创建多个分支,分别开发. 项目背景 产品经理:我们本次开发三个功能,列表页功能.详情页功能.系统消息功能,分两次上线,先上列表功能,再上详情页和系统消息. 小明:好的吧. 紧接着,小明就将本次需求分为2个分支,分别为A.B. A:开发列表页功能 B:开发详情页功能.系统消息功能 原计划:产品经理说先上列表功能,那小明就先开发A分支,列表功能很快开发完成(厉害吧).

把不需要版本控制的文件提交到远程分支上后,需要删除远程分支上的文件,用以下操作即可: git rm -r –cached dirname //删除远程文件夹,但保留本地文件夹 git commit -m ‘say something’ //提交操作,并添加描述 git push origin master //推送

git提交项目时候踩的Git的坑 特别 由于准备春招,所以希望各位看客方便的话,能去github上面帮我Star一下项目 https://github.com/Draymonders/Campus-Shop 经历 由于刚开始没有设置.gitignore文件,导致项目中所有的文件都被提交到了github上面,由此带来的问题就是有些debug日志也被提交了上去,对于团队开发很不友好. 一个错误的尝试 git rm -r --cached "fileName/directionName" 执

删除git某个文件的所有历史记录 git的目的就是版本控制,记录每一个版本的变动.然而有的时候我们往往希望从版本库中彻底删除某个文件,不再显示在历史记录中.例如不小心上传了一堆错误的文件,或者不小心上传了帐号.密码,那么这个时候怎么办呢?下面的命令可以完美解决你的问题 $ git filter-branch -f --tree-filter 'rm -rf common/service/SyncBlogServince.php' HEAD $ git push origin --force 批量

创建并转入新分支:git checkout –b XX(其中XX代表分支名称) 将新分支发布在github上: git push origin Branch1 往分支中添加文件:git add master/XX(master中的XX文件)或者git add XX(XX文件) 添加文件注释:git commit –m “XX” push:git push –u origin XX(之前的分支名称) 或push:git push 合并分支:先转入到master分支git checkout mast

一.分支 # 查看分支 git branch # 创建分支 git branch 分支名 # 切换分支 git checkout name # 创建并切换分支 git checkout -b name # 删除分支 git branch -d 删除分支 # 创建dev分支并以线上的为蓝本 git branch dev origin/dev git checkout dev 创建成功后切换到dev # 在要合并到的分支上做merge合并 git merge 分支名 二.tag 里程碑,版本的意思

具体方法如下 git pull origin 分支 //出现错误 git stash  缓存起来 git pull origin 分支 git stash pop //还原 git stash clear 参考资料: http://www.01happy.com/git-resolve-conflicts/ 开发人员常常遇到这种情况:花了几天时间一直在做一个新功能,已经改了差不多十几个文件,突然有一个bug需要紧急解决,然后给一个build测试组.在Git问世之前基本上靠手动备份,费时且容易出错

Git 保存的不是文件差异或者变化量,而只是一系列文件快照. 在 Git中提交时,会保存一个提交(commit)对象,它包含一个指向暂存内容快照的指针,作者和相关附属信息,以及一定数量(也可能没有)指向该提交对象直接祖先的指针.当使用 git commit 新建一个提交对象前,Git 会先计算每一个子目录(本例中就是项目根目录)的校验和,然后在 Git 仓库中将这些目录保存为树(tree)对象.之后 Git 创建的提交对象,除了包含相关提交信息以外,还包含着指向这个树对象(项目根目录)的指针,如

git merge 用来做分支合并,将其他分支中的内容合并到当前分支中.比如分支结构如下: master / C0 ---- C1 ---- C2 ---- C4 \ C3 ---- C5 \ issueFix 当前分支是master$ git checkout master 把issueFix中的内容Merge进来:$ git merge issueFix 如果没有冲突的话,merge完成.有冲突的话,git会提示那个文件中有冲突,比如有如下冲突: <<<<<<<

创建发布分支: (1) 软件hello-world的1.0发布版本库中有一个里程相对应. /home/jackluo/workspace/user1/workspace/hello-worldgit tag -n1 -l v* (2)基于里程v1.0创建发布布hello-1.x. 注:使用了git checkout 命令创建分支,最后一个参数v1.0是新分支 hello-1.x创建的基准点,如果没有里程,使用提交ID也是一样 [root@localhost hello-world]# git t

开发者user1 负责用getopt 进行命令解析的功能,因为这个功能用到getopt 函数,于是将这个分支命名为user1/getopt.(1)确保是在开发者user1的工作区中cd /home/jackluo/workspace/user1/workspace/hello-world(2)开发者user1 基于当前HEAD创建分支user1/getopt.git branch user1/getopt(3)使用 git branch创建分支,并不会自动切换.查看当前分支可以看到仍然工作在ma

关于版本控制 git是一种分布版本控制系统,每一主机都保存了完整副本.必杀技是分支. 在Windows可安装git客户端msysgit. git基础 第一次看progit觉得有点不懂,不懂版本控制,一条条命令写的觉得很麻烦没头绪.这次在看了向导guides.github.com之后,文章避免了一些细枝末节的命令,而是介绍工作流程,懂了一点工作大概流程再开始使用命令比较合适. 三种状态 工作目录.暂存区域.git目录 工作目录就是你打开文件夹看到可见目录.暂存区域含有添加(add)之后的文件.gi

转自:http://www.cnblogs.com/jackluo/p/3499731.html 开发者user1 负责用getopt 进行命令解析的功能,因为这个功能用到getopt 函数,于是将这个分支命名为user1/getopt.(1)确保是在开发者user1的工作区中cd /home/jackluo/workspace/user1/workspace/hello-world(2)开发者user1 基于当前HEAD创建分支user1/getopt.git branch user1/get

分支管理策略 通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息.如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息(有分支的commit id).下面我们实战一下--no-ff(ff:fast forward)方式的git merge:首先,仍然创建并切换dev分支:

分支在实际中有什么用呢? 你创建了一个属于你自己的分支,别人看不到,别人还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作. 在版本回退里,我们已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支.截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支.HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支

Git新建本地分支与远程分支关联问题:git branch --set-upstream git在本地新建分支, push到remote服务器上之后,再次pull下来的时候,如果不做处理会报以下提示: You asked me to pull without telling me which branch you want to merge with, and 'branch.production.merge' in your configuration file does not tell m

http://blog.csdn.net/pipisorry/article/details/47867097 查看文件的修改历史 git log --pretty=oneline 文件名 # 显示修改历史[Git高级教程:git log与git reflog] git show 356f6def9d3fb7f3b9032ff5aa4b9110d4cca87e # 查看更改 历史版本对比 查看日志git log 查看某一历史版本的提交内容git show 4ebd4bbc3ed321d01484

前言 无论是开源项目还是内部项目,使用Git都是大势所趋,尤其是在产品管理这块,使用Git大大提高了开发效率和产品的交付频率.本篇,针对Git的工作流和分支使用,进行了一些推荐. 目录 1     产品管理开发之Git工作流和分支规范推荐 1.1      Git工作流模型推荐 1.2      Git产品开发分支规范要求 1.2.1      永久分支 1.2.1.1  master(稳定版) 1.2.1.2   开发版(develop) 1.2.2      临时性分支 1.2.2.1  

当我们进行程序开发的过程中,有时会产生一个新的想法,然后就想马上试验,那我们怎么办? 如果我们继续在现有的基础上进行开发,但最后想法不成功,我们还要进行版本回退?如果我们的新想法,需要很长时间才能实现呢?我们其它的功能还要不要进行开发?最后就是如果有bug,我们修复bug,这有时也需要较长时间,我们还是在现有基础进行开发,如果修改不成功或引入的新的bug 怎么样? 这时就要引入分支的概念,当我们进行新功能开发或者修复bug的时候,在新的分支上进行开发, 它不会影响现有的代码. 分支,可以按照现实

Git仓库删除大文件 背景 当用Git久了,难免会手误或临时添加一些大文件到仓库中,即使以后添加进了.gitignore,甚至做了git rm,但是Git为了保证版本可回退,history pack里面依然会存储这些对象,这个时候我们就要为Git仓库进行瘦身. 或者不是大文件的情况,有时我们需要删除掉一些敏感信息文件,比如password.txt,即使回退也无法找到敏感文件,要实现这个要求,也要对history pack进行清理. 清理主要做如下一些事情: 寻找想要彻底清理的文件路径 查询这个文