git-分支使用方式

需求场景:假如你看着教程完成了一个项目，但是感觉第一次代码掌握不牢，想要进行第二次代码练习--如果某某心里想我还有初始备份文件，我此时的心里独白是你的硬盘还够用吗o(╯□╰)o

1 创建一个新分支 --git本地仓库默认是master分支 但是这分支最好只用来合并（merge）其他分支到这个分支上

2 查看现在所有的分支

chang是我用来做完一个项目的分支，master仅仅用来合并其他分支 此时change分支代码已经写完

3 效果展示

3.1 先切换的change分支看完整的代码是否还在

完整的代码还在

3.2 切换到想进行第二次练习的分支

4 需求完成--mama再也不用担心我硬盘里面不够放（教学）视频了...

时间： 2024-10-07 00:09:33

git-分支使用方式的相关文章

[廖雪峰] Git 分支管理策略

通常,合并分支时,如果可能,Git 会用 Fast forward 模式,但这种模式下,删除分支后,会丢掉分支信息. 如果要强制 禁用 Fast forward 模式,Git 就会在 merge 时生成一个新的 commit,这样,从分支历史上就可以看出分支信息. 下面我们实战一下 --no-ff 方式的 git merge: 首先,仍然创建并切换 dev 分支: $ git checkout -b dev Switched to a new branch 'dev' 修改 readme.txt

GIT 分支管理：分支管理策略、Bug分支、Feature分支

通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息. 如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息. 下面我们实战一下--no-ff方式的git merge: 首先,仍然创建并切换dev分支: $ git checkout -b dev Switched to a new branch 'dev' 修改readme.txt文件,并提交一个新的commit

Git详解之三 Git分支

相关文档 — 更多 Git 基础培训.ppt GIT 使用经验.ppt GIT 介绍.pptx GIT 分支管理是一门艺术.docx Eclipse上GIT插件EGIT使用手册.docx git/github学习笔记.doc git 版本控制系统.docx Git开发管理之道.pdf Git内部培训资料.pptx Git权威指南-第5篇-第32章-Gerrit.pdf Gitolite 构建 Git 服务器.pdf 版本控制之道 - 使用Git.pdf Git使用指南(中文).pdf Git-C

GIt分支管理策略

大纲: 1.前言 2.创建分支 3.切换分支 4.合并分支(快速合并) 5.删除分支 6.分支合并冲突 7.合并分支(普通合并) 8.分支管理策略 9.团队多人开发协作 10.总结 注,测试机 CentOS 5.5 x86_64,Git 服务器版本:git version 1.8.2.1,客户端版本:git version 1.9.2.msysgit.0.所有软件请到这里下载:http://msysgit.github.io/. 1.前言 在上一篇博客中我们主要讲解了Git 远程仓库,相信大家对

（转载）介绍一个成功的 Git 分支模型

介绍一个成功的 Git 分支模型 在这篇文章中,我提出一个开发模型.我已经将这个开发模型引入到我所有的项目里(无论在工作还是私人)已经一年有余,并且它被证明是非常成功的.我打算写这些已经很久了,但我一直找不到时间来做,现在终于有时间了.我不会讲任何项目的具体细节,仅是关于分支策略和释放管理相关内容. 它主要体现了Git对我们源代码版本的管理. 为何是Git? 对于Git与其他集中式代码管理工具相比的优缺点的全面讨论,请参见这里.这样的争论总是喋喋不休.作为一个开发者,与现今的其他开发工具相比较,

GIT 分支的理解

乎所有的版本控制系统都以某种形式支持分支. 使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响开发主线. 在很多版本控制系统中,这是一个略微低效的过程——常常需要完全创建一个源代码目录的副本.对于大项目来说,这样的过程会耗费很多时间. 分支简介 为了真正理解 Git 处理分支的方式,我们需要回顾一下 Git 是如何保存数据的. 或许你还记得 起步 的内容,Git 保存的不是文件的变化或者差异,而是一系列不同时刻的文件快照. 在进行提交操作时,Git 会保存一个提交对象(commit o

Git分支合并选择

用Git进行多人协作开发时,必然会合并代码,解决冲突.然而合并代码也是需要点技巧的,如果对一些关键命令没有理解去使用的话,git的版本演进路线就会变得很乱,从而造成了日后维护的一些麻烦. Git上合并代码有git merge 以及 git rebase 两种方式.下面将深入两者的用法以及对两者的适用场景作个总结. 前置知识点 Master分支:首先,代码库应该有一个.且仅有一个主分支.所有提供给用户使用的正式版本,都在这个主分支上发布.这个分支被称为Master分支: Develop分支:主分支

Git分支的前世今生

导读 几乎所有的版本控制系统都以某种形式支持分支. 使用分支意味着你可以把你的工作从开发主线上分离开来,以免影响开发主线. 在很多版本控制系统中,这是一个略微低效的过程--常常需要完全创建一个源代码目录的副本.对于大项目来说,这样的过程会耗费很多时间. 1.1 Git 分支 - 分支简介 有人把 Git 的分支模型称为它的"必杀技特性",也正因为这一特性,使得 Git 从众多版本控制系统中脱颖而出. 为何 Git 的分支模型如此出众呢? Git 处理分支的方式可谓是难以置信的轻量,创建

【转】一个成功的Git分支模型 .

---恢复内容开始--- 能力所限,本文的翻译多处都很不地道,如果哪些地方难于理解,还烦请查看原文.—— Dbzhang800 20110921 在本文中,我向大家介绍的是在大约一年前我为自己的项目(包括工作和私人项目)引入的且已被证实非常成功的一个开发模型(development model).这段时间我一直想写点关于它的东西,但在此之前,我却从未能抽出充足的时间来完成这件事.我不会谈论项目的任何细节,只涉及分支策略(branching strategy)和发布管理(release manag

git学习——<五>git分支

git学习——<一>git安装 git学习——<二>git配置文件 git学习——<三>git操作 git学习——<四>git版本管理 一.提出问题 今天开发的过程中遇到一个问题,A组接到开发任务要修改file文件,B组在此之前的15天为了完成自己的开发任务对file文件进行了修改,为了同步代码,B组将自己未完成的模块file文件提交到了cvs上.A对此一无所知,A组在完成开发任务后,把file文件完全上到了现网环境,报错了. 当然,避免上述问题的途径很多,