merge

1,one to one, 单向, 谁加注解才能关联(dubug有时候背lazy影响 副表角度： 查：能查，主表不加注解 插入：不加级联插入有异常，只有在副表加cascade = CascadeType.ALL,所以只能说明加了oneToOne只能级联插入, 　　如果只是查出来再插入，cascade = CascadeType.ALL需要删掉, 或改成merge,detech 还是不能改主表属性,能插入副表，不会有异常 　　把他看作一个dao一个session，不同dao查出来的对象不能跨session保存 delete: 不加不级联，加了cascade = CascadeType.ALL级联, merge可 update：不加不更新主表，加了cascade = CascadeType.ALL级联，merge可 2,many to one 和上面相同 删除：cascade = CascadeType.ALL可以删得剩下副表的情况 3,one to many, many to one, 单单onetomany不知道怎么弄 都不要忘记cascade = CascadeType.ALL 只有双关联才能用, 关注在外键 insertable = false 插入了，但沒有关联 updatable = false不修改关联的，新插入一条 插入的时候双方都要set, 在以有主表的情况先

本节主要讲解一下在SVN中Branch和tag的比较，SVN中Branch和tag在一个功能选项中，在使用中也往往产生混淆。在实现上，branch和tag，对于svn都是使用copy实现的，所以他们在默认的权限上和一般的目录没有区别。至于何时用tag，何时用branch，完全由人主观的根据规范和需要来选择，而不是强制的（比如cvs），下面我们就来看一下SVN中Branch和tag的具体介绍。 SVN中Branch和tag的比较 在SVN中Branch和tag在一个功能选项中，在使用中也往往产生混淆。在实现上，branch和tag，对于svn都是使用copy实现的，所以他们在默认的权限上和一般的目录没有区别。至于何时用tag，何时用branch，完全由人主观的根据规范和需要来选择，而不是强制的（比如cvs）。 一般情况下，tag，是用来做一个milestone的，不管是不是release，都是一个可用的版本。这里，应该是只读的。更多的是一个显示用的，给人一个可读（readable）的标记。 branch，是用来做并行开发的，这里的并行是指和trunk进行比较。比如，3.0开发完成，这个时候要做一个tag，tag_release_3_0，然后基于这个tag做release，比如安装程序等。trunk进入3.1的开发，但是3.0发现了bug，那么就需要基于tag_release_3

题目描述： 将两个有序链表合并为一个新的有序链表并返回。新链表是通过拼接给定的两个链表的所有节点组成的。 示例： 输入：1->2->4, 1->3->4 输出：1->1->2->3->4->4 我的方法： 这个题目比较简单，解法如下： 两个指针分别指向两个链表的头部。 比较对应位置的数字大小，记录较小的字符，对应的指针移到下一位。 直到两个链表都遍历完。 效果还不错：执行用时 : 32 ms, 在Merge Two Sorted Lists的Python提交中击败了99.60% 的用户。内存消耗 : 10.8 MB, 在Merge Two Sorted Lists的Python提交中击败了0.57% 的用户。 # Definition for singly-linked list. # class ListNode(object): # def __init__(self, x): # self.val = x # self.next = None class Solution(object): def mergeTwoLists(self, l1, l2): """ :type l1: ListNode :type l2: ListNode :rtype: ListNode """ ans=ListNode(0) head=ans while l1 and l2: if l1

可以说merge包含了join的操作，merge支持通过列或索引连表，而join只支持通过索引连表，只是简化了merge的索引连表的参数 示例 定义一个left的DataFrame left=pd.DataFrame([ [1,2],[3,4],[5,6] ], index=['a','c','e'], columns=['chenqionghe','muscle'] ) 定义一个right的DataFrame right=pd.DataFrame([ [7,8],[9,10],[11,12],[13,14], ], index=['b','c','d','e'], columns=['light','weight'] ) 然后，我们使用merge通过索引合并这两个Dataframe，如下 left.merge(right,left_index=True,right_index=True,how='outer') 然后，通过join方法实现相同的操作 left.join(right,how='outer') 可以看出join其实是省略了参数的merge，并且没有基于列的连表功能 merge的参数 left：参与合并的左侧DataFrame right：参与合并的右侧DataFrame how：inner、outer、left、right其中之一 left_index

在团队中使用GitLab中的Merge Request工作模式 Jun 1, 2018 | Git | 阅读 在工作中使用 Git 已有5年多的时间了， Git 分布式的工作机制以及强大的分支功能使得在团队中推广使用没有受到什么阻碍。一直以来都是采用的分支管理模式，我把项目的开发分为三个阶段：开发、测试和上线。 分支管理模式 开发阶段 除了 master 分支创建一个供所有开发人员开发的 dev 分支； 开发人员在 dev 分支上进行工作，随时随地 commit ，每天 push 一次到服务器； push 代码前需要进行 pull 操作，因为有可能在之前有别的成员先进行了 push 操作，如果有冲突还需要进行冲突解决； 每天上班后所有成员对 dev 进行 pull 操作，获取所有成员 push 的代码，有冲突需要解决； 团队Leader每天将 dev 合并一次到 master 。 测试阶段 测试进入后就需要添加 test 分支； 在开发人员将代码 push 到 dev 分支后，可以在 dev 基础上创建 test 分支，测试人员以 test 分支搭建测试环境，开始测试； 开发人员在接受到 bug 后，直接在测试分支上修改，然后让测试人员进行验证； 每天团队Leader将测试分支上修改的 bug 合并到 dev 分支上，这样所有团队成员当天修复的 bug 都会在第二天被团队其他人