如何把github上的仓库私有

1、只有属于自己的仓库才能设置为私有，包括我们fork的属于别人的仓库。首先进入我们拥有所有权的Github仓库的主页，点击右上方的Settings进入仓库的设置。

2、进入仓库的设置界面之后，滑动到页面最底端，找到【Danger Zone】设置菜单区域。

3、找到【Danger Zone】菜单区域中的【Make this repository private】选项，点击【Make privete】按钮。

4、在d出的确认对话框中，输入自己的【用户名/仓库名】，再点击下方的按钮确认该 *** 作。

5、更改完成后，在仓库的设置【Danger Zone】菜单区域中的【Make this repository private】选项变成了【Make this repository public】。

在本地计算机与GitHub（或GitLab）进行通信时，传输主要基于两种协议，HTTPS和SSH，对应的仓库地址就是HTTPS URLs和SSH URLs。

首先需要强调的是，HTTPS URLs和SSH URLs对应的是两套完全独立的权限校验方式，主要的区别就是HTTPS URLs采用账号密码进行校验，SSH URLs采用SSH秘钥对进行校验。平时使用的时候我们可以根据实际情况，选择一种即可。

HTTPS URLs

GitHub官方推荐采用HTTPS URLs的方式，因为该种方式适用面更广（即使在有防火墙或代理的情况下也同样适用），使用更方便（配置更简单）。

采用HTTPS URLs地址clone/fetch/pull/push仓库时，事先无需对本地系统进行任何配置，只需要输入GitHub的账号和密码即可。不过如果每次都要手动输入账号密码，也是一件很繁琐的事情。

好在已经有多个机制可以让 *** 作不用这么麻烦。

在Mac系统中，在启用Keychain机制的情况下，首次输入GitHub账号密码后，认证信息就会自动保存到系统的Keychain中，下次再次访问仓库时就会自动读取Keychain中保存的认证信息。

在非Mac系统中，虽然没有Keychain机制，但是Git提供了credential helper机制，可以将账号密码以cache的形式在内存中缓存一段时间（默认15分钟），或者以文件的形式存储起来（~/.git-credentials）。当然，Mac系统如果不启用Keychain机制，也可以采用这种方式。

# cache credential in memory

$ git config --global credential.helper cache

# store credential in ~/.git-credential

$ git config --global credential.helper store

在credential.helper设置为store的情况下，首次输入GitHub账号密码后，就会自动保存到~/.git-credentials文件中，保存形式为https://user:pass@github.com；下次再次访问仓库时就会自动读取~/.git-credentials中保存的认证信息。

另一个需要说明的情况是，如果在GitHub中开启了2FA（two-factor authentication），那么在本地系统中输入GitHub账号密码时，不能输入原始的密码（即GitHub网站的登录密码），而是需要事先在GitHub网站中创建一个Personal access token，后续在访问代码仓库需要进行权限校验的时候，采用access token作为密码进行输入。

SSH URLs

除了HTTPS URLs，还可以采用SSH URLs的方式访问GitHub代码仓库。

采用SSH URLs方式之前，需要先在本地计算机中生成SSH keypair（秘钥对，包括私钥和公钥）。默认情况下，生成的秘钥位于$HOME/.ssh/目录中，文件名称分别为id_rsa和id_rsa.pub，通常无需修改，保持默认即可。不过，如果一台计算机中存在多个秘钥对，就需要修改秘钥文件名，名称没有强制的命名规范，便于自己辨识即可。

如下是创建秘钥对的过程。

➜ ssh-keygen -t rsa -b 4096 -C "mail@debugtalk.com"

Generating public/private rsa key pair.

Enter file in which to save the key (/Users/Leo/.ssh/id_rsa): /Users/Leo/.ssh/debugtalk_id_rsa

Enter passphrase (empty for no passphrase): <myPassphrase>

Enter same passphrase again: <myPassphrase>

Your identification has been saved in /Users/Leo/.ssh/debugtalk_id_rsa.

Your public key has been saved in /Users/Leo/.ssh/debugtalk_id_rsa.pub.

The key fingerprint is:

SHA256:jCyEEKjlCU1klROnuBg+UH08GJ1u252rQMADdD9kYMo mail@debugtalk.com

The key's randomart image is:

+---[RSA 4096]----+

|+*BoBO+. |

|o=oO=** |

|++E.*+o. |

|+ooo +o+ |

|.o. ..+oS. . |

| . o. . o |

| .. |

| . . |

|.. |

+----[SHA256]-----+

在创建秘钥的过程中，系统还建议创建一个名为passphrase的东西，这是用来干嘛的呢？

首先，单独采用密码肯定是不够安全的。如果密码太简单，那么就很容易被暴力破解，如果密码太复杂，那么用户就很难记忆，记录到小本子里面更不安全。

因此，SSH keys诞生了。SSH秘钥对的可靠性非常高，被暴力破解的可能性基本没有。不过，这要求用户非常谨慎地保管好私钥，如果别人使用你的计算机时偷偷地将你的私钥拷走了，那么就好比是别人拿到了你家里的钥匙，也能随时打开你家的门。

基于以上情况，解决办法就是在SSH keys之外再增加一个密码，即passphrase。只有同时具备SSH private key和passphrase的情况下，才能通过SSH的权限校验，这就大大地增加了安全性。当然，这个passphrase也不是必须的，在创建秘钥对时也可以不设置passphrase。

另外，如果每次权限校验时都要输入passphrase，这也是挺麻烦的。好在我们不用再担心这个问题，因为ssh-agent可以帮我们记住passphrase，Mac系统的Keychain也可以记住passphrase，这样我们在同一台计算机中就不用重新输入密码了。

秘钥对创建好以后，私钥存放于本地计算机（~/.ssh/id_rsa），将公钥（~/.ssh/id_rsa.pub）中的内容添加至GitHub账户。

# copy the contents of id_rsa.pub to the clipboard

➜ pbcopy <~/.ssh/id_rsa.pub

# paste to GitHub

# Login GitHub, 【Settings】->【SSH and GPG keys】->【New SSH Key】

不过，如果此时检测本地计算机与GitHub的连接状态，会发现系统仍提示权限校验失败。

➜ ssh -T git@github.com

Permission denied (publickey).

这是因为在本地计算机与GitHub建立连接的时候，实际上是本机计算机的ssh-agent与GitHub服务器进行通信。虽然本地计算机有了私钥，但是ssh-agent并不知道私钥存储在哪儿。因此，要想正常使用秘钥对，需要先将私钥加入到本地计算机的ssh-agent中（添加过程中需要输入passphrase）。

# start ssh-agent in the background

➜ eval "$(ssh-agent -s)"

Agent pid 78370

➜ ssh-add ~/.ssh/id_rsa

Enter passphrase for /Users/Leo/.ssh/id_rsa: <myPassphrase>

Identity added: /Users/Leo/.ssh/id_rsa (/Users/Leo/.ssh/id_rsa)

添加完成后，就可以查看到当前计算机中存储的密钥。

➜ ssh-add -l

4096 SHA256:xRg49AgTxxxxxxxx8q2SPPOfxxxxxxxxRlBY /Users/Leo/.ssh/id_rsa (RSA)

再次检测本地计算机与GitHub的连接状态，校验就正常通过了。

➜ ssh -T git@github.com

Hi djileolee! You've successfully authenticated, but GitHub does not provide shell access.

后续再进行clone/fetch/pull/push *** 作时，就可以正常访问GitHub代码仓库了，并且也不需要再重新输入账号密码。

而且，将私钥加入ssh-agent后，即使删除私钥文件，本地计算机仍可以正常访问GitHub代码仓库。

➜ rm -rf ~/.ssh

➜ ssh-add -l

4096 SHA256:xRg49AgTxxxxxxxx8q2SPPOfxxxxxxxxRlBY /Users/Leo/.ssh/id_rsa (RSA)

➜ ssh -T git@github.com

The authenticity of host 'github.com (192.30.252.130)' can't be established.

RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'github.com,192.30.252.130' (RSA) to the list of known hosts.

Hi djileolee! You've successfully authenticated, but GitHub does not provide shell access.

只有执行ssh-add -D或ssh-add -d pub_key命令，将私钥从ssh-agent删除后，认证信息才会失效。

➜ ssh-add -d ~/.ssh/id_rsa.pub

Identity removed: /Users/Leo/.ssh/id_rsa.pub (mail@debugtalk.com)

➜ ssh-add -l

The agent has no identities.

➜ ssh -T git@github.com

Permission denied (publickey).

同时使用多个GitHub账号

熟悉了HTTPS URLs和SSH URLs这两种校验方式之后，我们再来看之前遇到的问题。要想在一台计算机上同时使用多个GitHub账号访问不同的仓库，需要怎么做呢？

为了更好地演示，现假设有两个GitHub账号，debugtalk和djileolee，在两个账号中各自有一个仓库，debugtalk/DroidMeter和DJIXY/MobileStore（公司私有库）。

前面已经说过，HTTPS URLs和SSH URLs对应着两套独立的权限校验方式，因此这两套方式应该是都能单独实现我们的需求的。

不过在详细讲解Git权限校验的问题之前，我们先来回顾下Git配置文件的优先级。

Git配置存储位置及其优先级

Unix-like系统中，保存Git用户信息的主要有3个地方（Mac系统多一个Keychain）：

/etc/gitconfig：存储当前系统所有用户的git配置信息，使用带有--system选项的git config时，配置信息会写入该文件；

~/.gitconfig或~/.config/git/config：存储当前用户的git配置信息，使用带有--global选项的git config时，配置信息会写入该文件；

Keychain Access：在开启Keychain机制的情况下，进行权限校验后会自动将账号密码保存至Keychain Access。

仓库的Git目录中的config文件（即repo/.git/config）：存储当前仓库的git配置信息，在仓库中使用带有--local选项的git config时，配置信息会写入该文件；

在优先级方面，以上4个配置项的优先级从上往下依次上升，即repo/.git/config的优先级最高，然后Keychain Access会覆盖~/.gitconfig中的配置，~/.gitconfig会覆盖/etc/gitconfig中的配置。

基于SSH协议实现多账号共存

先来看下如何采用SSH URLs实现我们的需求。

在处理多账号共存问题之前，两个账号均已分别创建SSH秘钥对，并且SSH-key均已加入本地计算机的ssh-agent。

➜ ssh-add -l

4096 SHA256:lqujbjkWM1xxxxxxxxxxG6ERK6DNYj9tXExxxxxx8ew /Users/Leo/.ssh/dji_id_rsa (RSA)

4096 SHA256:II2O9vZutdQr8xxxxxxxxxxD7EYvxxxxxxbynx2hHtg /Users/Leo/.ssh/id_rsa (RSA)

在详细讲解多账号共存的问题之前，我们先来回想下平时在Terminal中与GitHub仓库进行交互的场景。

➜ DroidMeter git:(master) git pull

Already up-to-date.

➜ DroidMeter git:(master) touch README.md

➜ DroidMeter git:(master) ✗ git add .

➜ DroidMeter git:(master) ✗ git commit -m "add README"

➜ DroidMeter git:(master) git push

Counting objects: 3, done.

Delta compression using up to 4 threads.

Compressing objects: 100% (2/2), done.

Writing objects: 100% (3/3), 310 bytes | 0 bytes/s, done.

Total 3 (delta 0), reused 0 (delta 0)

To git@debugtalk:debugtalk/DroidMeter.git

7df6839..68d085b master ->master

在 *** 作过程中，本地计算机的ssh-agent与GitHub服务器建立了连接，并进行了账号权限校验。

当本地计算机只有一个GitHub账号时，这个行为并不难理解，系统应该会采用这个唯一的GitHub账号进行 *** 作。那如果本地计算机中有多个Github账号时，系统是根据什么来判断应该选择哪个账号呢？

实际情况是，系统没法进行判断。系统只会有一个默认的账号，然后采用这个默认的账号去 *** 作所有的代码仓库，当账号与仓库不匹配时，就会报权限校验失败的错误。

那要怎样才能让系统正确区分账号呢？这就需要我们手动进行配置，配置文件即是~/.ssh/config。

创建~/.ssh/config文件，在其中填写如下内容。

# debugtalk

Host debugtalk

HostName github.com

User git

IdentityFile ~/.ssh/id_rsa

# DJI

Host djileolee

HostName github.com

User git

IdentityFile ~/.ssh/dji_id_rsa

要理解以上配置文件的含义并不难，我们可以对比看下两个项目的SSH URLs：

git@github.com:debugtalk/DroidMeter.git

git@github.com:DJISZ/Store_Android.git

其中，git是本地ssh-agent与GitHub服务器建立SSH连接采用的用户名（即User），http://github.com是GitHub服务器的主机（即HostName）。

可以看出，如果采用原始的SSH URLs，由于User和HostName都相同，本地计算机并不知道应该采用哪个SSH-key去建立连接。

因此，通过创建~/.ssh/config文件，在Host中进行区分，然后经过CNAME映射到HostName，然后分别指向不同的SSH-key，即IdentityFile。由于HostName才是真正指定GitHub服务器主机的字段，因此这么配置不会对本地ssh-agent连接GitHub主机产生影响，再加上Host别名指向了不同的SSH-key，从而实现了对两个GitHub账号的分离。

配置完毕后，两个GitHub账号就可以通过Host别名来进行区分了。后续再与GitHub服务器进行通信时，就可以采用Host别名代替原先的http://github.com。例如，测试本地ssh-agent与GitHub服务器的连通性时，可采用如下方式：

➜ ssh -T git@debugtalk

Hi debugtalk! You have successfully authenticated, but GitHub does not provide shell access.

➜ ssh -T git@djileolee

Hi djileolee! You have successfully authenticated, but GitHub does not provide shell access.

可以看出，此时两个账号各司其职，不会再出现混淆的情况。

不过，我们还遗漏了很重要的一点。在本地代码仓库中执行push/pull/fetch等 *** 作的时候，命令中并不会包含Host信息，那系统怎么知道我们要采用哪个GitHub账号进行 *** 作呢？

答案是，系统还是没法判断，需要我们进行配置指定。

显然，不同的仓库可能对应着不同的GitHub账号，因此这个配置不能配置成全局的，而只能在各个项目中分别进行配置，即repo/.git/config文件。

配置的方式如下：

在debugtalk/DroidMeter仓库中：

➜ git remote add origin git@debugtalk:debugtalk/DroidMeter.git

在DJIXY/MobileStore.git仓库中：

➜ git remote add origin git@djileolee:DJIXY/MobileStore.git

配置的原理也很容易理解，就是将仓库的Host更换为之前设置的别名。添加完毕后，后续再在两个仓库中执行任何git *** 作时，系统就可以选择正确的SSH-key与GitHub服务器进行交互了。

基于HTTPS协议实现多账号共存

再来看下如何采用HTTPS URLs实现我们的需求。

有了前面的经验，我们的思路就清晰了许多。采用HTTPS URLs的方式进行Git权限校验后，系统会将GitHub账号密码存储到Keychain中（Mac系统），或者存储到~/.git-credentials文件中（Git credential helper）。

不管是存储到哪里，我们面临的问题都是相同的，即如何在代码仓库中区分采用哪个GitHub账号。

配置的方式其实也很简单：

在debugtalk/DroidMeter仓库中：

➜ git remote add origin https://debugtalk@github.com/debugtalk/DroidMeter.git

在DJIXY/MobileStore.git仓库中：

➜ git remote add origin https://djileolee@github.com/DJIXY/MobileStore.git

配置的原理也很容易理解，将GitHub用户名添加到仓库的Git地址中，这样在执行git命令的时候，系统就会采用指定的GitHub用户名去Keychain或~/.git-credentials中寻找对应的认证信息，账号使用错乱的问题也就不复存在了。

10大企业看板工具软件：1.软件开发项目看板 PingCode；2.通用看板软件 Worktile；3.开源看板软件 Wekan；4.免费看板软件 Trello；5.个人和小团队的看板软件 Todoist ；6.开源免费看 Kanboard；7.面向个人免费的看板 Teambition；8.软件开发项目看板 Jira；9.开源项目看板 LibreBoard；10.开源看板 Jitamin。

看板方法通常用于不同行业的软件开发、项目管理、任务管理、敏捷开发，所以这里除了盘点顶级的一些看板软件工具，还将详细说明其适用领域、功能、优缺点。

一、国内外10大主流看板工具软件

看板方法通常用于不同行业的软件开发、项目管理、任务管理、敏捷开发，所以这里除了盘点顶级的一些看板软件工具，还将详细说明其适用领域、功能、优缺点。

1. 软件开发项目看板 PingCode

在《2022看板状态报告》曾提到“强烈推荐依据看板理念而设计的工具”，而 PingCode 就是这样一款工具，支持可视化价值流动，创建团队个性化的工作流（自定义配置Kanban、栏、触发器），WIP 限制、自定义卡片字段、设置DOD、版本规划等等。”

PingCode 是一款专门为软件开发而打造的看板软件，在2021年入选36氪发布的研发领域-项目管理榜单评分第一；2022年入选年度企服口碑产品。

PingCode 还是一款覆盖研发全生命周期的管理系统，被广泛用于需求收集、需求管理、需求优先级、产品路线图、项目管理（支持敏捷/kanban/瀑布）、测试管理、缺陷追踪、项目文档管理、效能度量、目标管理等领域。并且集成了github、gitlab、jinkens、企微、飞书等主流工具，也就是说我们能在需求下面关联代码，关联集成信息，在飞书查看通知等。

软件优势：

依据看板理念打造，标准化功能成熟

产品开箱即用，简单易上手，不需要像Jira 那样经过好几月的培训，以及专门的系统管理专家配置系统才可使用；

为25人以下团队免费提供基础版本，收费版价格仅为国外产品Jira的30%-40%；

国产化，支持信创、麒麟等；

支持私有部署、定制化以及saas等购买方式；

口碑、服务支持好；

软件缺点：

暂未提供多语言版本；

PingCode 官网

2.通用看板软件 Worktile

Worktile 是国内的一款基于看板框架的而打造的项目管理工具，在国内拥有60万+企业用户，比如金山、人民网、京东金融、小米等等，是国内使用最为广泛的项目管理看板软件之一。Worktile 几乎每年都入选36氪发布的“项目管理工具排行榜”（2021年TOP1）、国家信创委员会发布的“信创项目管理企业排行榜”前三。

这款看板软件非常适合10-1000人规模的中大型团队来搭建看板管理系统，能够满足电商、市场活动、律所项目、生产制造、行政、财务、设计、工程、教育、科研等几乎包含所有类型的项目。

Worktile 看板的核心功能包括：看板泳道（甬道）、自定义泳道（甬道）、WIP限制（Limit Work In Progress）、将步骤拆分为Doing/Done &DoD、可视化报表（支持自定义）、多种视图查看、自定义筛选、权限管理、支持在飞书、企业微信等产品中使用等等。

除此以外，它还支持其他类型的项目管理，有丰富的模板市场，满足不同场景的项目管理需求；Worktile还具备OKR（目标）管理、审批、简报、IM、网盘等模块，是一个工具的集合，能同时满足企业多种工具化管理需求，从而大幅降低成本。

软件优势：

能够满足绝大部分类型的看板管理需求，自定义能力非常强，可以搭建适合团队的项目模板和管理流程；

开箱即用，上手简单，价格相对便宜；

能够很大程度帮助团队节省成本，因为它是一个工具集合能够同时满足项目、OKR、网盘、OA等需求；

支持saas、私有部署、定制等购买方案；

为10人以下团队提供基础的免费版本

软件缺点：

在软件项目管理的专业度上不如 PingCode 等垂直领域的产品

Worktile官网

3. 开源看板软件 Wekan

Wekan 作为一款开源看板工具，你可以让它完全在本地运行，或者使用你自己选择的服务运行它。主要的kanban 功能在 Wekan 里几乎都有，例如创建看板、列表、泳道、卡片，在列表间拖放，给指定的用户安排任务，给卡片添加标签等等，基本上你对一款现代看板软件的功能需求它都能提供。

软件优缺点：

Wekan 的设计没有其他看板软件的好看，样式有些显旧，但是其功能虽然并不如PingCode、Worktile 等成熟，但也相对完善，其优点是可以在本地搭建，开源免费，上手简单。

官网： https://wekan.github.io/

4.免费看板软件 Trello

Trello 是早些年在国内非常出名的一个免费的在线看板工具，当然也不是完全免费，只是绝大部分功能免费。它和 Worktile 一样也是一款能服务几乎所有类型项目的看板工具。

你可以通过它创建板块、添加卡片、设置到期日期、分配任务、分享文件、与其他应用程序集成等等，使用 Power-Ups 后，你还可以添加地图、日历、投票以及各种第三方的集成，使其更适合自己的业务和团队。

软件优势：

Trello非常适合小团队和新人使用，尤其是它简单容易上手，无需学习甚至不了解看板也能立即使用，并配有iOS、Android移动应用程序，可以随时随地管理你的任务；

软件缺点：

缺乏创建预算/发票的财务工具

有限的数据表功能

不适合复杂的项目

官网： https://Trello.com/

5.个人和小团队的看板软件 Todoist

Todoist 在国外非常出名，是一款为个人和团队打造的任务管理软件，它不仅提供了常规的清单方式管理项目，还允许你用看板来管理任务，你可以添加新的看板，也可以将已有的清单转换为看板模式，可以将任务管理和看板结合使用，并且软件支持协作功能，可以和他人分享评论，共同使用看板来管理任务，如果你想要使用看板来管理自己每天任务的话，Todoist是一个不错的选择。

软件优点：

丰富的 Web 服务，结合 IFTTT 可以做很多事情

支持多人协作模式

软件缺点 :

对 Native 支持较差，客户端本质上是个加壳 Web 页面

不支持原生快捷键

官网： https://todoist.com/zh-CN

6.开源免费看 Kanboard

Kanboard 是一个相当简洁的看板工具，但它具备较为完善的一些功能，包括任务搜索和过滤，子任务，附件，评论等等，以及一些适宜的分析和报告。Kanboard 很容易安装，占用的资源很少（比如你可以运行在Raspberry Pi），而且已经被翻译成许多不同的语言。

软件优点：

软件开源免费，支持二次定制开发，满足个性化的管理需求；

多种语言选择；

界面超级简单， *** 作简单易上手；

软件缺点：

功能不成熟，界面过于简陋

官网： https://kanboard.org/

7.面向个人免费的看板 Teambition

钉钉旗下的一款看板类项目管理软件，更适用于小型团队项目协作，被广泛用于适合产品、研发、设计、市场、运营、销售、HR等各类团队。Teambition 以项目和任务的可视化管理来支撑小团队协作，含任务、文档、文件、统计、甘特图等丰富应用。

软件优点：

承诺个人版本永不收费；

优秀的产品界面和 *** 作体验；

工具融合，打破信息孤岛，集成了项目管理、文档管理、资源管理、流程管理、沟通协作等工具，支持不同的业务场景；

深度嵌入钉钉，对同时使用钉钉的用户来说非常友好；

软件缺点：

Teambition核心在任务及项目管理，为了追求的“简单易用”，牺牲了项目目标和分层分级权限管理——整体适用场景较为局限，难以实现项目的闭环管理（缺少目标、网盘管理能力）。

自定义能力不强，无法很好的满足团队的个性化需求；

无法与企业微信、飞书等外部工具打通；

官网： https://www.teambition.com/

8.软件开发项目看板 Jira

全球最早的软件研发过程管理工具之一，但近些年对国内用户的政策并不友好，特别是停售 Server 版。但其仍是全球最知名的IT项目管理软件之一。

JIRA 是工程师用来跟踪和管理任务的软件开发工具。您可以将它用于敏捷和瀑布项目管理，以跟踪错误、功能和其他工作项。您还可以将 JIRA 配置为与许多服务管理工具一起使用，使其成为管理任务的多功能工具。

软件优点：

更好的工作流程可见性；

时间跟踪帮助节省资源

提高生产力

为10人以下团队提供基础免费版本；

强大的第三方集成

软件缺点：

国内不支持私有部署版本，只提供saas版本，但国内又不设服务器；

购买成本高昂，百人左右团队动辄上百万；

新人上手使用成本高，需要长达几个月的培训以及专业的系统配置人员才可使用；

访问速度慢

官网： https://www.atlassian.com/zh/software/jira

9.开源项目看板 LibreBoard

LibreBoard 是一个卡片式的组织 Kanban 的开源实现。可以用来实现团队内部的协作沟通，你可以把 LibreBoard 看成是 Trello 的开源版本。

官网： https://github.com/diegok/libreboard

10.开源看板 Jitamin

Jitamin (读作/ˈdʒɪtəmɪn/) 是一款免费、开源，使用PHP语言开发的项目管理系统。Jitamin灵感来自于Vitamin，并结合了Just In Time(准时)和敏的拼音min，意指效率与敏捷是项目管理的维他命。

官网： https://github.com/jitamin/jitamin

以上就是关于看板软件工具的一些介绍，希望对大家看板管理系统的选型有所帮助。

---