k**0
发帖数: 19737 | 1 连开了好几个会讨论这玩意儿，说要把所有code放到bitbucket上去，还经常
distributed/branch口头说，弄得好像这玩意儿是啥伟大发明一样。
真是有点烦不胜烦，就一个souce control tool, 这样一个purposeful软件在我看来要
是花超过4个小时去学都是浪费，再说team里也没几个人，搞那么多branch真是吃饱了
撑的... |
L****8
发帖数: 3938 | 2 你用啥？
【在 k**0 的大作中提到】
: 连开了好几个会讨论这玩意儿，说要把所有code放到bitbucket上去，还经常
: distributed/branch口头说，弄得好像这玩意儿是啥伟大发明一样。
: 真是有点烦不胜烦，就一个souce control tool, 这样一个purposeful软件在我看来要
: 是花超过4个小时去学都是浪费，再说team里也没几个人，搞那么多branch真是吃饱了
: 撑的...
|
k**0
发帖数: 19737 | 3 现在已经用git了，以前是一个旧的centralized软件， 因为team小，有一些也没有用。
【在 L****8 的大作中提到】
: 你用啥？
|
g*****g
发帖数: 34805 | 4 If you are already using it, github, bitbucket etc. will only simplify your
workflow, what's the point to complain?
用。
【在 k**0 的大作中提到】
: 现在已经用git了，以前是一个旧的centralized软件， 因为team小，有一些也没有用。
|
k**0
发帖数: 19737 | 5 complain是因为老板太迷这个，还时不时开会讨论，小题大做烦死人
【在 g*****g 的大作中提到】
: If you are already using it, github, bitbucket etc. will only simplify your
: workflow, what's the point to complain?
:
: 用。
|
a**w
发帖数: 156 | 6 老板是Linus粉丝?
【在 k**0 的大作中提到】
: complain是因为老板太迷这个，还时不时开会讨论，小题大做烦死人
|
k**0
发帖数: 19737 | 7 没错，新粉丝
【在 a**w 的大作中提到】
: 老板是Linus粉丝?
|
l******t
发帖数: 55733 | |
z****e
发帖数: 54598 | 9 多好，互相学习
：complain是因为老板太迷这个，还时不时开会讨论，小题大做烦死人
： |
c******n
发帖数: 4965 | 10 整合3way. merge 很强
【在 k**0 的大作中提到】
: 连开了好几个会讨论这玩意儿，说要把所有code放到bitbucket上去，还经常
: distributed/branch口头说，弄得好像这玩意儿是啥伟大发明一样。
: 真是有点烦不胜烦，就一个souce control tool, 这样一个purposeful软件在我看来要
: 是花超过4个小时去学都是浪费，再说team里也没几个人，搞那么多branch真是吃饱了
: 撑的...
|
|
|
g*********e
发帖数: 14401 | 11 好奇， 当你的repo有百万行代码或者若干g xml文件后 branch的效率会如何？是不是
干脆checkout 几个local会比较好一点？ |
l******n
发帖数: 9344 | 12 那是不是已经躺着数钱了，谁还在乎效率？
【在 g*********e 的大作中提到】
: 好奇， 当你的repo有百万行代码或者若干g xml文件后 branch的效率会如何？是不是
: 干脆checkout 几个local会比较好一点？
|
g*********e
发帖数: 14401 | 13 不是 我是说整个公司
【在 l******n 的大作中提到】
: 那是不是已经躺着数钱了，谁还在乎效率？
|
g*****g
发帖数: 34805 | 14 分布式系统，只会比p4等好很多。而且项目之间并没有直接关系。git的标准做法就是
每个ticket开一个branch. merge完了再删掉。
【在 g*********e 的大作中提到】
: 不是 我是说整个公司
|
w**z
发帖数: 8232 | 15 我们那merge 完之后，都懒得删，搞出几百个branch.
【在 g*****g 的大作中提到】
: 分布式系统，只会比p4等好很多。而且项目之间并没有直接关系。git的标准做法就是
: 每个ticket开一个branch. merge完了再删掉。
|
g*****g
发帖数: 34805 | 16 不是什么大问题。我们有自动化的通知，超过多少天没修改就给你发信，所以清理得相
对干净。
【在 w**z 的大作中提到】
: 我们那merge 完之后，都懒得删，搞出几百个branch.
|
g*********e
发帖数: 14401 | 17
那你从一个branch跳到另一个以后 文件变了很多 第一次编译得半小时
【在 g*****g 的大作中提到】
: 分布式系统，只会比p4等好很多。而且项目之间并没有直接关系。git的标准做法就是
: 每个ticket开一个branch. merge完了再删掉。
|
g*****g
发帖数: 34805 | 18 git推荐的是short live branch，文件本来就不会变很多，编译半个小时那更是你们没
有做好模块化才会导致的。
俺们公司源码估计几千万行，几千个项目，我还没见过一个项目编译得半个小时的。当
然我们做的是micro services，不是windows.
【在 g*********e 的大作中提到】
:
: 那你从一个branch跳到另一个以后 文件变了很多 第一次编译得半小时
|
l*v
发帖数: 69 | 19 git rebase rerere
记着那个有点意思，也是大家开会讨论git work flow
【在 k**0 的大作中提到】
: 连开了好几个会讨论这玩意儿，说要把所有code放到bitbucket上去，还经常
: distributed/branch口头说，弄得好像这玩意儿是啥伟大发明一样。
: 真是有点烦不胜烦，就一个souce control tool, 这样一个purposeful软件在我看来要
: 是花超过4个小时去学都是浪费，再说team里也没几个人，搞那么多branch真是吃饱了
: 撑的...
|
k**0
发帖数: 19737 | 20 问一下，你们把代码放哪里？内部还是外部的云类似bitcucket一类的？
【在 g*****g 的大作中提到】
: 不是什么大问题。我们有自动化的通知，超过多少天没修改就给你发信，所以清理得相
: 对干净。
|
|
|
w**z
发帖数: 8232 | 21 我不知道，但应该是自己host的git repo
【在 k**0 的大作中提到】
: 问一下，你们把代码放哪里？内部还是外部的云类似bitcucket一类的？
|
g*****g
发帖数: 34805 | 22 We wanted to use github but github couldn't provide regional failover we
asked for. So we end up using Stash instead and hosting it ourselves in the
cloud.
【在 k**0 的大作中提到】
: 问一下，你们把代码放哪里？内部还是外部的云类似bitcucket一类的？
|
k**0
发帖数: 19737 | 23 多谢两位，问这个主要是因为我们某些项目内有敏感内容（网银密码之类的），而这几
个项目没有外部的contractor，我认为完全可以自己搞个内部的share server/folder
host在自己的内部网上，放在外面毕竟不放心。 否则要改code，加密敏感内容或者完
全不包括敏感文件（但这类文件也是需要update的）。
现在上层执意要全部放bitbucket,你们觉得怎么处理好？
the
【在 w**z 的大作中提到】
: 我不知道，但应该是自己host的git repo
|
g*****g
发帖数: 34805 | 24 我觉得内网并不见得比SaaS安全，这个我说过很多次了。更重要的是你要想这个事情你
反对成了也没啥好处，放bitbucket出了事也不是你的责任。争这个干啥。pick your
fight.
folder
【在 k**0 的大作中提到】
: 多谢两位，问这个主要是因为我们某些项目内有敏感内容（网银密码之类的），而这几
: 个项目没有外部的contractor，我认为完全可以自己搞个内部的share server/folder
: host在自己的内部网上，放在外面毕竟不放心。 否则要改code，加密敏感内容或者完
: 全不包括敏感文件（但这类文件也是需要update的）。
: 现在上层执意要全部放bitbucket,你们觉得怎么处理好？
:
: the
|
k**0
发帖数: 19737 | 25 这就是问题所在啊，我提出了敏感信息的问题，老板的意见就是加密/ignore, 没事找
事。
我是负责人，真的出了啥事，这个黑锅肯定我背。
谢了，没办法，看来得改code了。
【在 g*****g 的大作中提到】
: 我觉得内网并不见得比SaaS安全，这个我说过很多次了。更重要的是你要想这个事情你
: 反对成了也没啥好处，放bitbucket出了事也不是你的责任。争这个干啥。pick your
: fight.
:
: folder
|
g*****g
发帖数: 34805 | 26 We have a central configuration service. All properties can be overridden at
startup time. So you can put some test credential in git and override it
with real ones in prod environment. No code change is necessary. Just one
solution you can try.
【在 k**0 的大作中提到】
: 这就是问题所在啊，我提出了敏感信息的问题，老板的意见就是加密/ignore, 没事找
: 事。
: 我是负责人，真的出了啥事，这个黑锅肯定我背。
: 谢了，没办法，看来得改code了。
|
k**0
发帖数: 19737 | 27 Thanks
at
【在 g*****g 的大作中提到】
: We have a central configuration service. All properties can be overridden at
: startup time. So you can put some test credential in git and override it
: with real ones in prod environment. No code change is necessary. Just one
: solution you can try.
|
a9
发帖数: 21638 | 28 你一开始就不应该把密码存在git上啊。
这下要放bitbucket，提交历史麻烦了。
情你
your
【在 k**0 的大作中提到】
: 这就是问题所在啊，我提出了敏感信息的问题，老板的意见就是加密/ignore, 没事找
: 事。
: 我是负责人，真的出了啥事，这个黑锅肯定我背。
: 谢了，没办法，看来得改code了。
|
w**z
发帖数: 8232 | 29 放哪里，都要加密的。这个credentials应该和source code 分开,我专门写了个
service 把敏感信息分开存，取。
【在 k**0 的大作中提到】
: 这就是问题所在啊，我提出了敏感信息的问题，老板的意见就是加密/ignore, 没事找
: 事。
: 我是负责人，真的出了啥事，这个黑锅肯定我背。
: 谢了，没办法，看来得改code了。
|
k**0
发帖数: 19737 | 30 没事，我会rebase
说起这个我看一个repo历史都看到老板的密码了 lol
【在 a9 的大作中提到】
: 你一开始就不应该把密码存在git上啊。
: 这下要放bitbucket，提交历史麻烦了。
:
: 情你
: your
|
|
|
k**0
发帖数: 19737 | 31 是啊，看来也只能这么办了。
【在 w**z 的大作中提到】
: 放哪里，都要加密的。这个credentials应该和source code 分开,我专门写了个
: service 把敏感信息分开存，取。
|
c*********e
发帖数: 16335 | 32 我们是本地测试之后，check in.一个branch.
【在 w**z 的大作中提到】
: 我们那merge 完之后，都懒得删，搞出几百个branch.
|
b********e
发帖数: 595 | 33 没什么特别的，就是repo能多放几个地方，免的误操作被一锅端了。
平时新人做些小改变，fork以后再PR，review什么的比较方便，我们用的内部的ghe。
不要留着太多的branch，有的老repo久了几个g大，跨国家clone一次要等很久。
本地的mac上用gitx看log很方便 |
