git-flow-vis's People
Forkers
cwebbdesign mdpolky martindale emchateau liyistc bdwakefield nextiams nagyistge khaltner pixeline remie meywethergit-flow-vis's Issues
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.
Make stash add-in
Use icon:
Settings for naming conventions
Use available classes and components fro buttons, colors, dialogs, spinner
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.
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
Update add-on to version 1.0.2
The add-on should include version 1.0.2 of the javascript libraries (which includes the fix for #25)
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)
UI refactoring
There are a couple of improvements that can be done regarding the UI:
- Switch to a container-based solution for left & right panels (with gutter)
- Change commit message divs to a single commit message table in right panel
- 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
- 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).
- 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:
- An "embedded: true|false" option which will disable all of the default UI/UX when set to true (except for the gutter)
- Override of the table row rendering of messages (to allow custom HTML markup)
- 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.
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.
Recalculating should be on different thread
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
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
Load extra commits when an open end scrolls into view
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.
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.
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.
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.
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"
Improve progress indicator
The current implementation of the AJS.progressBar is not visible enough and buggy. This should be improved.
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]
.
`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.
Provide marketing assets
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
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.
Hotfix and Support branches
display gitflow hotfix and support branches
Include version 1.0.1 in the add-on
Update to the latest version of the javascript libraries
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:
- Start the code base with the public API functions.
- Limit the size of public API functions for readability, and move larger chunks of code to private support functions.
- Create a 'utils' object which has all the private support functions.
- 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.
- Have a more clear distinction between global variables and local variables. Perhaps replace some global variables with function parameters.
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.
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.
Support for forks
It would be useful to show branches that live in other, related repo's as well
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
Setup CI for add-on
The add-on should be build automatically upon commit
Cutting-edge experimental labs feature checkbox (with large red warning signs)
Allow users to opt-in on the latest and greatest version of the JS library
Write add-on documentation
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/
Include version 1.0.0 in add-on
Version 1.0.0 of the js library has been released, this should be included in the add-on
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.
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.
Source for http://beta.gitflowchart.com/chart
Any chance of releasing the source for http://beta.gitflowchart.com/chart ?
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.
Commit links don't take into account base url for Stash
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
Publish to marketplace
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
Pricing of add-on
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
settings screen: release tag regex
The release tag regex should be configurable.
Improve style
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.
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?
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.
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?
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!
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.