What is the best practice (and why) on closing tickets/issues in the versioning/ticketing system during software development?
Our workflow is based on creating FEATURE or PATCH branches to implement changes and then merge into a controlled master that is (mostly) guaranteed to build and be ready for deployment.
Our ticket system holds bug reports or feature requests we subsequently fix/implement in said branches, then merge into master before the next release.
Which solution is better:
A. Close the ticket once the solution is implemented (and verified) in the FEATURE/PATCH branch. This cleans out the list of open tickets fast and gives a good overview off how much work is left for the next release.
B. Keep it open until the branch has been merged to master and verified there.
Only master represents the final product, so technically only now the work is done. And no bug might stay un-fixed because someone forgot the merge.
My experience is that a support ticket with a feature request is closed after the request is logged with the Product Manager, they acknowledge with a time-frame and the customer has been suitably advised.
For a patch, both are valid approaches, but depending on when the fix is liable to be applied. If it's liable to be a fix-pack release within two weeks: keep the ticket open until the patch is deployed to that customer. Use the ticket as the root for the change management system. Otherwise, if the fix will not be deployed until some future routine release, then my advice is to let the customer know accordingly, and close the ticket.
Related
What criteria does Github use to determine whether or not a given PR "has too many changes" for rebase-merging?
I've worked on a refactoring effort recently and after submitting and getting approval in the PR, I got the following message from Github's UI, preventing me from rebase-merging the change:
This branch cannot be rebased due to too many changes
At the time, I had no idea what exactly the limit was, so I split my ~30-commit PR into 2 ~15-commit changes, which made the restriction go away.
I found a question around the same limitation, but it doesn't focus on what these limits are, asking for workarounds instead:
This branch cannot be rebased due to too many changes
I'm now doing another change which also has a similar number of commits and wanted to know exactly what rules Github uses to determine whether or not a given PR "has too many changes" so that I can split my PRs accordingly upfront and avoid rework both on my end as well as on reviewer's.
I tried finding official documentation on this to no avail. Unfortunately, the only way I'm aware of to test it is to submit the PR and check if the message comes up. This however becomes unfeasible since the message only shows after all checks have succeeded, meaning I have to also get actual reviews on the change to check whether they are mergeable or not. If I then find out it is not mergeable, I have to create a separate PR and split the change, wasting everybody's time on re-reviews.
Many different aspects (or a combination of multiple aspects) could be the cause for this:
Number of commits
Number of affected files
Number of affected lines
Number of conflicts with base branch
etc
I've been using GH for a long time and had never seen this message until a couple weeks ago, so I assume it is either some new feature, or maybe a restriction depending on the type of plan used by my company.
This is almost certainly a timeout-based situation. GitHub uses libgit2 to perform rebases and how long a rebase takes depends on the number of commits, the complexity of the changes in each of those commits, and the complexity related to the repository (size of objects that must be looked up, etc.). libgit2 doesn't have all the optimizations of regular Git, but regular Git cannot rebase in a bare repository, so the use of libgit2 is required.
So there's no fixed limit in the number of commits or the complexity, only that if it takes longer than whatever the timeout is, the operation will fail, and you'll be left with that message. One way to avoid this is to use regular merge commits, which while not immune from timing out, are less likely to do so because the merge involves only three commits, not however many are in your branch.
I know github generally has a rule where PR's and stuff can be closed, but never deleted to preserve history, unless there is something very necessary about it (such as private keys being included in the PR by accident, etc.). I was wondering, however, if draft PR's can be deleted. Sometimes I use it for certain CI/CD testing, and I end up closing them, but they can start cluttering up my PR history. Since they were never converted to a full, real PR, is that a thing we can do without contacting github support?
Thanks!
Apparently no. Draft PRs are treated like regular PRs and cannot be deleted without contacting support. https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository. They only delete them if there is sensitive data.
You might want to setup a separate repo just for CI/CD testing if you are trying to test configurations like Actions. That would keep your main repo from getting cluttered.
If you are creating draft PRs to run tests, that could indicate your tests are difficult (or slow) to run locally. I'm just assuming though. I know that's why I sometimes reply on CI/CD instead of local testing.
This question already has answers here:
Is there a way to make Github un-approve a pull request if a new commit is pushed to the branch?
(2 answers)
Closed 1 year ago.
We have have programmers on our team that make changes after the Code Reviewers approved.
Is there a way in Github, everytime a new file/edit is committed, Github would Automatically reset and ask Code Reviewers to reapprove?
Currently programmers are adding new changes without approval, and this may affect the QA and Production system later.
GitHub has an option for this in the branch protection settings, which is “Dismiss stale pull request approvals when new commits are pushed.” That controls whether the approvals are removed, and while it doesn't specifically re-request approvals from the reviewers, they will receive the normal notifications that changes have been pushed, and they can choose to re-review when it's convenient. Of course, the submitter can always click on the button to explicitly request a re-review.
Note that, as mentioned in the comments, there are various reasons to allow this practice, since sometimes there are minor improvements that could be made, but the status quo would be acceptable nevertheless. However, in some environments, this cannot be allowed for compliance or policy reasons, so this option exists for those cases.
Research I've done before raising this question:
[github] single user pr - no relevant results
[github] single user pull request - no relevant results
[github] approve own pull request
github protected branch require pull request (Unanswered)
A potentially relevant question, but around a multiple user environment, so there were workarounds. I don't have a workaround.
'[github] approve own pr` - no relevant results.
Quite a few Google searches
So my problem is simple: I have a personal GitHub repository that I am using to manage my website code. I would like to prevent accidental check-ins to the master branch because I do not want the CI/CD pipeline that I'm building to trigger unless a feature is complete; I'm planning to use issue-linked feature branches to handle updates.
My problem is that I cannot seem to set this up without having someone else to approve the pull requests, which I don't have. So the question is: How, other than creating a secondary git account to handle PR's, can I protect a branch to prevent accidental check-ins from happening, without having someone else on my team to approve those pull requests?
I know that I can do this in Azure Repositories, however, I quite like the GitHub environment so I'd rather do this in GitHub.
I managed to work around this. At the time I made this request, I didn't have automated tests set up (Something I believe all projects should have for completeness). When I set up validation requirements to merge into Master, I could not directly check-in to Master because those checks had not been run.
I could still approve the PR myself, so that was allowable, however, I also had to ensure that all pipeline checks had completed before that PR could complete.
It's not a complete answer because if you are not running a CI/CD pipeline with test running you will not be able to take advantage - but it's easy enough to set something dummy up that will always pass to enable this solution. Until GitHub.com provides a self-approval allowance, it seems to be the best answer.
I'm always happy to hear alternatives though!
In a DVCS, each developer has an entire repository on their workstation, to which they can commit all their changes. Then they can merge their repo with someone else's, or clone it, or whatever (as I understand it, I'm not a DVCS user).
To me that flags a side-effect, of being more vulnerable to forgetting to backup. In a traditional centralised system, both you as a developer and the people in charge know that if you commit something, it's held on a central server which can have decent backup solutions in place.
But using a DVCS, it seems you only have to push your work to a server when you feel like sharing it. It's all very well you have the repo locally so you can work on your feature branch for a month without bothering anyone, but it means (I think) that checking in your code to the repo is not enough, you have to remember to do regular pushes to a backed-up server.
It also means, doesn't it, that a team lead can't see all those nice SVN commit emails to keep a rough idea what's going on in the code-base?
Is any of this a real issue?
I can understand your concern about devs forgetting backups once their local diff is gone (because they've committed locally) and stops nagging them with copious output. I think the solution can lie in better tools, moar tools! You could set up a cron job on each dev's box that pushes every last reachable object in their repository to the central repo, and labels them in the central (backed-up) repo with namespaced branches. I think "git push" can do this, given the correct refspec. Then, all you aren't doing is affecting the state of your public branches.
But do you really need as aggressive a backup process as before, when the repo existed only in one place? With a DVCS, you need a far higher category of catastrophes to lose all your code. You now need an asteroid or a bomb hitting your office (and all your off-site team members), instead of just a hard disk or RAID controller going bad. Note, I'm not advocating sloppiness; I'm advocating equal risk at lower cost.
I don't think you have an automatism on this. Distributed or centralized VCS can be combined with backup (or not). It's all a question of discipline in the team.
Same for commit-emails. If the team has the discipline to regularly push changes to the right repositories, you can have a working commit-mailinglist too.
Bad habits also can grow in a team with centralized VCS. You have always to fight bad habits.
In most places I imagine that there is probably still a 'central' repository from where builds are made and put to test. If you want your code in the build, it's got to be pushed centrally.
This is also a management issue - tell your team - push regularly (at least daily) so that your code is backed up. If it's not being done, then get out the big stick.
I'd also note, that if you're relying on looking at the commits to see what your staff are doing, you probably have some larger issues that you might look at addressing...
Having a local copy of the repository might encourage poor backup habits, if one were slack. However, your master repository SHOULD be backed up.
The "local copy of the entire repository" has a much more important use than being a backup. It reduces the latency of examining the history of the codebase - say, diffing against the latest version - from being a network round trip to a trip to your local hard drive.
That doesn't sound all that big a deal if your main repository's on your gigabit LAN. If you're a telecommuter, and the repository's a good 600+ ms away over a VPN, it makes a world of difference.
I've never looked into it, but I'm sure both Mercurial and Git support post-commit hooks, allowing you to set up commit mails going to the team lead. Then each developer could set up her repository accordingly, or have an interim repository that permits half-baked features with the commit mails, or whatever.
Edit: Regarding John's comment about a long-running experiment being lost because it wasn't ready to commit to the master repo: work in a separate branch and regularly push your changes to the master. You still get all the benefits of working against a local repository (mainly, for me, very low latency), and still not annoy your colleagues with your half-baked feature... and you can still store your changes off your machine, in a place where your admin can properly back up the repository.