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?
Related
I'm not sure if it's an appropriate question here, and I haven't found another related question.
I'm new to programming, and I save my work every day, updating my repository with GItHub Desktop.
Is OK to do that? Is this good practice?
Is there a better way to keep saving my work on a daily basis?
it’s perfectly fine to push your project to origin and that is one of the reasons for git as it keeps your work safe. Further, having frequent commits during stages allows you revert back to those commits when you make a mistake or something goes wrong.
Although when it comes to best practice you should create different branches in your GitHub project and merge those branches into the main branch once it is in a complete state so your main branch is always a functioning product. Here’s some further reading on this:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches
You may also want to explore more of the GitHub docs.
Git can become quiet complex especially when working with other people so it’s useful to get in the habit with following branching structures and writing useful commit messages. Also you’ll often find different organisations have specific rules to this and you’ll have to understand git enough to work with in the way your team does.
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!
The company I work for uses TFS for its version control and has quite a strong opinion on data security.
With that in mind I'm unable to use source control services such as git due the capability being there to push your work to an external source.
My question is are there any git-like ways to manage your code which are PURELY LOCAL and do not offer the ability to push your changes to the internet? TFS does not seem to offer much in the way of local commits.
I've been told there's the shelving function however as a junior dev I would rather make any accessible code be in good standard before others can see it.
Thanks
I'm unable to use source control services such as git due the capability being there to push your work to an external source
That sounds like a rather odd reason. Even if you use a source control tool that does not support publishing the stuff, there is nothing that prevents you from simply uploading the contents manually somewhere. Sure, it requires manual work, but even that you could automate without introducing a version control system that does it.
The way you explain this also sounds as if you do have some kind of control of the tool you may end up using for this, so the company needs to trust you anyway to not publish the stuff.
And at that point, there is no reason not to use Git here: After all, it works completely offline, and you do not have to set up a remote which you could push to.
Taking things even further, if your company works with TFS, then you could utilize git-tfs which is a bridge between Git and TFS. With it, you can actually connect to your TFS, use Git locally, and then publish your changes (after you polished them) to the TFS. So it would all be a single integrated workflow, without you having to juggle between two different incompatible systems: You just commit using Git, and once you have a set of commits ready for checking them into the TFS, you can e.g. do git tfs checkin and make a single check-in for it.
I've been told there's the shelving function
The TFS shelvesets are also not offline; they are public in the same way the normal checkins are, it’s just that they live on the side without affecting the normal TFS repository. And they are quite cumbersome to work with too (since they don’t give you a history).
I am working on establishing a workflow at my company if we were to migrate to DVCS (most likely Mercurial). One of the things I would like to do is to have a repository for QA. The idea being that each developer works on a branch and when they are done the branch is pushed to QA. From there the test team can do their testing and report back any bugs. Once the branch is fully tested and acceptable it will be pushed to a staging repository where the merge back to the mainline will happen before pushing to the central repository.
This can work quite easily if everyone just communicates the status of their work in some way, but I know this doesn't always happen as you would want it to. What I am worried about is branches in the QA repo waiting around but nobody knows if it is waiting to be tested, currently being tested, waiting for fixes, waiting to be pushed to the staging area etc. So what I am looking for are ideas of how a status can be added to a branch? What would also be good would be to do it in a way that we could use hooks to also notify people of changes in the status.
Any ideas would be appreciated.
Unfortunately I think you need a different system to keep track of this part of your workflow.
A repository consists of things that aren't supposed to change all willy nilly, yet the current Q&A status will by necessity change orthogonal to the contents of the repository.
Let me rephrase that. You have 10 changesets in the Q&A repository, ready to be tested. Exactly what each tester focuses on, the status of each test, etc. will change, even though those 10 changesets stay the same.
I would definitely try to use a bugtracking system where you can integrate the repository history in some way, even if it is just by linking an issue in the system to its changeset.
I notice your comment about not getting support for buying Kiln, but there are other systems you should be able to integrate that would give you something similar.
I would very much resist trying to press Mercurial into service of something it wasn't built to support, trying to use tags for this would fail miserably, and bookmarks would give you problems, as you've already noted.
So again, try to find a separate system for keeping track of Q&A status.
One simple method might be to keep a metadata file in your repo's root folder, named .teststatus or somesuch, that looks like:
# branch-name, last passed revision
default, 0123456789ab
stable, 0123456789ac
bobs-dev-branch, 0123456789ad
marys-dev-branch, none
Using tags or bookmarks would feel like a sort of abuse, here. You couldn't use the same tag across branches (e.g. passed would have to be stable-passed), and tags are generally not moving. Bookmarks, on the other hand, are intended to move, but you still have the branch-namespacing issues.
Joel Spolsky, one of the founders of this site, produces a program called FogBugz that is integrated with Mercurial and makes it easy to keep track of everyone's status.
I'm not completely sure how your workflow works, but here are a few ideas:
Tags.
Use named branches and close the branch when tested.Typing hg branches will show you which branches are still pending.
You could probably use an incoming hook for the automatic notification of new changesets being added to the QA repo.
Why would a developer push something to a QA repository if it wasn't ready to be QA'd? I think the act of pushing changesets to a QA designated repository should be the signal that the feature is ready to be tested.
Feature branches by cloning is my favorite approach.
I recently joined a project team that is using TFS (I have happily avoided TFS until now). I am trying to determine if there is a way to require a story/defect reference to be associated with every commit comment?
With Tortoise/SVN it was easy to add a requirement for a reference number to be required with each commit. Personally, I like to track every commit back to a user story or defect, so I am hoping there is a way make this mandatory in TFS as well? I searched SO and Google, and haven't found the magic "key words", so if someone can point me in the right direction, it would be greatly appreciated.
Note: Stories and Issues are stored in other tools and not tied to TFS in any way.
Can it be done? Yes. Is it easy? Fairly easy. However, two caveats. Caveat number one: you're going to have to write code. Codeplex has some good examples here. Additional searches on codeplex and on the almighty Google will locate you more examples.
The big caveat here is that check-in policies are client-side. Once you develop the policy, it will need to be deployed to all developer workstations. If the policy isn't installed? It is ignored. While I'm a big fanboy of TFS, this is one oversight that I can't believe is still in place after three major version releases.
You could create a server-side check-in monitor that examines the check-in and determines if the story has been associated. However, it will not prevent the check-in, but you can use it to alert someone to resolve it after the fact.
Switch to a DVCS system like Git (see this article on pre-commit hooks) or Mercurial (see this other article on pre-commit hooks) which DO have server-side hooks that can be overridden to do validation checks. :-)
Yeah, I know, not really the answer you were looking for but it is an alternative solution to the problem that some other SO users might find useful.
With the DVCS type of system, you can have a separation between hooks that run on the local computer and hooks that run on the server when your commit is pushed back to the shared repository. That kind of concept does not have a corollary in TFS. It can make some things easier for your developers. For example, every changeset that was committed to our shared repository had to have a ticket number attached in the commit message. Local pre-commit hooks guarded against changesets getting created (in Mercurial) that did not have proper commit messages.
With TFS's support for GIT in an upcoming release maybe things will be easier in this regard.