- Kibana Guide: other versions:
- What is Kibana?
- What’s new in 8.17
- Kibana concepts
- Quick start
- Set up
- Install Kibana
- Configure Kibana
- AI Assistant settings
- Alerting and action settings
- APM settings
- Banners settings
- Cases settings
- Enterprise Search settings
- Fleet settings
- i18n settings
- Logging settings
- Logs settings
- Metrics settings
- Monitoring settings
- Reporting settings
- Search sessions settings
- Secure settings
- Security settings
- Spaces settings
- Task Manager settings
- Telemetry settings
- URL drilldown settings
- Start and stop Kibana
- Access Kibana
- Securing access to Kibana
- Add data
- Upgrade Kibana
- Configure security
- Configure reporting
- Configure logging
- Configure monitoring
- Command line tools
- Production considerations
- Discover
- Dashboards
- Canvas
- Maps
- Build a map to compare metrics by country or region
- Track, visualize, and alert on assets in real time
- Map custom regions with reverse geocoding
- Heat map layer
- Tile layer
- Vector layer
- Plot big data
- Search geographic data
- Configure map settings
- Connect to Elastic Maps Service
- Import geospatial data
- Troubleshoot
- Reporting and sharing
- Machine learning
- Graph
- Alerting
- Observability
- Search
- Security
- Dev Tools
- Fleet
- Osquery
- Stack Monitoring
- Stack Management
- Cases
- Connectors
- Amazon Bedrock
- Cases
- CrowdStrike
- D3 Security
- Google Gemini
- IBM Resilient
- Index
- Jira
- Microsoft Teams
- Observability AI Assistant
- OpenAI
- Opsgenie
- PagerDuty
- SentinelOne
- Server log
- ServiceNow ITSM
- ServiceNow SecOps
- ServiceNow ITOM
- Swimlane
- Slack
- TheHive
- Tines
- Torq
- Webhook
- Webhook - Case Management
- xMatters
- Preconfigured connectors
- License Management
- Maintenance windows
- Manage data views
- Numeral Formatting
- Rollup Jobs
- Manage saved objects
- Security
- Spaces
- Advanced Settings
- Tags
- Upgrade Assistant
- Watcher
- REST API
- Get features API
- Kibana spaces APIs
- Kibana role management APIs
- User session management APIs
- Saved objects APIs
- Data views API
- Index patterns APIs
- Alerting APIs
- Action and connector APIs
- Cases APIs
- Import and export dashboard APIs
- Logstash configuration management APIs
- Machine learning APIs
- Osquery manager API
- Short URLs APIs
- Get Task Manager health
- Upgrade assistant APIs
- Synthetics APIs
- Uptime APIs
- Kibana plugins
- Troubleshooting
- Accessibility
- Release notes
- Upgrade notes
- Kibana 8.17.1
- Kibana 8.17.0
- Kibana 8.16.3
- Kibana 8.16.2
- Kibana 8.16.1
- Kibana 8.16.0
- Kibana 8.15.5
- Kibana 8.15.4
- Kibana 8.15.3
- Kibana 8.15.2
- Kibana 8.15.1
- Kibana 8.15.0
- Kibana 8.14.3
- Kibana 8.14.2
- Kibana 8.14.1
- Kibana 8.14.0
- Kibana 8.13.4
- Kibana 8.13.3
- Kibana 8.13.2
- Kibana 8.13.1
- Kibana 8.13.0
- Kibana 8.12.2
- Kibana 8.12.1
- Kibana 8.12.0
- Kibana 8.11.4
- Kibana 8.11.3
- Kibana 8.11.2
- Kibana 8.11.1
- Kibana 8.11.0
- Kibana 8.10.4
- Kibana 8.10.3
- Kibana 8.10.2
- Kibana 8.10.1
- Kibana 8.10.0
- Kibana 8.9.2
- Kibana 8.9.1
- Kibana 8.9.0
- Kibana 8.8.2
- Kibana 8.8.1
- Kibana 8.8.0
- Kibana 8.7.1
- Kibana 8.7.0
- Kibana 8.6.1
- Kibana 8.6.0
- Kibana 8.5.2
- Kibana 8.5.1
- Kibana 8.5.0
- Kibana 8.4.3
- Kibana 8.4.2
- Kibana 8.4.1
- Kibana 8.4.0
- Kibana 8.3.3
- Kibana 8.3.2
- Kibana 8.3.1
- Kibana 8.3.0
- Kibana 8.2.3
- Kibana 8.2.2
- Kibana 8.2.1
- Kibana 8.2.0
- Kibana 8.1.3
- Kibana 8.1.2
- Kibana 8.1.1
- Kibana 8.1.0
- Kibana 8.0.0
- Kibana 8.0.0-rc2
- Kibana 8.0.0-rc1
- Kibana 8.0.0-beta1
- Kibana 8.0.0-alpha2
- Kibana 8.0.0-alpha1
- Developer guide
How we use Git and GitHub
editHow we use Git and GitHub
editForking
editWe follow the GitHub
forking model for collaborating on Kibana code. This model assumes that
you have a remote called upstream
which points to the official Kibana
repo, which we’ll refer to in later code snippets.
Branching
editAt Elastic, all products in the stack, including Kibana, are released at the same time with the same version number. Most of these projects have the following branching strategy:
-
main
points to the next minor version. -
<major>.<minor>
is the previously released minor version, including patch releases.
As an example, let’s assume that the main branch is currently a not-yet-released 8.1.0. Once 8.1.0 has reached feature freeze, it will be branched to 8.1 and main will be updated to reflect 8.2.0. The release of 8.1.0 and subsequent patch releases will be cut from the 8.1 branch. At any time, you can verify the current version of a branch by inspecting the version attribute in the package.json file within the Kibana source.
Pull requests are made into the main
branch and then backported when it is safe and appropriate.
-
Breaking changes can only be made to
main
if there has been at least an 18 month deprecation period and the breaking change has been approved. Telemetry showing current usage is crucial for gaining approval. -
Features should not be backported to a
<major>.<minor>
branch. -
Bug fixes can be backported to a
<major>.<minor>
branch if the changes are safe and appropriate. Safety is a judgment call you make based on factors like the bug’s severity, test coverage, confidence in the changes, etc. Your reasoning should be included in the pull request description. - Documentation changes can be backported to any branch at any time.
Commits and Merging
edit- Feel free to make as many commits as you want, while working on a branch.
- When submitting a PR for review, please perform an interactive rebase to present a logical history that’s easy for the reviewers to follow.
- Please use your commit messages to include helpful information on your changes, e.g. changes to APIs, UX changes, bugs fixed, and an explanation of why you made the changes that you did.
- Resolve merge conflicts by rebasing the target branch over your feature branch, and force-pushing (see below for instructions).
- When merging, we’ll squash your commits into a single commit.
Commit using your @elastic.co
email address
editIn order to assist with developer tooling we ask that all Elastic engineers use their @elastic.co
email address when committing to the Kibana repo. We have implemented a CI check that validates any PR opened by a member of the @elastic
organization has at least one commit that is attributed to an @elastic.co
email address. If you have a PR that is failing because of this check you can fix your PR by following these steps:
- Ensure that you don’t have any staged changes
- Checkout the branch for your PR
-
Update the git config for your current repository to commit with your
@elastic.co
email:git config user.email YOUR_ELASTIC_EMAIL@elastic.co
-
Create a commit using the new email address
git commit -m 'commit using @elastic.co' --allow-empty
- Push the new commit to your PR and the status should now be green
Rebasing and fixing merge conflicts
editRebasing can be tricky, and fixing merge conflicts can be even trickier
because it involves force pushing. This is all compounded by the fact
that attempting to push a rebased branch remotely will be rejected by
git, and you’ll be prompted to do a pull
, which is not at all what you
should do (this will really mess up your branch’s history).
Here’s how you should rebase master onto your branch, and how to fix merge conflicts when they arise.
First, make sure master is up-to-date.
git checkout master git fetch upstream git rebase upstream/master
Then, check out your branch and rebase master on top of it, which will apply all of the new commits on master to your branch, and then apply all of your branch’s new commits after that.
git checkout name-of-your-branch git rebase master
You want to make sure there are no merge conflicts. If there are merge conflicts, git will pause the rebase and allow you to fix the conflicts before continuing.
You can use git status
to see which files contain conflicts. They’ll
be the ones that aren’t staged for commit. Open those files, and look
for where git has marked the conflicts. Resolve the conflicts so that
the changes you want to make to the code have been incorporated in a way
that doesn’t destroy work that’s been done in master. Refer to master’s
commit history on GitHub if you need to gain a better understanding of how code is conflicting and how best to resolve it.
Once you’ve resolved all of the merge conflicts, use git add -A
to stage them to be committed, and then use
git rebase --continue
to tell git to continue the rebase.
When the rebase has completed, you will need to force push your branch because the history is now completely different than what’s on the remote. This is potentially dangerous because it will completely overwrite what you have on the remote, so you need to be sure that you haven’t lost any work when resolving merge conflicts. (If there weren’t any merge conflicts, then you can force push without having to worry about this.)
git push origin name-of-your-branch --force
This will overwrite the remote branch with what you have locally. You’re done!
Note that you should not run git pull, for example in response to a push rejection like this:
! [rejected] name-of-your-branch -> name-of-your-branch (non-fast-forward) error: failed to push some refs to 'https://github.com/YourGitHubHandle/kibana.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Assuming you’ve successfully rebased and you’re happy with the code, you should force push instead.
Creating a pull request
editSee Submitting a pull request for the next steps on getting your code changes merged into Kibana.
On this page