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.
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!
Context
I often found valuable projects with many forks. Sometimes I would like to add something to the original functionality, so I go for forking. However to prevent reinventing the wheel, I would like to ensure no one done such kind of work before. So I review the existing forks, but usually those just a stalling copies. In case of 100 forks this is a tedious work.
Question
Given a github repo, how to see if one or more of its fork has measurable activity? I would like to do this to filter out the "just another copy" like forks.
GitHub has a network graph as one of their features for Understanding connections between repositories. This provides a:
Timeline of the most recent commits to this repository and its network ordered by most recently pushed to.
This would show the most recently active forks just below the main repository. You can access it at https://github.com/<user>/<repo>/network, e.g. here's one from one of my repos.
I don't think Github itself provides an easy way to do this, but some third-party tools have been written to help with that.
gitpop3 for example supports sorting the forks of a given repository by either number of stars, forks, commits or the last modified date.
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
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?