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.
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!
Is there way i can make commit messages mandatory? I need this validation both from UI and API level so i dont see any commits that have blank description.
Is that possible?
Github Enterprise has this feature available as a pre-receive hook.
Examples of pre-receive hooks from the readme:
Require commit messages to follow a specific pattern or format, such
as including a valid ticket number or being over a certain length.
Prevent sensitive data from being added to the repository by blocking keywords, patterns or filetypes.
Prevent a PR author from merging their own changes.
Prevent a developer from pushing commits of a different author or committer.
Prevent a developer from pushing unsigned commits.
I do not think that is possible. The UI always sets a default commit message if you do not specify one on your own. The extended description section, however, is optional and is probably specific to GitHub.
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.
Im using Jira with Bitbucket, and I wonder - can I somehow store info about that one or more revisions are related to some ticket, without writing ugly prefixes like ABC-123 in commit-messages?
The only other solution is to login to JIRA UI and create an issue link to the commit page in Bitbucket.
Obviously, this is somewhat more work than just adding ABC-123 in the commit.
Short answer: not really
The problem is that most version control systems don't allow you to store extra structured data related to a commit. The least common denominator is the commit message, so it tends to get used for all kinds of logically separate data, e.g. JIRA issue keys, change the status directions etc. The git notes feature might be used for this.
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?