We use bitbucket a lot, especially using the pull requests mechanism to review and approve changes.
I find it very hard for me to review pull requests using the web-based interface of bitbucket, and would like to be able to review them in something a bit more "smart", which allows me to jump to files quickly and navigate from usage to declaration of variables fast.
I could not find a tool which can do such a thing.
Did anyone hear \ made a tool that can do such thing?
You can try this addon. It allows you easily manage pull requests. All PRs will be in a board where you can drag them into proper status (in preparation, ready for review, reviewing etc).
https://marketplace.atlassian.com/1221505
Related
I have a GitHub repo that has multiple contributors making changes at the same time. I'm having conflicts with merging pull requests because by the time someone wants to submit changes they've made to be reviewed, someone else who had been working on a portion of the code in the same file will end up having an outdated repository on their local device. Whenever they plan to make their pull request with the changes, the repository had already been changed.
What is the proper way to submit changes through the command line before making a pull request to ensure you have the updated repository and the changes on your local device arent removed by re-pulling?
How should I properly be instructing my team to make changes to my repository while avoiding conflicts of files being updated?
What steps should I be taking when reviewing pull requests to make sure I am merging properly?
This is a very common scenario with version control tools like GitHub. There is NO solution to avoid merges completely, being in the same repository but there are a few ways that can help you reduce merges:
If possible, restructure your repo and make it modular for different teams.
See if you can use the concept of a common library and rearrange contents in various smaller repositories.
THE BEST way is to ask all contributors to make small and very frequent changes. This will increase no. of pull requests but it will make review quick for reviewers. And you also need to ensure there is no pipeline being formed for pull request review.
Thanks!
We have several Repositories in Azure DevOps, some in the same project others in different projects.
I'm trying to find out how pull requests could be linked in some fashion.
I know we could actually put urls in the description, for different pull requests, which I'm guess might be our only option.
However, it would useful to be able to see some status across pull requests in different repositories.
I'm picturing a project which has meant changes in different repos, at the end of the project, we'd want to merge all these pull requests at the same time. So having some means of making it obvious across all pull requests, which pull requests are also required. Obviously I'm not expecting one merge / complete all button.
But there would need to be some obvious link.
Maybe there's an extension which might help, or something obvious I've missed.
It is possible integrate github with a custom application that track issues? This custom issue tracker is developed by people that is not involved with github development, but can code some plugin or feature that provides a pattern to refer a external issue.
The pattern can be #I or something like this.
Thoughts?
As far as I'm aware, most popular enterprise solutions are building integrations with GitHub repositories via webhooks (if they don't already offer them). If this is a in-house custom solution you will have to build that integration yourself.
You'll need to register a webhook for each repository and you will have to know how to associate events from different repositories with different issues.
With the webhook set-up you'll be able to inspect pull requests, pushes to different branches, etc. and you can use whatever syntax you want to refer to issue ids in your issue tracker. If your repository is also public facing and has issues (and pull requests) turned on, you will definitely not want to overlap usage of #numerical_id with your own issue tracker. In that case, you will want to choose something like ^ or & or % which isn't currently claimed by anyone else. What you choose for that, though, is entirely up to you.
We’d like to allow contributors to use GitHub pull requests on our git mirror on GitHub to submit code. But we are using trac otherwise for issue management, which means that the #nnnn namespace is already taken.
I am worried that by default, GitHub would start linking random commits to unrelated pull requests, just because these happen to mention a trac ticket that happens to have the same number.
Is there a way to prevent GitHub from interpreting these numbers in a repository?
The GitHub support team writes:
Disabling that linking is not possible currently, and I'm not sure if
that feature will be available in the near future. Still, I'll add
your request to our feature request wishlist and pass the feedback to
the team.
Thanks for the question/suggestion and let us know if there's anything
else.
Currently we are using SVN.
I would like to start using GitHub, but one absolute requirement is that we will need to have precommit (premerge) validation of the code like we currently have. Does GitHub support precommithooks (premergehooks)?
We're a team of 5 developers. We made an agreement that all code (JavaScript) should pass JSLint-like validation. Voluntary validation has proven not to work because it's easily forgotten. How can we be sure that code that becomes available to the others is guaranteed to validate against JSLint (or similar)?
The concept I was looking for was the prereceive hook
I don't believe github supports pre-commit hooks. However, the git core does. You could set up the pre-commit hooks locally, or apply them as a test before merging branches into your main github.
I think you're missing something fundamental about git. It's not a centralized model (well ok, it can be, but if you're going to use it this way then github is probably the wrong approach). If you're using github, the right way to do this is:
Host your main repo
Have your developers each create their own fork
Let them happily hack away, committing and pushing to their heart's content
When they think a feature is ready, they send a pull request to you (the maintainer) which you yourself verify on the side to ensure stability. Then you merge / rebase their changes into the main repo.
Naturally there are many ways to skin a cat. But when you're talking about "real git" (the kind employed by the open source community), the centralized "check-it-in-and-it-damned-well-better-work" model is kind of difficult, especially when it comes to larger projects.
I think this article describes a very good workflow that could be a basis for automation:
http://scottchacon.com/2011/08/31/github-flow.html
The main idea is that you use pull requests as mentioned above, but you can also have a service that can use the github api to fetch or pull the branch making the request, merge, test, validate then push to the target branch.
No, GitHub doesn't support pre-commit hooks. How would that even work? Committing happens on your computer, do you really want to allow GitHub to run arbitrary code on your machine?