Hello I'm new to Github/Gist and I want to use this code, but I need to modify it a little bit. Can i just fork this code and modify it to use it for my own projects? Or do i have to link to the author etc.? Here is the link: https://gist.github.com/learncodeacademy/777349747d8382bfb722
Thank you!
Github repositories are meant to be forked. You don't have to ask an author for permission. Anyway, the gist you linked to has already been forked 30 times.
When you are using a forked repository.It shows up as "forked from xyz". So attribution is automatic. But if you want to, you can always give an extra credit to the author by mentioning it specifically.
Forking a repository on Github, creates an individual copy of the code. This feature is meant to encourage collaboration as well as allow you to experiment with the repositories code. Forking can be used to propose new changes to someone else's code or jumpstart an idea or a new project. As the repository was created by someone else, it is always important to understand the limitations of using their code for your own projects (especially if you plan on selling this product). Every repository created on Github has the chance to create a license file. This file will tell you what you can or cannot do with the forked code. Often open source code is meant to be used and shared with everyone, but it is still good to check. Here is Githubs documentation on forking repositories: https://help.github.com/articles/fork-a-repo/. For more information on licensing files see http://choosealicense.com/. Github gists follow the same standard. If you are still worried, it does not hurt to contact the owner of the repository and verify that you can use it for your own projects.
The point of open sourcing code on GitHub is for others to take and use for themselves and learn from it. Also, like fuchsteufelswild said, when forking on GitHub it automatically gives credit to the author so you should be good.
Related
I'm developing a Jupyter Book project with my research team on a GitHub repository (I'm a total noob at this but so are they).
Yesterday I came across a few PRs and realized that they all included a '_build' folder in their forks which gets added to the repo when you test jb build MyBook locally on your clone. I'd like to set up a bot, perhaps with GitHub Actions or ProBot that checks this and either removes the folder from their fork (No harm there) or leaves a comment that the folder should be removed before merging. (The book gets built and deployed by a GitHub-actions workflow)
As far as I can tell, bots of this kind can only check for title, body, and comments but not the contents of the fork itself. Are there tools out there to do this? If not so, please point me in some direction so I can further investigate the matter and perhaps create a workflow of my own.
Thanks in advance!
Beside adding a .gitignore, as commented, to incite any contributor to not add a folder, you might consider writing your own GitHub Action in order to reject automatically a PR if the wrong folder is detected.
You can use a GitHub Action like ArangoGutierrez/GoLinty-Action and adapt it in order to check for a folder in the checked out code.
If the test fails, you can then reject the PR.
Is there any way to disable viewers to download my files from github?
I want to show my work, but I am afraid anybody can steal my code.
You can't, Github actually means you want to share something with the community, or you are showcasing your work in the open source community. Unfortunately you cannot restrict the users from downloading your content from your Repository.
Alternatively what you can do Just make your Repository private. But then in this case you are not able to make you work available to view for audience.
More you can read here :-
https://help.github.com/en/github/building-a-strong-community/limiting-interactions-in-your-repository
Disabling zip/tarballs on GitHub at the moment seems to be impossible, but it would be useful for those using git submodules, which are not included in the automatic created archives, where the repository owner could replace them with a continuous integration job with something like git-archive-all.
A couple years ago I created a C# program for one of my classes. We had to work in groups and used GitHub. Now that I finally graduated I'm trying to add some code to my GitHub account to show to prospective employers, I realized that that program is not in my repositories (another teammate created it, but I contributed). Also, we have a lot of useless files in that repository and everything is a mess, it doesn't even has a Read Me.
So, my question is: should I create another repository without the useless files and cleaner code? Or should I fork the repository? What would be the best way to add it to my profile?
Also, what book, video, website, etc. would you recommend to learn how to use GitHub fast?
if you fork the repository people will see that you forked from a repository and there will be a history of commits made by whoever committed into that repository.
Assuming that it is not a very large code base, why don't you just create a new repository and just start doing the project again in a progressive manner where you can demonstrated your skills on the project. I am assuming as you already done the project early it will be easier for you to create the project ground up and will give you a chance to improve the previous code along the way.
you can find lots of git hub tutorials for beginners if you just search on google.
try git
I find this is very useful git scm
git for begginers
I want to open the issues tab when I open repository because I made a repository just for collecting the tasks for all my project , How can we do that ?
As #VonC has said, this is NOT configurable. It seems that what you require is an issue tracker and not specifically a repository. This articles may help you find an issue tracker that fits your purpose:
http://mashable.com/2014/02/16/bug-tracking-apps/
http://www.thegeekstuff.com/2010/08/bug-tracking-system/
Github's feature for referencing issues in commits automatically just by using the # and referencing commits in issues using the commit hash id is powerful. But is it a maintainable or scalable approach to handle issues from different repositories in one central repository? I do not think so. Issues are important in project development and should be kept organised the same way we keep code clean and organised.
However, this does not mean that it is not possible to maintain your issues in a single github repository. Instead of trying to have the issues tab open automatically, you may create a manual, as a README, for instructions on utilizing the reported issues. This manual will be shown to users visiting the repo. See https://github.com/keybase/keybase-issues as an example. You may find this github article useful in referencing issues.
This doesn't seem to be configurable.
That means you need to open your repo directly at the "Issues" page:
https://github.com/<username>/<reponame>/issues
I just found the Mottie/tablesorter repository after implementing the –what I thought to be– original repository from Chrisitian Back.
The description of Mottie's repo says:
Github fork of Christian Bach's tablesorter plugin + awesomeness
Now when reading this, three questions come up:
Why is this one not marked as fork on github (usually if this is a little hint below the repository name if it's a fork - that's missing on this repo)
Is "+ awesomeness" in the repository description something specific (e.g. a JS lib) or is this just some kind of "marketing term" for this repo?
What are the major differences between this repository and the original one from Christian Bach?
Can I easily migrate to Mottie's repo (as it is much more vivid according to its Pulse)? What do I have to watch at when doing so?
As I mentioned in the issue that was opened:
Christian Bach added his GitHub repository on May 20, 2014, whereas my fork was created somewhere around June 2011. So there really isn't a way for me to fork from his repo now. Nothing is missing, except for a few documented changes to the options; but a lot has been added.
"+ awesomeness" was just added to distinguish this fork from the original; especially because most of the widgets available for this fork will not work with the original. I have tried different methods to help distinguish this difference... "+ awesomeness" is just one way. Now the main document page has "unoffical fork" at the top to try to make it more obvious. Eventually, I plan to rename this fork to Abelt (which has lots of breaking changes) to avoid further confusion.
I have some documented differences on the summary wiki page. Sadly, I haven't had the time nor the inclination to update it since version 2.7 (currently we're on v2.18.3). That should at least get you started. Other than that, I feel like the documentation is pretty extensive, so you can always fall back on it if you have questions.
If you have a basic set up working with the original tablesorter, then there is shouldn't be any major changes needed to just swap out the original with the forked version. With a more complex set up, you might have to tweak a few things. Post some code, I'll try to help. It won't be as bad as you think.