Agile&DevOps系列-8.连接Bitbucket并上传Nuget项目代码

11 篇文章 0 订阅
11 篇文章 0 订阅

启动Bitbucket服务器,waiting.... 登录ing

 

1.创建项目

完成之后点击项目进入 ,然后创建仓库

下图就是创建好的空仓库

 

下面命令是使用git bash初始化项目代码和上传相关 Mark 一下

---------------------------------------------

Configure Git for the first time

git config --global user.name "gaosiji"

git config --global user.email "gaosiji20080303@126.com"

 

Working with your repository

I just want to clone this repository

If you want to simply clone this empty repository then run this command in your terminal.

git clone http://localhost:7990/scm/...../nugetserver.git

 

My code is ready to be pushed

If you already have code ready to be pushed to this repository then run this in your terminal.

cd 项目根目录

git init

git add --all

git commit -m "Initial Commit"

git remote add origin http://localhost:7990/scm/..../nugetserver.git

git push -u origin master

 

My code is already tracked by Git

If your code is already tracked by Git then set this repository as your "origin" to push to.

cd 项目根目录

git remote set-url origin http://localhost:7990/scm/..../nugetserver.git

git push -u origin --all

git push origin --tags

---------------------------------------------

2.客户机初始化已经写好的项目和代码

启动客户机git bash

进入项目根目录

cd C:/Dev/NugetServer/NugetServer

记得目录的分级用 / 而不是 \

git init

git add --all (由于需要忽略的文件和目录比较多这里统一添加,再用GUI工具去添加忽略)

git commit -m "Initial Commit"

git remote add origin http://localhost:7990/scm/..../nugetserver.git

git push -u origin master

 

最后一步弹出鉴权登录窗口

git credential manager for windows

输入bitbucket你创建的用户名和密码就完成了

 

如果输入或者验证错误,就删除一下登录凭据

经过一系列折腾上传成功 附上两张截图

 

上面操作都是基于本地localhost 一般公司肯定都是私有PC或者云VM

下面就远程方式down一下代码,update 和 commit一下

首先创建一个远程分支,使用bitbucket

 

Branch type 跟据项目对code的操作和即将对线上产品产生的影响选择对应类型,比如新功能开发 选择Feature / 线上问题热修复Hotfix / Bug修改Bugfix / 发布版本 / Release等

创建完成切换到ChinaDev分支

 

前置条件:

1.获取Bitbucket服务器Ip或者域名

2.客户机可以ping通或者访问Bitbucket域名

Sourcetree方式 ,通过客户机访问bitbucket然后找到分支Checkout

或者直接用git 命令

cd 客户机项目目录

git init

git remote add origin https://192.168.110.239:7990/scm/cnb/nugetserver.git

git fetch origin

git checkout -b local_dev origin/ChinaDev

git checkout local_dev

 

如果配置错了remote url 可以使用如下命令修改remote URL

git remote rm origin

git remote add origin [url]

 

或者也可以在客户机使用任何git工具进行操作, 小乌龟、github desktop等等。

 

下载完成之后随便修改点东西,然后提交commit 之后,在push到remote 仓库

此时查看bitbucket就可以看到记录了,

 

后续会继续开关于开发分支、版本控制、release、发布相关文章已经操作bitbucket的PR等相关操作

刚刚发布的ThoughtWorks技术雷达 建议技术团队“暂缓或谨慎”使用反模式“CI theatre(伪CI,可以理解为不完整的持续集成)”。 “伪CI”描述的是实践持续集成(CI)过程中的一些错觉,然而这些并不是真正的CI实践。 基于持续集成,我和同事 Emily Luke做了一些研究, 我将分享伪CI是什么样的,为什么我们建议你“暂缓或谨慎使用”,以及预防伪CI的方法。持续集成我最喜欢的CI定义来自于continuousdelivery.comCI开发人员定期(至少每天)将他们所有的工作集成到主干(也称为主线或主干分支)这个引用中暗含了CI实践的两个基本原则。第一个是“把他们所有的工作集成到主干”;第二个是“至少每天”。对于CI还有一系列其他原则和实践,例如:将所有内容都检入您的代码库,构建每个提交,自动化构建,保持快速构建,并有可以自我验证的代码, 还有Martin Fowler 关于持续集成的评论中的可视化故障并立即修复故障等。我个人认为 每天至少检入代码到主干分支一次 是CI的基础。没有达到这一点就只是伪CI而不是真正意义上的CI。伪CI是什么样的?这是我们调研到的一个故事,一位经验丰富的开发人员(让我们称他为David)来自湾区的一个中型创业公司,每周有两次产品交付。 David说他的组织正在践行CI,他说:“是的,我们用Circle CI”,他描述了一个具有挑战性的场景,曾经在一个分支上工作了一段时间,大约修改了100个文件和7000行代码,然后在代码审查阶段就开始招架不住了,因为他要向他的同事解释所有的代码变更的原因。“最具挑战性的事情是你最终要将一大堆功能集中到一个提交里,因为它们都是这个组件的一部分”,他解释说:“我希望有一个更好的方式来分解这些提交,因为很难把所有事情(变更历史)记在脑子里。”如果这个情况你听起来很熟悉,那么你也在做伪CI。 如果有下面的这些场景,那么你们就是在做伪CI:当有人问起你们在实践CI吗? 如果你说我们有一个CI服务器并且我们使用X工具在我们的调查中,只有10%的参与者承认有CI服务器与CI践行不一样。 相反,90%的个人表示他们正在践行CI,无论他们是否有专门从事CI的基础知识。 所以简单的认为只要有一个CI服务器就是“在做CI”,这就清楚地表明是在做“伪CI”。使用长期开发分支,但不会定期检入master主干在David的故事中,他们并没有实践每天检入master主干,这就是“伪CI”的标志。 这是我们在调研中常看到的一种模式,其中团队在master主干上运行CI,但不频繁构建,也不是每天都在提交。 或者他们在分支上运行CI,但不会频繁的集成到master主干。 只对特性分支运行CI,其实应该称之为持续隔离(continuous isolation)才对.合并分支时感到焦虑和疲惫真正的持续集成要把代码所有者的责任意识扩展到整个团队。 这改变了团队内部人员的观点以及他们对失败构建的态度。 不再是“我的宝贵的分支”,或是“我的错误导致构建被破坏”,而是“我们的代码”和“我们的失败”。David遇到焦虑和疲惫的事实清楚地表明,他忽略了CI的一个重要的优势:持续反馈和代码集体所有权。伪CI还有更多的一些现象,虽然我们发现有一些并不那么常见,但它们仍然存在一些问题,构建的时候,仅有极少的测试覆盖允许构建长时间处于失败状态虽然David的团队引入了一个备受尊崇的CI工具和常见的流程,如特征分支和代码审查,但他们并没有实施全套CI实践,因此错过了许多好处。 我们遗憾的发现,在我们的研究的组织中90%发生了这种情况。一些组织实施伪CI中反而错失了CI的主要优势 - 快速反馈,代码集体所有权,并准备达成持续交付如何避免,预防和解决伪CI的问题?如果您确定可能正在遭受伪CI之苦,则可以通过三种方式来解决问题并进行持续改变。1. 提交更频繁回到根本,尽量频繁地提交,每天至少提交一次应该是最低目标。 如果你还没有开始做CI,这就是你可以开始的地方,即使你在做CI,依然会有改进的空间。我喜欢“频率降低难度”的说法。 往往我们在做一些事情时,任务变得越小,则其更容易被实现。 持续集成就是是一个典型例子。 我的建议是要更加频繁地检入你的代码代码库并且将开发分支集成到主干分支,至少每天集成一次”。2. 基于主干分支开发有很多论坛在讨论基于主干还是基于开发分支进行开发,我不想讨论那些血淋淋的细节。 然而,在我们的调研中,当我们与一些曾经在实践CI过程中感到痛苦的人交谈时,没有引入主干开发的团队对此有更深刻的感受。 DevOps现状调查报告-2016 还发现,基于主干开发和持续集成是达成持续交付的关键因素,同时也能建设更高效能的团队。基于主干的开发肯定会有一定的挑战,但它可以把问题提前暴露出来,而不是要等到代码合并、代码审查甚至到延迟发布的时候。如果你想达到更好效果的CI和CD,我建议在主干上做开发,或者如果你更愿意使用短周期的临时分支(合并到主干之前不到一天)进行开发,那么最好同时不要超过三个以上的活跃分支。3. 自动化自动化是做好持续集成的基石,所以如果你还没有自动化一切,现在是开始的好时机。 如果你认为已经实现了所有自动化的功能,那么每次有人手动地做任何事情超过一次,便要问自己“这个为什么不能自动化”? 我已经观察到自动化不仅可以帮助您在CI中变得更好,还可以帮助您开始持续交付。总结现在你知道什么是伪CI了,如果你的团队正在这么实践伪CI,那么你可以阻止这种情况继续发生了。 如果您仍然感到困惑,我建议你在Martin Fowler的博客“CI Certification test”做一个测试, 以确认你的组织是否正在做可靠的CI。 如果你通过了CI测试,那太好了,现在是考虑您是否准备好实施持续交付的时候了。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值