1. 为什么Android项目离不开Git分支管理先抛一个我早年踩过的场景入职第一家公司接手一个迭代了三年、代码量几十万的Android项目团队七八个人同时在这个工程上开发。当时带我的组长丢给我一句你拉个分支做登录模块重构。我打开Android Studio盯着右下角那个写着master的按钮愣了半天——拉分支拉什么分支拉了之后别人还能看到我的代码吗我改到一半他们会不会被我搞坏这种困惑在刚接触Git的Android开发者里太常见了。大家在学校或自己写Demo时都是单打独斗一个master分支从头提交到尾最多commit多写几条。但真实项目完全是另一回事可能有三个版本的线上bug要紧急修复有两个人同时在改同一个Activity有一个人在大胆重构核心网络层还有一个人在研究升级minSdkVersion。如果没有分支管理这些工作全部堆在一条线上任何一个人的半成品代码都会直接影响所有人项目会瞬间陷入混乱。Git分支解决的核心问题有两个。第一是隔离每个人在独立的分支上干活互不干扰代码写得再烂也不影响主线的正常运行。第二是合流当某个功能完成并验证通过后再通过合并操作把成果汇入主分支让团队共享。对于Android项目分支尤其重要还有一层原因Android工程的构建链路比较重涉及资源编译、依赖拉取、NDK编译等多种环节动辄几分钟的构建时间让团队不可能频繁地试错。分支隔离配合合理的工作流能最大程度减少无谓的构建等待和冲突产生。很多初学者对分支有一个常见误解以为分支是把代码复制了一份。实际上Git的分支只是一个指向某个提交commit的可移动指针创建分支几乎不消耗任何空间和时间。这也是为什么Git鼓励多用分支、常开分支——它的成本极低带来的秩序收益却极高。这篇文章的内容主线很明确从环境准备开始到新建分支、切换分支、合并分支、提交推送的每一个动作我都会结合Android Studio的图形界面和Git命令行两种方式拆开讲最后用一个完整的功能开发周期串一遍。你能拿到的不仅是点哪里的操作步骤更是每一步背后的原理和容易踩的坑。2. 动手前先把环境理顺让Android Studio找到Git并认出项目很多人在分支操作上翻车不是不会点按钮而是环境根本没配好。Android Studio里的Git功能依赖两个层面的条件电脑上安装并配置好Git以及Android Studio能正确识别并启用当前项目的Git管理。2.1 安装与配置Git的细节Android Studio不像Visual Studio那样自带Git它只是Git客户端。所以第一步是确保本机装了Git。这块补一句macOS上通过Xcode Command Line Tools可能会自动带上Git但版本可能偏老Windows上需要去官网下载安装包。安装过程中有几个别乱动的选项——安装路径建议保持默认PATH环境不要选仅Git Bash使用要选从命令行使用Git那一项否则Android Studio内部调用git命令时会找不到。装完之后打开终端或命令行工具快速验证一下git --version能打出版本号就说明Git本体OK。然后设置全局身份信息。这一步经常被跳过但没做的话会导致提交记录里缺作者信息或者更麻烦——单元测试里如果依赖提交作者做判断时会出问题git config --global user.name 你的名字 git config --global user.email 你的邮箱2.2 Android Studio中启用版本控制打开Android Studio后依次进入File - SettingsmacOS上是Android Studio - Preferences在左侧找到Version Control - Git检查Path to Git executable栏是否自动识别到了git.exeWindows或/usr/bin/gitmacOS/Linux。有一个反常现象值得注意有时候路径栏是空白的但命令行里git用得好好的人也会遇到。这种情况通常不是没装而是Android Studio没有找到可执行文件。点右边的Test按钮如果能弹出Git executed successfully说明链接正常如果报错手动点浏览按钮定位到Git的可执行文件再重新测试。接下来确认项目本身是否被Git接管。如果你是从Android Studio里直接Clone或Check out from Version Control拉下来的项目Android Studio会自动识别。如果是自己从零Start一个新项目并且没有勾选创建Git仓库的选项那项目根目录下没有.git文件夹Git功能区是空的。判断方法很简单打开项目根目录看有没有.git文件夹或者在Android Studio里按下快捷键Alt 9打开Version Control工具窗口能正常显示提交历史就说明没问题。如果没有.git目录在根目录执行以下命令完成初始化git init再说一个实操中容易出问题的点Android Studio的项目结构是嵌套的。有些朋友把工程直接放在某个已有的Git仓库的子目录下或者在一个仓库里同时塞了前端和后端代码Android Studio在检测项目根目录时会找错仓库位置。建议一个Android项目对应一个独立的Git仓库根目录避免跨目录的混乱。2.3 远程仓库连接与身份认证分支操作往往会用到远程仓库所以接下来需要确认本地仓库和远程仓库GitLab、GitHub、Gitee都行之间的连接。在Android Studio的终端面板或者系统终端里查看git remote -v能正常显示origin的fetch和push地址说明远程仓库已关联。如果没有用以下命令添加git remote add origin gitgithub.com:yourname/yourproject.git这里我强烈建议优先使用SSH方式而不是HTTPS方式连接远程仓库。一方面SSH方式在每次提交和拉取时不需要反复输入账号密码另一方面在自己电脑上提前配置好SSH密钥后面所有基于Android Studio的远程分支操作都会顺畅很多不会莫名其妙卡在认证弹窗上。SSH密钥的生成和配置很简单打开终端ssh-keygen -t ed25519 -C 你的邮箱一路上回车到底然后在~/.ssh/id_ed25519.pub文件里复制公钥内容贴到代码托管平台的SSH Keys设置页。测试连通性ssh -T gitgithub.com看到successfully authenticated之类的提示就说明认证OK。到这里环境就算真正理顺了。接下来进入正题——分支操作。3. 新建分支界面操作与命令行双路径解析新建分支是分支使用中最简单也最频繁的操作但它有两个前置问题值得先弄清楚从哪里新建新建之后身在何处3.1 分支来源与指针概念新建分支必须指定一个起点这个起点通常是一个存在的分支的最新提交也可以是一个历史提交的哈希值还可以是某一个标签。默认情况下Git会在当前所处分支的最新提交上拉出新分支。这里必须理解Git分支的本质。前面说了分支就是一个指针它指向某个提交对象。当你新建分支A和分支B它们一开始指向同一个提交所以两个分支的代码内容完全相同。随着你在A分支上提交了新代码A指针向前移动B指针仍然停留在原地——于是这两个分支的代码就开始出现差异了。当前在哪个分支这个概念在Git里用HEAD来表示HEAD可以理解为当前所处位置的标记。在Android Studio的图形界面上新建分支有两个入口。最常用的位置是右下角的状态栏那里显示着当前分支名比如master点击它会弹出一个Git分支菜单菜单列表会展示所有本地分支和远程分支选择New Branch输入新分支名即可弹出的窗口里有两个复选框Checkout branch和Track remote。前者表示新建后立刻切换到这个分支上后者表示关联一个同名的远程分支。实际操作中绝大多数情况下我们都会勾选Checkout branch因为开一个新分支就是为了马上去它上面干活。3.2 图形界面的完整操作步骤我用一个具体需求来说明假设当前在master分支上需要新建一个feature/video-detail-redesign分支来开发视频详情页改版。操作步骤是点击右下角当前分支名此时显示master在弹出的分支菜单里选择New Branch输入分支名feature/video-detail-redesign勾选Checkout branch点击Create等待右下角分支名变成新分支名就完成了。这里有几个注意事项。第一分支名不能含有空字符等特殊符号团队内通常有命名规范后面会讲。第二新建分支前最好确认工作区是干净的即当前没有未提交的改动否则新分支会把工作区里未提交的改动一起带过去。这个概念起初容易让人困惑后面切换分支时会细致讲。3.3 命令行操作与对应关系熟练之后命令行方式在很多场景下比图形界面更高效尤其是在多个分支快速切换、写脚本、或者在服务器处理问题时。新建分支的常用命令# 基于当前分支新建但不切换 git branch feature/login-module # 新建并立即切换老命令兼容性好 git checkout -b feature/login-module # 新建并立即切换新命令语义更清晰 git switch -c feature/login-modulegit switch是在Git 2.23之后引入的新命令把切换分支这一工作从git checkout中分离出来。对于初学者我更推荐用git switch因为语义明确——switch听起来就是切换不会和git checkout 文件这种恢复文件的用法混淆。Android Studio内置的Git版本通常都够新放心大胆用。查看所有分支git branch -a-a参数会显示本地分支加远程分支用remotes/origin前缀区分。当前所在分支前面会有一个星号*同时分支名之后还会标注与对应远程分支的对比状态非常直观。3.4 分支命名规范一张团队协作的隐形契约分支命名看起来是小事但在多人协作中它是降低沟通成本的重要手段。我看到很多年轻的Android开发开分支时随意起名什么test、new1、fix过了两周自己都忘了这个分支是干嘛的。以下是目前Android团队里很常见的一套分支命名约定前缀用途示例feature/新功能开发feature/push-notificationbugfix/缺陷修复bugfix/crash-on-splashhotfix/线上紧急修复hotfix/1.2.3-login-failrelease/发布准备分支release/2.0.0-betachore/工具、配置类改动chore/update-gradle-version这种命名的好处是一看到分支名就知道它的性质结合项目管理工具比如Jira或TAPD的单号还能在分支名里加上任务编号比如feature/APP-2381-video-detail-redesign。大多数团队还会要求每次提交信息里带上单号这样后续回溯代码时会非常方便。4. 切换分支工作区管理是真正的坎新建分支之后接下来的高频操作就是切换分支。写代码时切分支是最基础的动作但也是翻车率最高的动作。这个场景在Android开发里尤其常见你正在feature分支改一个网络请求逻辑产品突然说线上有个崩溃要马上修你得切到hotfix分支去改。4.1 未提交改动会给切换带来什么Git的底层原理决定了切换分支时要保证某个前提如果你当前分支上有未提交的修改切到另一个分支时这些修改默认会被带到目标分支前提是目标分支的这些文件没有被修改过。如果两边都对同一个文件做了不同的修改Git会拒绝切换报下面这个经典的错误error: Your local changes to the following files would be overwritten by checkout: app/src/main/java/.../MainActivity.java Please commit your changes or stash them before you switch branches.看到这个提示不要慌它说明Git保护了你的工作成果。此时你有几个选择提交当前修改到当前分支如果改动完整、逻辑自洽用git stash暂存当前改动切换完分支干完活之后再切回来git stash pop恢复放弃当前改动慎用除非确实不想要了git stash是处理突然切换分支的救命稻草。在Android Studio里你可以通过VCS - Git - Stash Changes来暂存命令行方式git stash # 切去别的分支干活回来之后 git stash pop我个人的习惯是只要分支上的改动还没到可以提交的程度而我又必须切走就顺手git stash。安全第一语法是肌肉记忆。4.2 切换分支时构建状态的处理Android项目和纯后端项目不太一样切换分支后Gradle增量编译常常会检测到文件变化然后触发重新编译。但有一个隐藏问题容易让人困惑——切换分支后有时候Android Studio里的代码显示还是旧内容或者构建报出奇奇怪怪的错误。这通常不是Git的问题而是IDE的缓存和Gradle构建缓存没有完全刷新。我踩过最典型的一次坑是在分支A里给build.gradle加了一个依赖切到分支B后发现所有代码都正常但运行项目时Gradle竟然还在尝试解析那个不存在的依赖。后来我把范围内的问题确定在构建缓存上。应对办法很朴素切换分支后如果发现显示异常或构建异常先执行File - Sync Project with Gradle Files或者直接点大象图标重新同步。如果还不行用Build - Clean Project再不行就File - Invalidate Caches / Restart。多数情况下这三板斧能解决99%的切了分支但IDE界面/构建状态停留在旧分支的问题。4.3 游离的HEAD状态另一个在切换分支时会遇到的概念是游离HEADdetached HEAD。在Android Studio里点击历史提交记录里某一个具体的提交版本然后选择Checkout就会进入这个状态。这个状态下HEAD不再指向某个分支的最新提交而直接指向一个具体的提交对象。如果此时新建分支新分支会以这个历史提交为起点如果此时直接提交这个提交不属于任何分支一旦切走就可能丢失。对于大多数日常开发不需要主动进入游离HEAD状态。如果手滑进去了用git switch 分支名就能回到某个正经分支上。如果想基于当前游离状态创建一条新分支执行git switch -c new-branch-name这个游离HEAD概念我没有展开太多因为在实际Android项目开发中真正需要它的时候极少。但理解它有助于搞懂分支是指针这个本质。5. 合并分支冲突才是真正的考试新建分支、切换分支都相对简单真正有含金量的是合并。合并的核心逻辑是把某个分支上所做的修改合到另一个分支上。5.1 合入方向先想清楚谁合并谁最常见的错误是方向搞反。假设你要把自己开发的feature/payment分支合并到master或develop、main需要先切到master分支再执行合并feature/payment操作命令是git switch master git merge feature/payment为什么是这个顺序因为git merge语义是把指定的分支合并到我当前所处的分支。用图形界面也一样先切到目标分支再选中源分支并选择Merge into Current。这个方向搞反了首先不会报错但会把还没有验证过的新功能代码直接拉进你的当前分支。轻则被同事吐槽重则污染了别人的开发基线。在Android Studio中执行合并的完整路径是切换到目标分支比如master菜单栏VCS - Git - Merge Branches在弹出的对话框里选择要合入的源分支点击Merge还有一个快速入口在右上角或右下角的分支菜单里切换到目标分支后在分支列表里右键点击源分支选择Merge into Current。5.2 合并过程的三类结果合并无非三种结果第一类直接快进合并Fast-forward。当源分支的最近提交是目标分支的后续提交且目标分支没再往前走Git直接把目标分支指针移动到源分支的位置。这样合并的结果是一条直线历史看不到合并痕迹的提交节点。第二类三方合并Merge commit。两个分支各自有新提交产生了分叉。Git会把两个分支共同祖先的版本、目标分支版本、源分支版本三方进行比较尝试自动合并合并成功后生成一个新的Merge Commit。第三类冲突Conflicts。三方比较时发现同一文件的同一区域在两边的改动无法自动协调Git停下来等你决策。在Android项目里冲突高发的文件不出意外是以下几个AndroidManifest.xmlapp/build.gradle中的dependencies块多个开发者都修改过的Activity或Fragment文件包含大量模块依赖的settings.gradle5.3 Android Studio合并冲突解决实战我在真实项目中解决了一次典型的build.gradle冲突来讲清楚整个处理链路。情况是同事在feature/push分支给dependencies里加了implementation org.greenrobot:eventbus:3.3.1而我在feature/profile分支为了调试给另一个模块加了同样的依赖。执行合并后Android Studio弹出VCS Merge对话框冲突文件列表里出现了app/build.gradle。双击打开后界面上方有三个面板左侧是本地版本Local即目标分支的内容中间是合并结果Merge result可以手动编辑右侧是远程版本Remote即源分支的内容最底下还有一个展示两个版本差异的视图。解决的过程就是逐段审查决定保留哪边、删除哪边。对于我这个案例两边加的依赖不冲突最终结果是两个都保留。特别提醒一个高发坑XML布局文件和resources资源文件冲突。两个同事同时往同一个layout文件里加控件Git的自动合并有时能强行拼出一个文件来但很可能把标签结构搞乱。这时候不一定要在Merge对话框里死磕代码可以考虑采取朴素策略——手上有完整的一方代码时手动把另一边的内容加回来会更靠谱。具体操作上可以先通过git checkout --ours或git checkout --theirs做整体选择再在IDE里精确比对调整。在合并对话框里修改完成后要点Apply然后完善Merge Commit的说明文字。Android Studio通常会自动填入一条类似Merge branch feature/push into master的消息一般不用改。5.4 合并完成后必须做的验证这是我反复和团队成员强调的合并完成后不要急着推远程先跑一套验证。Android项目尤其要跑这些Build - Make Project确认能编译过跑一次lint检查Analyze - Inspect Code确认没有引入明显代码问题针对涉及功能跑一遍单元测试或手动冒烟因为合并是风险最高代码变更动作之一自动合并认为没问题不代表业务逻辑没受影响。尤其是两个人都改了同一个逻辑分支附近的地方。6. 提交与推送好提交是给未来自己写说明书分支做得再漂亮最终都要通过提交commit和推送push沉淀到版本库。很多初学者会忽视提交的质量问题看到git commit就当作保存一下这是大误区。6.1 提交的时机与粒度经常有人问多久提交一次比较好我的经验法则是一个逻辑独立的小改动就提交一次。比如修复了一个空指针问题、完成了一个网络接口对接、调整了一个页面布局都是合适的提交单元。千万不要把改了十几个文件的所有改动打成一个提交。这样的提交有几个问题出问题时无法精准回滚到某个具体改动代码评审时别人没法针对小改动做review冲突解决时定位差异非常痛苦在Android Studio中对要提交的内容做精细控制有个很好用的功能在Version Control工具窗口的Local Changes列表中可以右键每个文件选择Diff查看改动也可以在提交对话框里勾选/取消某个文件的提交状态。6.2 Commit Message的写法提交信息是给未来的自己和其他人看的说明书。我在这个上面吃过亏刚工作时提交信息全是fix、update、提交这种废话三个月后再看代码根本回忆不起来当时改了什么。现在比较流行的规范是Conventional Commits格式大致为type[optional scope]: description [optional body]类型常见的有type含义feat新功能fix修复bugrefactor重构不改行为docs文档test测试chore构建、工具链等杂项比如feat(login): 新增手机号验证码登录 修复了几次验证码校验的竞态问题补充了相关单元测试在Android Studio的Commit工具窗口里写好信息后可以点击右上角的commit按钮右侧小箭头选择Commit and Push直接推送到远程。6.3 Push、Push前务必Pull推送是把本地提交传到远程仓库的过程。推送本身不难难的是推送失败的情况。最常见的失败原因是在你本地提交之前的这段时间里远程分支上已经有别人推了新提交。Git会拒绝你push要求先拉取pull再推送。这里就引出一个习惯在推送前最好先看下本地和远程的状态差异。我说一个很少被教程提到但很实用的操作顺序先git status确认干净用git pull --rebase把远程提交拉下来再git push为什么要用--rebase而不是默认的merge拉取因为Android工程里如果用merge方式拉取远程提交会多出一个Merge remote-tracking branch提交节点会让提交历史变得杂乱。--rebase会把你在本地的提交移到远程最新提交的后面历史是干净的一条线。但--rebase有一个注意点如果本地修改的文件和远程修改的文件重叠很多rebase过程中也会需要解决冲突且处理方式比merge更考验逻辑因为要逐个commit进行重放。新手如果倾向于简单省事用普通pull也未尝不可但要有接受额外Merge提交的心理预期。Android Studio里执行pull的方式同样很顺滑VCS - Git - Pull在对话框里选择远程仓库、分支名、rebase/merge策略点Pull。不过说句实在话用命令行git pull --rebase在操作感和可控性上更干脆建议并行使用。6.4 把本地分支推送到远程本地新建的分支默认不会自动出现在远程仓库。当你需要和别人协作这个分支或者想备份这个分支时需要推送git push -u origin feature/payment这里的-u--set-upstream参数表示建立本地分支和远程同名分支的追踪关系。第一次推送后以后只要执行git push就能自动推到目标远程分支。Android Studio的爽点在这里当你点击推送按钮时它会弹出一个智能的Push对话框自动检测到你没有对应的远程分支并建议执行git push -u origin feature/payment。你只要点确认Source和Destination分支名都可以改一般默认即可。推送之后其他人就可以在你的分支上继续开发或者发起合并请求Merge Request / Pull Request来把它合入主分支。6.5 撤销与补救操作提交总会出错这里我必须专门说一个很多人都会踩的坑不要把不该提交的大文件、密钥文件、构建产物提交到仓库。Android工程里最典型的是app/build/目录下的中间产物local.properties里的SDK路径每台电脑不同各种签名工具的keystore文件.gradle/缓存目录正确的做法是在仓库根目录添加.gitignore文件。Android Studio创建新项目时默认会生成一份完整的.gitignore但如果你是手动导入的项目或者刚开始用Git管理老项目可能缺这个文件。最好自己检查确认。下面是Android项目最基础的一份ignore模板*.iml .gradle /local.properties /.idea/caches /.idea/libraries /.idea/modules.xml .DS_Store /build /captures .externalNativeBuild .cxx *.keystore !debug.keystore万一你已经提交了不该提交的文件先不要慌也不要上网搜索各种强删历史的野路子操作先把文件从版本控制中移除再提交一次更稳妥# 从Git移除但保留本地文件 git rm --cached local.properties如果需要彻底清历史那操作要非常小心涉及git filter-branch或BFG这种破坏性操作强烈建议在备份分支上演练过再执行而且一般涉及团队协作都要提前沟通。7. 完整复盘一次feature分支从创建到合入的实战演示前面讲的是零散的动作这一节我想用一个完整的流程把这些动作串成一条线。假设你接到一个新需求在App的我的页面新增一个意见反馈入口修改设置项。7.1 开发前拉分支原则永远是主分支保持稳定可发布状态所有开发都在功能分支上进行。假定团队主分支是develop有的团队用master或main本质一样。先切到develop并拉最新代码git switch develop git pull --rebase然后基于最新的develop创建功能分支git switch -c feature/feedback-entry这时候右下角的分支名变成了feature/feedback-entry。7.2 开发中的多次提交每完成一个小步就提交一次。比如第一步在strings.xml里添加反馈入口的文案资源git add app/src/main/res/values/strings.xml git commit -m feat(feedback): 添加意见反馈入口文案第二步修改MineFragment.java加上入口布局和点击事件git add app/src/main/java/com/example/app/ui/mine/MineFragment.java git commit -m feat(feedback): 在设置页添加反馈入口并处理点击跳转第三步新增FeedbackActivity及其布局文件git add app/src/main/java/com/example/app/ui/feedback/ git add app/src/main/res/layout/activity_feedback.xml git commit -m feat(feedback): 新增反馈页面基础结构每次提交前记得用git diff检查本次改动的内容确认没有夹带无关改动。Android Studio的Commit界面也会显示所有变更差异方便二次确认。7.3 开发完成合入develop功能开发完毕本地验证编译通过、功能正常之后先推送分支git push -u origin feature/feedback-entry然后合入develop分支git switch develop git pull --rebase git merge feature/feedback-entry如果合并时产生冲突按第5节的方式解决。没有冲突的话合并会生成一个Merge提交节点。合入后立即跑一次完整构建验证没有因为合并引入问题./gradlew assembleDebug如果构建通过推送到远程git push7.4 分支的收尾合并后立刻清理功能合并完成后本地和远程的分支都建议及时清理不然分支越积越多切换列表里全是废弃分支会干扰判断。删除本地分支git switch develop git branch -d feature/feedback-entry-d参数只有在该分支已合并到家当前分支的情况下才允许删除这是一个保护机制。如果功能分支并没有合并但确实不需要了需要用-D强制删除。远程分支删除指令是git push origin --delete feature/feedback-entry在Android Studio中分支菜单里选中本地分支后右键选择Delete远程分支在Git工具窗口下方Remote Branches里删。删除动作没有任何心理负担分支只是一个指针合入后的代码已经沉淀在主线历史里了删掉分支不影响任何已合入内容。7.5 一个常用的小技巧提交前先看差异再点提交最后分享我个人多年养成的习惯。很多人提交时直接把所有改动一股脑提交了省事但风险大。我强烈建议每次提交前按下Alt 9打开Version Control面板在Default变更集双击每个文件看一眼具体改动。很多时候会意外发现——自己不小心改了无关的文件或者改错了地方。这个习惯的成本极低但对代码质量的帮助极其显著。8. 常见问题速查与多年的实操心得文章的最后我整理一张问题对照表方便你以后遇到问题时快速定位。下面所有场景都是我或我身边的人真实踩过的坑。症状可能原因解决办法切换分支被拒绝当前分支有未提交改动且和目标分支冲突先stash或commit再切换切换后代码没变化IDE缓存/Gradle未同步File - Sync Project with Gradle Files必要时Invalidate Caches推送被拒绝远程分支有新提交git pull --rebase后重新push合并时生成多余的Merge提交使用了merge策略而非rebase想要干净历史就改用git pull --rebase合并后编译失败两个分支改了相同依赖或资源打开merge dialog检查关键文件必要时手动选ours/theirs分支删不掉分支未合并-d保护确认base分支后用-D强制删除或先merge再删提交用户名不对全局git config未设置或设置错误git config --global user.name / user.email误提交local.properties缺少正确的.gitignoregit rm --cached后添加.gitignore规则还有一个从经验里沉淀的判断标准无论使用什么分支策略Android项目都值得保持一条随时可构建可通过的主分支。这条分支上最好不要出现半成品的提交。所有不完整的、正在试验中的代码都留在feature分支上。这样团队随时都能从那一条分支出包对外测试而不需要担心代码缺东西。至于提交信息风格和团队成员统一即可。有的人喜欢全英文有的人用中文但有一点是共识——必须能看懂。不要用asdf或呵呵这种无意义内容。从自己写Demo到融入团队协作Git分支是所有Android开发者绕不开的一课。但我可以拍着胸脯说这些操作熟练之后你会越来越觉得分支带来的不是负担而是一种安全感——你随时可以放心大胆地尝试新东西因为一切都在掌控之中。改乱了切回去做坏了删掉重来做完了合入主线。这种确定性是单分支开发永远体会不到的。