• Icon: Suggestion Suggestion
    • Resolution: Low Engagement
    • None
    • None
    • 1
    • 3
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      My team uses feature branches pushed to github to do code reviews. Sometimes the code review is denied and the developer has to resubmit work on a new branch. It seem that Jira smart commits watch all branches instead of just master, so that the #resolve smart commit tag is applied as soon as the code review branch is created, rather than when it's merged into the main corpus of code. This of course then shows an incorrect status on the Jira issue, since it's not actually resolved, just "pending" until the code is verified to actually work.

      Is there any way to tell Jira to sync only one or two specific branches?

            [JSWSERVER-13992] Seeking the ability sync only one or two specific branches

            Atlassian Update - 17 April 2025

            Hello,

            Thank you for submitting this suggestion. We appreciate you taking the time to share your ideas for improving our products, as many features and functions come from valued customers such as yourself.

            Atlassian is committed to enhancing the security and compliance of our Data Center products, with an emphasis on sustainable scalability and improving the product experience for both administrators and end-users. We periodically review older suggestions to ensure we're focusing on the most relevant feedback. This suggestion is being closed due to a lack of engagement in the last four years, including no new watchers, votes, or comments. This inactivity suggests a low impact. Therefore, this suggestion is not in consideration for our future roadmap.

            Please note the comments on this thread are not being monitored.

            You can read more about our approach to highly voted suggestions here and how we prioritize what to implement here.

            To learn more about our recent investments in Jira Data Center, please check our public roadmap and our dashboards, which contain recently resolved issues, current work, and future plans.

            Kind regards,
            Jira Data Center

            Aakrity Tibrewal added a comment - Atlassian Update - 17 April 2025 Hello, Thank you for submitting this suggestion. We appreciate you taking the time to share your ideas for improving our products, as many features and functions come from valued customers such as yourself. Atlassian is committed to enhancing the security and compliance of our Data Center products, with an emphasis on sustainable scalability and improving the product experience for both administrators and end-users. We periodically review older suggestions to ensure we're focusing on the most relevant feedback. This suggestion is being closed due to a lack of engagement in the last four years , including no new watchers, votes, or comments. This inactivity suggests a low impact. Therefore, this suggestion is not in consideration for our future roadmap. Please note the comments on this thread are not being monitored. You can read more about our approach to highly voted suggestions here and how we prioritize what to implement here. To learn more about our recent investments in Jira Data Center, please check our public roadmap and our dashboards, which contain recently resolved issues , current work, and future plans. Kind regards, Jira Data Center

            I'm amazed that so many companies pay for Jira when this isn't implemented. We are completely unable to use feature or testing branches because of this oversight. All the alternatives I've seen suggested online so far just mean more work for our developers.

            Daniel Martí added a comment - I'm amazed that so many companies pay for Jira when this isn't implemented. We are completely unable to use feature or testing branches because of this oversight. All the alternatives I've seen suggested online so far just mean more work for our developers.

            Upvoted!

            I would love to have this feature.

            Paulo Barros added a comment - Upvoted! I would love to have this feature.

            Hope to have this too.

            Xinyan Zhao added a comment - Hope to have this too.

            Would love to have this to make Smart Commits work with our workflow.

            Chad Stewart added a comment - Would love to have this to make Smart Commits work with our workflow.

            This request seems 3 years old and I agree feels like a major oversight

            Sanjay Sharma added a comment - This request seems 3 years old and I agree feels like a major oversight

            Upvoted.  This is a big oversight imho.  The JIRA DVCS connector seems to have knowledge of PR state and branches because it displays them in the sidebar of the linked JIRA issues, so it seems like the context to solve this already exists. Why can't Smart Commits leverage that context to make decisions on transitions?   

            We're trying to standardize on JIRA as our issue tracker, and Smart Commits was the peace treaty for Github Issues users...but if it doesn't work as we need it to, then it's a hard sell for getting teams off Github Issues and into JIRA.  Github issues is free and if it continues to improve and has votes from developers, it gets harder to convince teams to spend the money on JIRA.  Please fix!! 

            Dale Cieslak added a comment - Upvoted.  This is a big oversight imho.  The JIRA DVCS connector seems to have knowledge of PR state and branches because it displays them in the sidebar of the linked JIRA issues, so it seems like the context to solve this already exists. Why can't Smart Commits leverage that context to make decisions on transitions?    We're trying to standardize on JIRA as our issue tracker, and Smart Commits was the peace treaty for Github Issues users...but if it doesn't work as we need it to, then it's a hard sell for getting teams off Github Issues and into JIRA.  Github issues is free and if it continues to improve and has votes from developers, it gets harder to convince teams to spend the money on JIRA.  Please fix!! 

            We use BitBucket to do a simple code review process, namely:

            1. Fork master to open a feature branch, named after the JIRA issue number.
            2. Commit code to feature branch; using git-hooks we enforce the issue number appears in each commit.
            3. Push code to Bitbucket once all changes complete, open pull request from "feature branch" -> "master".
            4. Once code is reviewed and accepted, feature branch is closed and "master" is deployed to our TEST environment.
            5. UAT is completed.
            6. Once accepted we create a second pull request from "master" -> "live". Once that is reviewed, merged it is deployed to LIVE.

            It's a simple process that allows us to have control whilst still being pretty agile. We're struggling with JIRA workflow transitions in #4 & #6 because of lack of an ability to target a branch with a workflow transition condition.

            We've therefore not been able to use this feature. We don't ever use smart commits, they don't seem to fit into our workflow too well unfortunately.

            alexlatchford added a comment - We use BitBucket to do a simple code review process, namely: Fork master to open a feature branch, named after the JIRA issue number. Commit code to feature branch; using git-hooks we enforce the issue number appears in each commit. Push code to Bitbucket once all changes complete, open pull request from "feature branch" -> "master". Once code is reviewed and accepted, feature branch is closed and "master" is deployed to our TEST environment. UAT is completed. Once accepted we create a second pull request from "master" -> "live". Once that is reviewed, merged it is deployed to LIVE. It's a simple process that allows us to have control whilst still being pretty agile. We're struggling with JIRA workflow transitions in #4 & #6 because of lack of an ability to target a branch with a workflow transition condition. We've therefore not been able to use this feature. We don't ever use smart commits, they don't seem to fit into our workflow too well unfortunately.

            Same issue here – we have a code review process in Phabricator, and when the commit is sent to Phabrictor, a branch is pushed to the remote and Jira picks it up. The problem is that it's pre-merge into master, so the work isn't technically 'done/resolved' from a board perspective until the review is complete and it's merged. We're looking into using different keywords/triggers to move the story across the board, and are also looking to see if the https://secure.phabricator.com/T5422 could help, but having some control over the branch(es) that Jira monitors could be really powerful/helpful!

            Adam Beckerman added a comment - Same issue here – we have a code review process in Phabricator, and when the commit is sent to Phabrictor, a branch is pushed to the remote and Jira picks it up. The problem is that it's pre-merge into master, so the work isn't technically 'done/resolved' from a board perspective until the review is complete and it's merged. We're looking into using different keywords/triggers to move the story across the board, and are also looking to see if the https://secure.phabricator.com/T5422 could help, but having some control over the branch(es) that Jira monitors could be really powerful/helpful!

            Thanks for reporting. Even if the code is accepted, in our system, the branch must also pass post-commit automated tests, and only then does it get merged to master, so the #resolve transition is even more premature, and should only occur on merge to master, which then triggers QA to verify the fix on master.

            L. Antkiewicz added a comment - Thanks for reporting. Even if the code is accepted, in our system, the branch must also pass post-commit automated tests, and only then does it get merged to master, so the #resolve transition is even more premature, and should only occur on merge to master, which then triggers QA to verify the fix on master.

              Unassigned Unassigned
              jworley Jason Worley (Inactive)
              Votes:
              42 Vote for this issue
              Watchers:
              21 Start watching this issue

                Created:
                Updated:
                Resolved: