teun / git-flow-vis Goto Github PK

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.

Use icon:

Settings for naming conventions

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

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.

@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

The add-on should include version 1.0.2 of the javascript libraries (which includes the fix for #25)

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)

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.

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.

Look into HTML5 Web Workers
This will mean a major refactor, because all of the work for the Worker must be in a separate js resource.
Also look into polyfill

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

At start time, we load a limited set of commits for all branches. If we scroll down, we will at some point see loose ends. At that time, we should incrementally load extra commits. And redraw.

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.

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.

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.

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"

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

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].

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.

Add-on guidelines for publishing to marketplace (#1):
Provide branding and marketing assets like a logo, banner, and screenshots as defined by our branding guidelines. Reference these assets in the plugin descriptor.

https://developer.atlassian.com/display/MARKET/Branding+your+add-on
https://developer.atlassian.com/x/TACU

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.

display gitflow hotfix and support branches

Update to the latest version of the javascript libraries

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.

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.

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.

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

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

The add-on should be build automatically upon commit

Allow users to opt-in on the latest and greatest version of the JS library

One of the requirements for publishing to the Atlassian Marketplace (#1) is to have a nice internet page with documentation on how to install & use the add-on. I would suggest publishing this to https://collabsoft.atlassian.net/wiki/

Version 1.0.0 of the js library has been released, this should be included in the add-on

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.

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.

Any chance of releasing the source for http://beta.gitflowchart.com/chart ?

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.

Our Stash instance has following url:
www.example.com/stash
When we are clicking on commit links in GitFlowChart it is redirecting us to
www.example.com/projects/PROJECT/repos/REPO_NAME/commits/da398a9ef4f79e2892ab5854b658a368e5f610b6
instead of
www.example.com/stash/projects/PROJECT/repos/REPO_NAME/commits/da398a9ef4f79e2892ab5854b658a368e5f610b6

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

The pricing scheme needs to be decided before the add-on can be published on the marketplace.
The add-on can be compared to https://marketplace.atlassian.com/plugins/com.stiltsoft.stash.graphs

The release tag regex should be configurable.

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.

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?

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.

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?

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!