Git学习笔记五--分支管理】的更多相关文章

为什么要引入分支? 分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了.如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险. 现在有了分支,就不用怕了.你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作. 查看分支:git branch 创建分…
1.用户与组账号 用户账号:包括实际人员和逻辑性对象(例如应用程序执行特定工作的账号) 每一个用户账号包含一个唯一的用户 ID 和组 ID 标准用户是系统安装过程中自动创建的用户账号,其中除 root 是管理者外,其余的都是系统账号 组账号:组是逻辑性单元,用来集合特定的用户,以便于其中的所有成员对文件具有相同的访问权限 标准组是系统自动添加的,其中除 root 组用来组织管理者外,其余的供程序执行时使用 2.账号信息 (1)用户账号信息 有关用户账号的信息都记录在 /etc/passwd 文件…
Git用Fast forward模式(快进模式),但这种模式下,删除分支后,会丢掉分支信息. 如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息. 下面我们实战一下--no-ff方式的git merge: $ git merge --no-ff -m "merge with no-ff" dev 可以看到,不使用Fast forward模式,merge后就像这样: 分支策略 在实际开发中,我们应该按照几个基…
软件开发中,bug就像家常便饭一样.有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除. 当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101来修复它,但是,等等,当前正在dev上进行的工作还没有提交: $ git status On branch dev Changes to be committed: (use "git reset HEAD <file&…
每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支.截止到目前,只有一条时间线,这个分支叫主分支,即master分支,HEAD指向master,master指向提交,所以,HEAD指向的就是当前分支.每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长. 当我们创建新的分支dev时,git新建了一个指针叫dev,指向master相同的提交,同时把HEAD指向dev,就表示当前分支在dev上,不过,从现在开始,对工作区的修改和提交就是针对de…
1.创建与合并分支 一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点: 每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长: 当我们创建新的分支,例如dev时,Git新建了一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev上: 你看,Git创建一个分支很快,因为除了增加一个dev指针,改改HEAD的指向,工作区的文…
当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101来修复它,但是,等等,当前正在dev上进行的工作还没有提交: 并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需1天时间.但是,必须在两个小时内修复该bug,怎么办? 幸好,Git还提供了一个stash功能,可以把当前工作现场"储藏"起来,等以后恢复现场后继续工作: $ git stash 现在,用git status查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以…
来源:廖雪峰 通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息. 如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息. git merge --no-ff -m "merge with no-ff" dev 合并dev分支,请注意--no-ff参数,表示禁用Fast forward,因为本次合并要创建一个新的commit,所以加上-m参数,把com…
发布一个版本时,我们通常先在版本库中打一个标签(tag),这样,就唯一确定了打标签时刻的版本.将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来.所以,标签也是版本库的一个快照. Git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的. 在Git中打标签非常简单,首先,切换到需要打标签的分支上: $ git branch * dev master $ git check…
软件开发中,总有无穷无尽的新的功能要不断添加进来. 添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支. 现在,你终于接到了一个新任务:开发代号为Vulcan的新功能,该功能计划用于下一代星际飞船. 于是准备开发: $ git checkout -b feature-vulcan Switched to a new branch 'feature-vulcan' 5…