3.2. The Wireshark Git repository3.2. The Wireshark Git repository
is used to keep track of the changes made to the
Wireshark source code. The code is stored inside Wireshark project’s Git
repository located at a server at the wireshark.org domain.
Changes to the official repository are managed using the
code review system. Gerrit
makes it easy to test and discuss changes before they are
pushed to the main repository. For an overview of Gerrit see the
Git is a fast, flexible way of managing source code. It allows large
scale distributed development and ensures data integrity.
Why Gerrit?
Gerrit makes it easy to contribute. You can sign in with any OpenID
provider and push your changes. It’s usable from both the web and
command line and is integrated with many popular tools.
Git is our third revision control system
Wireshark originally used
(CVS) and migrated to
in July 2004.
The Subversion repository was subsequently migrated to Git in January 2014.
Using Wireshark’s Git repository you can:
Keep your private sources up to date with very little effort
Get a mail notification when the official source code changes
Get the source files from any previous release (or any other point in time)
Have a quick look at the sources using a web interface
See which person changed a specific piece of code
and much more
3.2.1. The web interface to the Git repository
If you need a quick look at the Wireshark source code you can
browse the most recent file versions in the master branch using Gitweb:
You can also view commit logs, branches, tags, and past revisions:
Like most revision control systems, Git uses
manage different copies of the source code and allow parallel development.
Wireshark uses the following branches for official releases:
master: Main feature development and odd-numbered "feature" releases.
master-x.y: Stable release maintenance. For example, master-1.10 is used
to manage the 1.10.x official releases.Wireshark 用户手册Updated 3 years ago
Subscribe Please log in to preview this contentYou can still access this book's content using the Read button.该项目未开启捐赠功能，可发送私信通知作者开启
与超过 300 万 开发者一起发现、参与优秀开源项目，私有仓库也完全免费 ：）
已有帐号？
由于 Git 不支持空文件夾，创建文件夹后会生成空的 .keep 文件
Loading...

thinkjs-admin
后台thinkjs，前台基于vue+vueRouter+vuex+elementUI，一个后台管理系统,登录状态设计基于token refresh_token 已完成，权限管理正在开发

启动命令
npm install
npm start

cd webpack
npm install
npm run build


帐号密码
admin
123456
#x-admin
正在加载...Filthy (feat. Phillip Morris, Vitamin D, Illegit & Sharkula) - Illuminati Congo - 单曲 - 网易云音乐
Filthy (feat. Phillip Morris, Vitamin D, Illegit & Sharkula)
所属专辑：
网易云音乐多端下载
同步歌单，随时畅听320k好音乐
网易公司版权所有(C)杭州乐读科技有限公司运营：
违法和不良信息举报电话：6
举报邮箱：git 有两个分支 a、a-&b， a 有更新以后用什么语句更新到 b？ - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
已注册用户请 &
git 有两个分支 a、a-&b， a 有更新以后用什么语句更新到 b？
11:28:50 +08:00 · 3412 次点击
a ：当前线上版本，需要不断修复 bug
b ：来源于 a ，在 b 上面开发新模块
两个分支都要保留，不能删除。
在 a 上面更新代码以后，怎么也更新到 b ？
27 回复 &| &直到
23:18:30 +08:00
& & 11:32:20 +08:00
git checkout a & git pull & git checkout b & git rebase a
& & 11:33:58 +08:00
线上分支不应该直接在上面更新代码吧
& & 11:40:09 +08:00
看看 git flow 流程， A 分支有 bug 应该新开一个 /hotfix 分支，修改上线后合并到 B 的 feature 分支
& & 11:43:29 +08:00
@ 你是不是看错需求了？@ 啥意思？
& & 11:45:08 +08:00 via Android
@ 我觉得我写的满足了你的需求。
& & 11:45:26 +08:00
似乎只能使用 rebase 了
& & 11:48:25 +08:00
merge/rebase 有问题吗？ 一楼的说的应该没问题吧
& & 11:50:21 +08:00
切到 b 然后 rebase a
& & 11:52:53 +08:00
这种开发模式是非常典型可以用 Git 最佳实践的。请参考：
& & 11:55:39 +08:00
一楼可行，不想切分支的话可以这么搞，效果相同： 在 b 上 git pull --rebase origin a
& & 11:59:14 +08:00
一种做法是走 rebasegit checkout bgit rebase a我觉得更好的做法是每一个 BUG 都从 a 拉出一个分支，这个分支开发完后同时 merge 到 a 和 b
& & 12:09:55 +08:00
@ @ @ 先谢谢回复rebase 或 merge 会删除分支吗？
我的需求是 a 、 b 分支都不能消失
& & 12:12:32 +08:00
cherry-pick 看是不是你想要的
& & 12:23:17 +08:00
如果不是“同步”分支，建议 cherry-pick
& & 12:34:12 +08:00
@ 不会，分支只有你手动才删得掉，其它任何操作都不会删除分支
& & 12:48:22 +08:00
git checkout a -& git merge b 吗?
& & 12:49:16 +08:00
cherry-pickcherry-pickcherry-pick
& & 12:49:39 +08:00
少量提交可以用 cherry-pick多一点的提交，看看能不能用 rebase
& & 12:53:48 +08:00
如果能 merge --ff-only, 也可以这样
& & 12:55:36 +08:00
建议楼主先熟悉一下 git 基础和 git-flow ， 楼上说的 rebase/merge/cherry-pick 都可以，用哪种方法完全取决去个人爱好,洁癖用 rebase强迫症用 merge爱折腾用 cherry-pick
& & 13:11:51 +08:00
在 b 上 merge a 就可以了啊，没有什么必要 rebase 。cherry pick 会产生很多新的 commit ，更没有必要了。
& & 13:32:09 +08:00
@ 用 b rebase a 就可以了啊，没有什么必要 merge 。
& & 13:34:42 +08:00
rebase 被玩坏了
& & 13:56:35 +08:00
建议用 mergerebase 可能会导致 non-fastforwardcherry-pick 少量 commit 没问题，多了累
& & 14:03:21 +08:00
没有争议的问题 为啥还讨论这么激烈 蛋疼
& & 14:18:26 +08:00
git rebase -i &branch& 是正确的用法
& & 23:18:30 +08:00
On branch B1. branch_b cleangit merge branch_a2. branch_b can not merge before commitgit stashgit merge branch_a* may need fix confilct thengit stash pop遇到不可合并的二进制文件,需要重新 git checkout file
& · & 2727 人在线 & 最高记录 3762 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.1 · 18ms · UTC 05:17 · PVG 13:17 · LAX 22:17 · JFK 01:17? Do have faith in what you're doing.}