Giter Site home page Giter Site logo

git-flow-vis's Introduction

GitFlowVisualize

GitFlowVisualize is a javascript library to visualize git repositories that are using the Git Flow workflow. It uses conventions to know which lineage should be drawn as the master line and which as the develop line. The output is SVG using d3.js. The different types of branches are color coded (master, develop, feature, release, hotfix).

Installation

In the browser

You can use GitFlowVisualize directly in your browser by including the gitflow-visualize.js file from the dist/ folder. GitFlowVisualize is registered on the global namespace. Please note that you will also be required to include the following dependencies:

  • d3.js (v3)
  • Moment
  • ThenBy
  • Crypto-JS/MD5

If you are not using these dependencies in your own project, it might be easier to include gitflow-visualize.bundle.js. This version includes all required dependencies and will allow you to immediately start using GitFlowVisualize in your project.

In your NodeJS project

Simply install GitFlowVisualize by running

npm install git-flow-vis

and include it in your project by adding

const GitFlowVisualize = require('git-flow-vis');

Live Examples

You can find two live examples with dummy data in the examples/ folder. To see them in action, checkout the repository, run npm install to install all dependencies and npm run dist to compile the project. Afterwards, you can open the standalone.html or multiple_datasets.html examples in your browser.

Usage

GitFlowVisualize is available on the global namespace and can be used directly in your project. You can use the following placeholder to kickstart your project.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<meta charset="utf-8">
	<!-- 
		The GitFlowVisualize files are available in the 'dist' folder.
		'gitflow-visualize.bundle.min.js' is a minified version which includes all the dependencies. 
		You can also use 'gitflow-visualize.min.js' if you include all the required dependencies seperately.
	-->
	<script src="gitflow-visualize.bundle.min.js"></script>
	<link rel="stylesheet" type="text/css" href="gitflow-visualize.css">
</head>
<body>
	<div id="drawhere"></div>
	<script type="application/javascript">
		// See the 'options' section of the README for more information on how to confgure GitFlowVisualize
		// The 'dataCallback' and 'moreDataCallback' options are required and are used to retrieve commit data.
		var options = {
			drawElem: document.getElementById('drawhere'),
			dataCallback: function(done) { done({}); },
			moreDataCallback: function(from, done) { done(from, {}); }
		};
		GitFlowVisualize.draw(options);
	</script>
</body>
</html>

GitFlowVisualize also has support for AMD and CommonJS dependency resolving. If you wish to include GitFlowVisualise in your NodeJS project you can simply assign it to a variable:

const GitFlowVisualize = require('git-flow-vis');

GitFlowVisualize.draw([elem], opts)

elem
DOM object, placeholder of the Git Flow Chart.
opts
Object.

elem is an optional argument, opts is required. If elem is provided, it must be in the order shown. The elem can also be passed using the opts.drawElem option. If neither elem nor opts.drawElem is provided, a div placeholder will be appended to the document body tag.

opts

opts.drawElem is the DOM Element which is used as the placeholder in which the graph is drawn.

opts.drawTable is the DOM Element which is used as the placeholder to hold the commit data table. If not provided, the opts.drawElem element is used.

opts.masterRef is the git reference to the master branch. Defaults to 'refs/heads/master'.

opts.developRef is the git reference to the develop branch. Defaults to 'refs/heads/develop'.

opts.featurePrefix is the git reference prefix to all feature branches. Any branch that is prefixed with this value will be considered to be a feature branch. Defaults to 'refs/heads/feature'.

opts.releasePrefix is the git reference prefix to all release branches. Any branch that is prefixed with this value will be considered to be a release branch. Defaults to 'refs/heads/release'.

opts.hotfixPrefix is the git reference prefix to all hotfix release branches. Any branch that is prefixed with this value will be considered to be a hotfix release branch. Defaults to 'refs/heads/hotfix'.

opts.releaseZonePattern is a regular expression (RegExp) that can be used to include other branches in the colored 'Release' zone of the graph. Defaults to '/^refs/heads/bugfix/'.

opts.releaseTagPattern is a regular expression (RegExp) that can be used to identify release tags. Defaults to '^/refs\/tags\/\d+(\.\d+)+$/'.

opts.showSpinner() is a function that is called prior to starting processing of commit data and can be used to show a loading message.

opts.hideSpinner() is a function that is called when the commit data has been processed and the graph has been drawn.

opts.dataCallback(callback(data)) (required) is a function that is called by the graph to retrieve the commit data from the Git repository. It provides a callback function which expects a data parameter. The data parameter should use the following JSON schema:

{
	branches: { 
		values: [
			{
				"id": STRING - the Git reference to the branch,
				"displayId": STRING - the name of the branch to be displayed in the graph,
				"latestChangeset": STRING - the SHA hash of the latest changeset on the branch
			}
		]
	},
	tags: {
		values: [
			{
				"id": STRING - the Git reference to the tag,
				"displayId": STRING - the name of the tag to be displayed in the graph,
				"latestChangeset": STRING - the SHA hash of the latest changeset on the tag
			}
		]
	},
	commits: [
		{
			values: [
				{
					"id": STRING - the SHA hash of the commit,
					"displayId": STRING - the abbreviated SHA hash of the commit, 
					"author": { 
						"emailAddress": STRING - the email address of the commit author, 
						"displayName": STRING - the name of the author to be displayed in the graph
					}, 
					"authorTimestamp": INTEGER - the timestamp of the commit, 
					"message": STRING - the commit message, 
					"parents": [
						{ 
							"id": STRING - the SHA hash of the commit parent, 
							"displayId": STRING - the abbreviated SHA hash of the commit
						}
					]
				}
			]
		}
	]
}

opts.moreDataCallback(from, callback(data, from)) (required) is a function which is used by the commit graph to lazy load additional commit data on scroll. It passes the SHA hash of the last commit that it retrieved and a callback function which expects a data and from parameter. The data parameter should use the following JSON schema:

{
	"size": INTEGER - the number of commits in the values property,
	"values": [
		{
			"id": STRING - the SHA hash of the commit,
			"displayId": STRING - the abbreviated SHA hash of the commit, 
			"author": { 
				"emailAddress": STRING - the email address of the commit author, 
				"displayName": STRING - the name of the author to be displayed in the graph
			}, 
			"authorTimestamp": INTEGER - the timestamp of the commit, 
			"message": STRING - the commit message, 
			"parents": [
				{ 
					"id": STRING - the SHA hash of the commit parent, 
					"displayId": STRING - the abbreviated SHA hash of the commit
				}
			]
		}
	]
}

In this case, 'values' is an array of commits with the same JSON schema as the 'commits' property of the opts.dataCallback() function. The from parameter of the callback should be the same SHA hash that was provided in the from parameter of the opts.moreDataCallback() function.

opts.dataProcessed(data) is a function that is called when the graph has finished processing the commit data. It passes a data parameter which includes detailed information of all the commits that have been processed by the graph.

opts.createCommitUrl(commit) is a function that is called for each commit which can be used to generate a URL reference to the commit source. The commit parameter has the same JSON schema as a commit in the commits property of the opts.dataCallback() function.

opts.createAuthorAvatarUrl(author) is a function that is called for each commit which can be used to generate a URL reference to the author avatar/profile picture. The author parameter has the same JSON schema as the author object of a commit in the commits property of the opts.dataCallback() function. If this option is not specified, the default behavior is to use the MD5 hash of the author email address and retrieve the picture from Gravatar.

opts.hiddenBranches is an array of strings (full refs) that indicates which branches should NOT be shown in the diagram initially.

GitFlowVisualize.branches

The branches property of GitFlowVisualize exposes a few functions that allow the host to show/hide branches and provide a nicer UI for this.

branches.getAll() returns a list of all branches in the chart, both visible and invisible. Each item comes with a few useful properties on it. An example:

{
	id: 'refs/heads/feature/large-font', /*full git ref*/
	name: 'feature/large-font',
	lastActivity: 42274874226 /*milliseconds since UNIX epoch. Can be passed to javascript Date() constructor*/,
	lastActivityFormatted: '3/22/2017 13:04:12',
	visible: true
}

branches.setHidden(refs) allows you to pass an array of refs (like what you can set on opts.hiddenBranches).

branches.getHidden() returns an array of refs of branches that are currently hidden.

branches.registerHandler(handler) allows you to pass an event handler. This handler will be called when users click the "Change..." item on the branches summary. To unregister, pass in null.

Legal stuff

GitFlowVisualize was created as part of the Git Flow Chart add-on for Atlassian Bitbucket. As such, this code has a mixed Commercial and Open Source license. It is released to GitHub to share and to accept contributions. The GitHub Terms of Service apply, so feel free to study the code, make forks and contribute. The project can also be used in Open Source projects that are made public using the GPLv3 license or for personal non-commercial use. Commercial exploitation of the code is explicitely prohibited.

License

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/

Copyright 2014-2017 Teun Duynstee

git-flow-vis's People

Contributors

remie avatar teun avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

git-flow-vis's Issues

Support for forks

It would be useful to show branches that live in other, related repo's as well

Implement licensing API

Add-on guidelines for publishing to marketplace (#1):

  • Uses the UPM API/UI for license management
  • Use a non-milestone release of the plugin-license-storage-library
  • Your add-on stops working if the licenseManager component reports an license error

Bugfix branches

As of recently, Atlassian proposes a modified branching model from git-flow. Main difference is that they envision bugfix branches, which are like feature branches, but from a release branch in stead of develop. As this doesn't seem to be completely stable (or incontroversial), I'd propose that we treat bugfix branches as release branches. This issue involves only the addition of a new prefix (bugfix) and have it do the same as release and hotfix.

Selected commit and progressive loading conflict

When you select a commit and highlight its ancestry and then scroll down causing a reload, all of the dimming and hightlighting gets screwed up. We should at least just disable the highlighting when loading new data, but preferably reapply the highlighting.

Make stash add-in

Use icon:

Settings for naming conventions

Use available classes and components fro buttons, colors, dialogs, spinner

Code refactoring

The code base is becoming somewhat large and has a mixture of public and private API functions and variables. Maybe it is time for a bit of cleanup:

  1. Start the code base with the public API functions.
  2. Limit the size of public API functions for readability, and move larger chunks of code to private support functions.
  3. Create a 'utils' object which has all the private support functions.
  4. Re-evaluate the support methods...there are now multiple public / private API's with "draw" in their name, some which are part of the "drawing" object and some are directly on the main class.
  5. Have a more clear distinction between global variables and local variables. Perhaps replace some global variables with function parameters.

Incremental redrawing

D3 suggests a pattern where you only have to redraw elements that actually changed. Each element must specify a key. Then you specify operations for enter(), exit() and update().

If many elements remain untouched after a redraw, this can give large perf advantages. Also, you could easily add animations to indicate moving/appearing elements.

Would be interesting to profile which part actually takes most time.

Commit messages would be easy to make incremental (unique key is easy, most remain as they are.

Hard part could be that the x() function potentially changes, because the number of lines can increase.

It would help if the cleanup code would have an algorithm that would most of the time have commits end up on the same line as before. This seems possible enough.

Use placeholder for default settings

Currently the default settings are stored as values in the add-on, overriding the javascript defaults regardless of user interaction. This should be adjusted: the add-on settings should have explicit null values and not override the javascript options unless the user explicitly changed them. To allow the default values to be visible, placeholder attributes should be used.

Real time inserts of new commits

By regularly checking for new commits, we could have a live feel to the page. By requesting the branches feed, you can see in one request if new commits have been added to the repo.

Consistent naming of add-on

Currently the add-on uses the visible names 'Flow Graph', 'Git Flow Graph', 'Git Flow' and 'Stash Git Flow Graph'. In addition it is using 'gfc' (git flow chart), 'gitflow', 'GitFlowGraph', 'git-flow-vis', 'GitFlowVisualize' as prefixes in code. The servlets use 'git-flow-graph' as url prefix.

Maybe we should decide on a more consistent naming convention :)
I would like to propose we switch to "Git Flow", with "gf" as prefix.
@Teun : what is your preference?

Add support for Mercurial (hg)

BitBucket Cloud also supports Mercurial repositories. Although slightly different, the graph could still be useful for analysis. It think the best way to implement this is to make the 'masterRef', 'developRef', 'featurePrefix', 'releasePrefix' and 'hotfixPrefix' options to accept both String and regular expression values. That way, the more volatile branch naming conventions of Mercurial can be supported and molten into the Git Flow scheme of things.

It should be noted that 'master' is called 'default' in Mercurial, so maybe also add an option to set the type of SCM and automatically adjust the labels on the chart, or add additional options to manually override the chart labels (maybe also good for localisation)

`featurePrefix` option does change label color but not zone when applied to release branch

The allParentsOnMaster check forces the Git Flow naming convention on the graph (which can be considered expected behaviour of a Git Flow Chart) and places release branches in the release zone, even if the featurePrefix setting has been manually set to 'refs/heads/release'.

To some extend this invalidates the featurePrefix option, because it does not override the default behaviour. But it becomes even more complicated considering that the commit label actually does change color, from yellow (release zone) to blue (feature zone). When determining the label color, the featurePrefix is taken into consideration and the Git Flow convention is not enforced.

I guess this issue is about trying to make the options behave a bit more consistent, regardless of whether this is strictly Git Flow or a more liberal approach.

LazyLoad method is broken due to use of D3 select

The switch from jQuery to D3 selection broke the lazy loading of extra repository data. The D3 select() method returns a double array. The appropriate notation to get the DOM Element should be d3.select([selector])[0][0].

Do new minor release

I have made a few small improvements to the javascript library. They have been tested in the field using the source include feature.

We should:

  • create a new version of the plugin using the current master branch of the library (actually the current 1.0.8 release branch)
  • this should have a new field in the configuration page named releaseZonePattern with this default value: /^refs/heads/bugfix/ It is a regular expression and should be passed in as such.
  • test and release

@remie can you set this in motion? I have Stash running locally now, so I may be able to help out testing.

Make shortcut key to place raw data on clipboard

When users want to send feedback to us on the graph, it would be cool if they could just enter a shortcut key to place the json of the current graph on their clipboard. Then they could send us a screenshot, a description of what they think is wrong and the json. We can use their json in a unit test to make sure that we improve that drawing algorithm.

Epic branches

Sometimes, a team works on a big feature for a long time. Several feature branches will be branched off from this branch. They belong together and should be drawn together.

Several options:

  • mark a branch as an epic branch. We will make all branches that are branched off the epic as a group.

  • we could also try to recognize these branches automatically. Needs research.

Add-on support request: more flexible branch configurations

@Teun, what do you think about the following support request?

My team utilizes a slightly modified Gitflow where we have versioned Develop branches that correspond to a release branch.

For example:
Master
--> Release/1.1
----> Develop/1.1
------> Feature/JIRA-123-This-is-new

Improve progress indicator

The current implementation of the AJS.progressBar is not visible enough and buggy. This should be improved.

Preparing for stash rebranding

Stash will be rebranded soon. This means that the name "stash" should be replaced in the documentation, code, add-on and basically anywhere else. Easiest way is to keep the 1.x.y line of the add-on compatible with stash and release a major 2.x.y version with the rebranding.

Merged features

It would be usefull to give special treatment to merged branches, meaning branches that are part of master or develop already. This is not only relevant for existing branches, but also for columns that are recognized, but have no branch label on them (anymore). In git flow, this is very common.

It could be interesting to show only unmerged branches in the feature-branch style. Merged columns could be added to the group of develop columns, which are drawn close together.

Create Automated Integration Tests

The next version of the add-on should include some automated integration tests (cucumber?) to verify the add-on to stay up-to-date with the latest version of stash

Add support for GitHub Flow

Repositories that are using the GitHub flow now end up with a lot of release branches, because the JS library detects that there parents originate from Master. Based on the Git Flow convention, these branches are considered to be hotfix/release branches.

We might be able to support the GitHub flow by also applying the 'featurePrefix' test even if all parents originate from master.

In addition, it would be good if the branch hints support both String and regular expressions as input. This would allow for a more diverse selection of naming conventions.

Lines to release and hotfix branches should have release colors

The line from a release branch to develop is currently green and should be yellow. Everything that goes to or from release branches should be yellow. Even a line coming from a feature (which should of course be impossible), should stand out by using release-yellow.

Example in the test set under "feature branch interpreted as release branch"

Hide and show branches

When a repo has many active branches, it would be nice to be able to hide a number of them. Needs some UI. Store in localStorage which branches should NOT be visible.

Limitation: all branches that are already merged back to develop will necessarily be visible (as they are part of develop). This could still cause a large number of columns to be needed. We could try and combine all merged-back branches into one column of group.

UI refactoring

There are a couple of improvements that can be done regarding the UI:

  1. Switch to a container-based solution for left & right panels (with gutter)
  2. Change commit message divs to a single commit message table in right panel
  3. Cleanup UI in terms of overview: move branch labels to float:right position in the message column, use ellipsis to cut of text overflow in message column, rearrange table columns
  4. Remove table & graph backdrop highlighting on commit message hover and replace it with a more subtle highlight of the single commit in the graph (for instance by filling the commit circle with a color and opaqueness of other commits).
  5. Minor styling improvements (are more subtle gutter line, a more subtle message table, etc)

In addition, an API for the UI/UX can be introduced which allows:

  1. An "embedded: true|false" option which will disable all of the default UI/UX when set to true (except for the gutter)
  2. Override of the table row rendering of messages (to allow custom HTML markup)
  3. The ability to add custom css classes to important elements, such as the commit table, the graph, etc.

In addition, we should consider if we want to keep the AUI styling in the default CSS. If so, it might be better to simply include the AUI packages from NPM instead of copying the CSS styling. That will allow us to keep up to date with AUI styling.

git flow graph on external place (like own homepage)

hi teun,
i saw your excelent implementation of git flow from stash. i tried it directly as an stash plugin and i worker perfectly. now i would like, to show our users some commit and branch information on our homepage, so i would like to show your git flow graph ๐Ÿ˜ƒ the stash api is accessable from "outside" so it shouldnt be technically a problem. is there any way, can you give me a hint ? thanks & regards, marc!

Discuss: should we implement Git Flow operations in add-on

Besides from having a git flow chart, it might also be useful to have the same Git Flow operations as available in Sourcetree within Stash (New Feature, New Release, New Hotfix, Finish current, etc).

Questions to discuss:

  • Should we leave this to someone else to implement?
  • Should we extend the add-on to include these features?
  • Is this out of scope, should it be a separate add-on?

Strange branch placing example

In the attached case, the branch 15949-repopulate end up in the release zone. That can't be right. Settings used:
node serve --remotes -u *** -p *** --repo *** --releasePrefix refs/heads/candidate

sample.zip

Expand develop column into multiple

The basic idea behind the visualisation is that we want to consistently draw the master and develop branches as one line, as you would see them in the charts detailing git flow. However, it turns out that this is quite possible to do for master, but way harder for develop. When multiple developers work on the repository, they will cause non-linear relations between commits that are all on develop.
We should allow for multiple columns to show develop. Maybe one core column and n extra columns (in green) to allow for the out-of-band commits.

Combine group into one big column

Larger groups of commits on a feature branch(es) could be combined into one bold line, placing all its commits on one line, creating less clutter. If you want to see exactly how the branching and merging within that line happened, you can click the group column and expand int into separate lines.

This could be implemented by just changing the x() functions range part. By drawing all of the columns of the group on one x coordinate, it will form a line. Maybe also draw these group columns as thicker lines, as we do for master and develop.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.