1.多master/develop分支如何使用gitflow版本控制
2.Python modbus_tk 库源码分析
3.什么是源码master分支呢
4.如何编译busmaster源码?
5.nginx源码分析--master和worker进程模型
6.yarn源码分析（四）AppMaster启动
多master/develop分支如何使用gitflow版本控制
在使用 gitflow 做版本控制系统，发现gitflow的源码时候只能指定一个master/develop，如果要多分支使用要如何操作呢?源码那么来看看我是如何给gitflow加料的。
公司都是源码git作为版本控制，公司一些项目组在用gitflow，源码但是源码亚马逊采集网站源码我们组没有强制， 但是源码我上月出了一次事故，总结就是源码分支管理问题，所以开始强迫自己使用gitflow,源码 以前的项目是一个master和一个develop，自己checkout一个分支，源码然后merge(不理解的源码可以看看a-successful-git-branching-model).
问题出现了: 项目有几个主分支和开发分支，比如master_sina,源码 master_qq. master_buzz ,而gitflow的时候只能指定一个master/develop, 这样你start一个feature/hotfix之前就要去.git/config里面修改 [gitflow “branch”]项的相关主分支和开发分支，so不方便。源码看了下源码，源码给gitflow加点料
添加功能
当你打开了feature/hotfix分支，源码但是你不想要它了(当然你可以直接git branch -D xx)，使用git flow hotfix/feature delete ,自动帮你删除这个分支，以便你新建其他分支(git flow只容许你一次存在一个hotfix/feature分支)
你想使用gitflow删除其它存在分支嘛？不需要 git branch -D ，你还可以git flow hotfix/feature delete XX
比如我在init的时候指定了master为master_sina, 而当我想创建master_qq的hotfix，我只需要在start的埋伏源码是否给它取名字是’qq_‘开头的即可，要是有其它的需要你可以直接在源码里面添加对应的内容
例子 git-flow-hotfix 我主要标记我修改的部分
代码如下 复制代码 init() {
require_git_repo
require_gitflow_initialized
gitflow_load_settings
VERSION_PREFIX=$(eval "echo `git config --get gitflow.prefix.versiontag`")
PREFIX=$(git config --get gitflow.prefix.hotfix)
}
# 增加help的选项说明
usage() {
echo "usage: git flow hotfix [list] [-v]"
echo " git flow hotfix start [-F] version [base]"
echo " git flow hotfix finish [-Fsumpk] version"
echo " git flow hotfix publish version"
echo " git flow hotfix delete [branch]"
echo " git flow hotfix track version"
}
cmd_default() {
cmd_list "$@"
}
cmd_list() {
DEFINE_boolean verbose false 'verbose (more) output' v
parse_args "$@"
local hotfix_branches
local current_branch
local short_names
hotfix_branches=$(echo "$(git_local_branches)" | grep "^$PREFIX")
if [ -z "$hotfix_branches" ]; then
warn "No hotfix branches exist."
warn ""
warn "You can start a new hotfix branch:"
warn ""
warn " git flow hotfix start version [base]"
warn ""
exit 0
fi
current_branch=$(git branch --no-color | grep '^* ' | grep -v 'no branch' | sed 's/^* //g')
short_names=$(echo "$hotfix_branches" | sed "s ^$PREFIX g")
# determine column width first
local width=0
local branch
for branch in $short_names; do
local len=${ #branch}
width=$(max $width $len)
done
width=$(($width+3))
local branch
for branch in $short_names; do
local fullname=$PREFIX$branch
local base=$(git merge-base "$fullname" "$MASTER_BRANCH")
local master_sha=$(git rev-parse "$MASTER_BRANCH")
local branch_sha=$(git rev-parse "$fullname")
if [ "$fullname" = "$current_branch" ]; then
printf "* "
else
printf " "
fi
if flag verbose; then
printf "%-${ width}s" "$branch"
if [ "$branch_sha" = "$master_sha" ]; then
printf "(no commits yet)"
else
local tagname=$(git name-rev --tags --no-undefined --name-only "$base")
local nicename
if [ "$tagname" != "" ]; then
nicename=$tagname
else
nicename=$(git rev-parse --short "$base")
fi
printf "(based on $nicename)"
fi
else
printf "%s" "$branch"
fi
echo
done
}
cmd_help() {
usage
exit 0
}
parse_args() {
# parse options
FLAGS "$@" || exit $?
eval set -- "${ FLAGS_ARGV}"
# read arguments into global variables
VERSION=$1
BRANCH=$PREFIX$VERSION
# 这里就是我多master/develop的技巧，我这里会判断要新建的分支的前缀，
# 要是qq_开头就会基于master_qq和develop_qq创建分支。所以你可以根据你的需要在这里加一些方法
test `expr match "$@" "qq_"` -ne 0 MASTER_BRANCH="$MASTER_BRANCH"_qq
DEVELOP_BRANCH="$DEVELOP_BRANCH"_qq
}
require_version_arg() {
if [ "$VERSION" = "" ]; then
warn "Missing argument version"
usage
exit 1
fi
}
require_base_is_on_master() {
if ! git branch --no-color --contains "$BASE" 2/dev/null
| sed 's/[* ] //g'
| grep -q "^$MASTER_BRANCH$"; then
die "fatal: Given base '$BASE' is not a valid commit on '$MASTER_BRANCH'."
fi
}
require_no_existing_hotfix_branches() {
local hotfix_branches=$(echo "$(git_local_branches)" | grep "^$PREFIX")
local first_branch=$(echo ${ hotfix_branches} | head -n1)
first_branch=${ first_branch#$PREFIX}
[ -z "$hotfix_branches" ] ||
die "There is an existing hotfix branch ($first_branch). Finish that one first."
}
# 添加delete 参数，函数需要cmd_开头
cmd_delete() {
if [ "$1" = "" ]; then
# 当不指定参数自动去找存在的未关闭的gitflow分支
local hotfix_branches=$(echo "$(git_local_branches)" | grep "^$PREFIX")
test "$hotfix_branches" = "" die "There has not existing hotfix branch can delete" exit 1
else
# 指定参数先判断参数是不是的数量格式
test $# != 1 die "There only need one parameter indicates the branch to be deleted" exit 1
hotfix_branches="$1"
fi
# 当要删除的分支就是当前分支，先checkout到develop分支
test "$hotfix_branches" = "$(git_current_branch)" echo 'First checkout develp branch'; git_do checkout "$DEVELOP_BRANCH"
git branch -D ${ hotfix_branches} /dev/null echo 'Delete Successed'|| die "Did not find branch: [$hotfix_branches]"
}
cmd_start() {
DEFINE_boolean fetch false "fetch from $ORIGIN before performing finish" F
parse_args "$@"
BASE=${ 2:-$MASTER_BRANCH}
require_version_arg
require_base_is_on_master
require_no_existing_hotfix_branches
# sanity checks
require_clean_working_tree
require_branch_absent "$BRANCH"
require_tag_absent "$VERSION_PREFIX$VERSION"
if flag fetch; then
git_do fetch -q "$ORIGIN" "$MASTER_BRANCH"
fi
if has "$ORIGIN/$MASTER_BRANCH" $(git_remote_branches); then
require_branches_equal "$MASTER_BRANCH" "$ORIGIN/$MASTER_BRANCH"
fi
# create branch
git_do checkout -b "$BRANCH" "$BASE"
echo
echo "Summary of actions:"
echo "- A new branch '$BRANCH' was created, based on '$BASE'"
echo "- You are now on branch '$BRANCH'"
echo
echo "Follow-up actions:"
echo "- Bump the version number now!"
echo "- Start committing your hot fixes"
echo "- When done, run:"
echo
echo " git flow hotfix finish '$VERSION'"
echo
}
cmd_publish() {
parse_args "$@"
require_version_arg
# sanity checks
require_clean_working_tree
require_branch "$BRANCH"
git_do fetch -q "$ORIGIN"
require_branch_absent "$ORIGIN/$BRANCH"
# create remote branch
git_do push "$ORIGIN" "$BRANCH:refs/heads/$BRANCH"
git_do fetch -q "$ORIGIN"
# configure remote tracking
git config "branch.$BRANCH.remote" "$ORIGIN"
git config "branch.$BRANCH.merge" "refs/heads/$BRANCH"
git_do checkout "$BRANCH"
echo
echo "Summary of actions:"
echo "- A new remote branch '$BRANCH' was created"
echo "- The local branch '$BRANCH' was configured to track the remote branch"
echo "- You are now on branch '$BRANCH'"
echo
}
cmd_track() {
parse_args "$@"
require_version_arg
# sanity checks
require_clean_working_tree
require_branch_absent "$BRANCH"
git_do fetch -q "$ORIGIN"
require_branch "$ORIGIN/$BRANCH"
# create tracking branch
git_do checkout -b "$BRANCH" "$ORIGIN/$BRANCH"
echo
echo "Summary of actions:"
echo "- A new remote tracking branch '$BRANCH' was created"
echo "- You are now on branch '$BRANCH'"
echo
}
cmd_finish() {
DEFINE_boolean fetch false "fetch from $ORIGIN before performing finish" F
DEFINE_boolean sign false "sign the release tag cryptographically" s
DEFINE_string signingkey "" "use the given GPG-key for the digital signature (implies -s)" u
DEFINE_string message "" "use the given tag message" m
DEFINE_string messagefile "" "use the contents of the given file as tag message" f
DEFINE_boolean push false "push to $ORIGIN after performing finish" p
DEFINE_boolean keep false "keep branch after performing finish" k
DEFINE_boolean notag false "don't tag this release" n
parse_args "$@"
require_version_arg
# handle flags that imply other flags
if [ "$FLAGS_signingkey" != "" ]; then
FLAGS_sign=$FLAGS_TRUE
fi
# sanity checks
require_branch "$BRANCH"
require_clean_working_tree
if flag fetch; then
git_do fetch -q "$ORIGIN" "$MASTER_BRANCH" ||
die "Could not fetch $MASTER_BRANCH from $ORIGIN."
git_do fetch -q "$ORIGIN" "$DEVELOP_BRANCH" ||
die "Could not fetch $DEVELOP_BRANCH from $ORIGIN."
fi
if has "$ORIGIN/$MASTER_BRANCH" $(git_remote_branches); then
require_branches_equal "$MASTER_BRANCH" "$ORIGIN/$MASTER_BRANCH"
fi
if has "$ORIGIN/$DEVELOP_BRANCH" $(git_remote_branches); then
require_branches_equal "$DEVELOP_BRANCH" "$ORIGIN/$DEVELOP_BRANCH"
fi
# try to merge into master
# in case a previous attempt to finish this release branch has failed,
# but the merge into master was successful, we skip it now
if ! git_is_branch_merged_into "$BRANCH" "$MASTER_BRANCH"; then
git_do checkout "$MASTER_BRANCH" ||
die "Could not check out $MASTER_BRANCH."
git_do merge --no-ff "$BRANCH" ||
die "There were merge conflicts."
# TODO: What do we do now?
fi
if noflag notag; then
# try to tag the release
# in case a previous attempt to finish this release branch has failed,
# but the tag was set successful, we skip it now
local tagname=$VERSION_PREFIX$VERSION
if ! git_tag_exists "$tagname"; then
local opts="-a"
flag sign opts="$opts -s"
[ "$FLAGS_signingkey" != "" ] opts="$opts -u '$FLAGS_signingkey'"
[ "$FLAGS_message" != "" ] opts="$opts -m '$FLAGS_message'"
[ "$FLAGS_messagefile" != "" ] opts="$opts -F '$FLAGS_messagefile'"
eval git_do tag $opts "$VERSION_PREFIX$VERSION" "$BRANCH" ||
die "Tagging failed. Please run finish again to retry."
fi
fi
# try to merge into develop
# in case a previous attempt to finish this release branch has failed,
# but the merge into develop was successful, we skip it now
if ! git_is_branch_merged_into "$BRANCH" "$DEVELOP_BRANCH"; then
git_do checkout "$DEVELOP_BRANCH" ||
die "Could not check out $DEVELOP_BRANCH."
# TODO: Actually, accounting for 'git describe' pays, so we should
# ideally git merge --no-ff $tagname here, instead!
git_do merge --no-ff "$BRANCH" ||
die "There were merge conflicts."
# TODO: What do we do now?
fi
# delete branch
if noflag keep; then
# 这个问题很奇怪，在完成分支删除它也会存在当前分支是
# 要删除的分支删除报错的问题，所以先切换走
test "$BRANCH" = "$(git_current_branch)" git_do checkout "$DEVELOP_BRANCH"
git_do branch -d "$BRANCH"
fi
if flag push; then
git_do push "$ORIGIN" "$DEVELOP_BRANCH" ||
die "Could not push to $DEVELOP_BRANCH from $ORIGIN."
git_do push "$ORIGIN" "$MASTER_BRANCH" ||
die "Could not push to $MASTER_BRANCH from $ORIGIN."
if noflag notag; then
git_do push --tags "$ORIGIN" ||
die "Could not push tags to $ORIGIN."
fi
fi
echo
echo "Summary of actions:"
echo "- Latest objects have been fetched from '$ORIGIN'"
echo "- Hotfix branch has been merged into '$MASTER_BRANCH'"
if noflag notag; then
echo "- The hotfix was tagged '$VERSION_PREFIX$VERSION'"
fi
echo "- Hotfix branch has been back-merged into '$DEVELOP_BRANCH'"
if flag keep; then
echo "- Hotfix branch '$BRANCH' is still available"
else
echo "- Hotfix branch '$BRANCH' has been deleted"
fi
if flag push; then
echo "- '$DEVELOP_BRANCH', '$MASTER_BRANCH' and tags have been pushed to '$ORIGIN'"
fi
echo
}
Python modbus_tk 库源码分析
modbus_tcp 协议是工业项目中常用的设备数据交互协议，基于 TCP/IP 协议。协议涉及两个角色：client 和 server，或更准确地称为 master 和 slave。modbus_tk 库作为 Python 中著名且强大的 modbus 协议封装模块，其源码值得深入分析，尤其是在关注并发量等方面的需求时。深入研究 modbus_tk 库的源代码和实现逻辑，对在库的基础上进行更进一步的开发尤其重要。因此，本文旨在提供对 modbus_tk 库源码的深入解析，以供参考。trylock源码
实例化 TcpMaster 对象时，首先导入 TcpMaster 类，该类继承自 Master，但在实例化时并未执行任何操作。Master 的 `__init__()` 方法同样没有执行任何具体任务，这使得 TCP 链接在创建 TcpMaster 实例时并未立即建立。TCP 链接的建立在 `open()` 方法中实现，该方法由 TcpMaster 类执行。在 `open()` 方法中，自定义了超时时间，进一步保证了 TCP 连接的建立。
在 TcpMaster 类的 `execute()` 方法中，核心逻辑在于建立 TCP 协议的解包和组包。在读写线圈或寄存器等操作时，都会调用 `execute()` 方法。详细分析了 `execute()` 方法的具体实现，包括通过注释掉的组包等过程代码，以及 `TcpMaster._make_query()` 方法的实现。`_make_query()` 方法封装了请求构建过程，源码 2包括生成事务号、构建请求包和发送请求。
在请求构建完成后，`_send()` 方法负责通过 `select` 模块进行连接状态检测，确保发送数据前连接无异常。通过分析 `execute()` 方法的后续逻辑，我们能够看到一个完整的组包、发送数据及响应解析的源码流程。响应解析涉及 `TcpMaster.execute()` 方法中对 MBAP 和 PDU 的分离、解包及数据校验。
在解析响应信息时，`TcpQuery().parse_response()` 方法解包并验证 MBAP 和 PDU，确保数据一致性。通过此过程，获取了整个数据体，完成了响应信息的解析。在 `execute()` 方法的后续部分，没有执行新的 I/O 操作，进一步简化了流程。caseinsensitivemap源码
为了保障线程安全，`threadsafe` 装饰器被添加在 `Master.execute()` 方法及 `TcpQuery._get_transaction_id()` 方法上。这一装饰器确保了跨线程间的同步，但可能引起资源竞争问题。在实际应用中，为了避免同一设备不能同时读写的情况，可以显式传递 `threadsafe=False` 关键字参数，并实现自定义锁机制。
modbus_tk 模块提供了丰富的钩子函数，如 `call_hooks`，在数据传递生命周期中自动运行，实现特定功能的扩展。常见的钩子函数包括初始化、结束、请求处理等，这些功能的实现可以根据具体需求进行定制化。
什么是master分支呢
目前的master 就是froyo，以后的master就是更新的版本。打个比方就像我们开发一个工程项目，隔一段时间就备份一次，上次备份是eclair,现在备份froyo, master就是目前正在开发的主线，froyo是现在的一个备份而已。
android2.2 释放的源代码来看master分支是默认的。
如何编译busmaster源码?
在编译busmaster源码时，通常使用的是build命令。若出现错误信息提示未安装java，则需要在window命令行环境下运行java命令。如果该命令无法被识别，说明你可能需要安装jdk(java development kit)。可以在线搜索Oracle或Sun的最新版本进行下载安装。
在编译脚本的环境设置中，需要准备以下工具：Java\jdk、Syntext\Serna Free、dita\DITA-OT1.5及ant。其中，DITA-OT1.5工具通常用于修改设计配置后生成代码。但如果你未对Source目录下的代码进行任何修改，可以直接通过编译现有的VisualStudio工程sln文件完成编译过程。此步骤在gitHub仓库的脚本描述中有详细指引。
要成功编译，仅需确保安装了.Net Framework 3.5或4.0版本，通常在安装VisualStudio后会自动包含。在编译脚本中，可以通过设置DOTNET环境变量来实现。设置方法如下：
DOTNET=%SystemRoot%\Microsoft.NET\Framework\v4.0.
DOTNET=%SystemRoot%\Microsoft.NET\Framework\v3.5
程序代码中通常包含有关设计文档和API手册的注释，关于其更新方法的详细信息，可以在gitHub仓库的相关文档中查找。
nginx源码分析--master和worker进程模型
一、Nginx整体架构
正常执行中的nginx会有多个进程，其中最基本的是master process（主进程）和worker process（工作进程），还可能包括cache相关进程。
二、核心进程模型
启动nginx的主进程将充当监控进程，主进程通过fork()产生的子进程则充当工作进程。
Nginx也支持单进程模型，此时主进程即是工作进程，不包含监控进程。
核心进程模型框图如下：
master进程
监控进程作为整个进程组与用户的交互接口，负责监护进程，不处理网络事件，不负责业务执行，仅通过管理worker进程实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。
master进程通过sigsuspend()函数调用大部分时间处于挂起状态，直到接收到信号。
master进程通过检查7个标志位来决定ngx_master_process_cycle方法的运行：
sig_atomic_t ngx_reap;
sig_atomic_t ngx_terminate;
sig_atomic_t ngx_quit;
sig_atomic_t ngx_reconfigure;
sig_atomic_t ngx_reopen;
sig_atomic_t ngx_change_binary;
sig_atomic_t ngx_noaccept;
进程中接收到的信号对Nginx框架的意义：
还有一个标志位：ngx_restart，仅在master工作流程中作为标志位使用，与信号无关。
核心代码（ngx_process_cycle.c）：
ngx_start_worker_processes函数：
worker进程
worker进程主要负责具体任务逻辑，主要关注与客户端或后端真实服务器之间的数据可读/可写等I/O交互事件，因此工作进程的阻塞点在select()、epoll_wait()等I/O多路复用函数调用处，等待数据可读/写事件。也可能被新收到的进程信号中断。
master进程如何通知worker进程进行某些工作？采用的是信号。
当收到信号时，信号处理函数ngx_signal_handler()会执行。
对于worker进程的工作方法ngx_worker_process_cycle，它主要关注4个全局标志位：
sig_atomic_t ngx_terminate;//强制关闭进程
sig_atomic_t ngx_quit;//优雅地关闭进程（有唯一一段代码会设置它，就是接受到QUIT信号。ngx_quit只有在首次设置为1时，才会将ngx_exiting置为1）
ngx_uint_t ngx_exiting;//退出进程标志位
sig_atomic_t ngx_reopen;//重新打开所有文件
其中ngx_terminate、ngx_quit、ngx_reopen都将由ngx_signal_handler根据接收到的信号来设置。ngx_exiting标志位仅由ngx_worker_cycle方法在退出时作为标志位使用。
核心代码（ngx_process_cycle.c）：
yarn源码分析（四）AppMaster启动
在容器分配完成之后，启动容器的代码主要在ContainerImpl.java中进行。通过状态机转换，container从NEW状态向其他状态转移时，会调用RequestResourceTransition对象。RequestResourceTransition负责将所需的资源进行本地化，或者避免资源本地化。若需本地化，还需过渡到LOCALIZING状态。为简化理解，此处仅关注是否进行资源本地化的情况。
为了将LAUNCH_CONTAINER事件加入事件处理队列，调用了sendLaunchEvent方法。该事件由ContainersLauncher负责处理。ContainersLauncher的handle方法中，使用一个ExecutorService（线程池）容器Launcher。ContainerLaunch实现了Callable接口，其call方法生成并执行launch_container脚本。以MapReduce框架为例，该脚本在hadoop.tmp.dir/application name/container name目录下生成，其主要作用是启动MRAppMaster进程，即MapReduce的ApplicationMaster。