Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
GitHub is a great place to share accomplished projects for veterans. It is also a good place for beginners to show their baby steps learning a new language. I am learning Java by debugging someones' else final code in tutorials. For instance, bot's logic in tic-tac-toe (original code is posted in GitHub) or a calc that displays "6.0-" instead of "-6" or crashes after a sequence "0/0=" instead of showing "NaN" (original code is posted in a blog only). Some day I will contribute to comunity, but for now the goal is to make it easier for the employer to evaluate my skills.
I want to gather my work in one place and give a credit to actual authors of the program. I considered using
//Corrections to bot's logic. Handling forks. Stepan's code
But that doesn't feel right. How should I proceed when authors post their stub on GitHub or elsewhere?
Thanks in advance,
Stepan
You can submit a pull request and make your contribution to the project. Once you push it with a commit mentioning the changes you have made, the original repository owner can decide whether or not to merge the branch you have created.
From [docs],
Pull requests let you tell others about changes you've pushed to a
repository on GitHub. Once a pull request is sent, interested parties
can review the set of changes, discuss potential modifications, and
even push follow-up commits if necessary.
This discussion suggests that:
(1) If the original author didn't post his code on GitHub, than just post it on your page. Give a credit to the original author by saying where the program comes from and placing comments like
//Fixing [description of] problem (your nickname)
to indicate your contributions
(2) If the project comes from GitHub try to push changes first. If it didn't work in a reasonable time - fork it. You will have your own source code with smart bots and exception handling.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Just curious as to what the general consensus is for committing code of GitHub.
Should you commit only build-able code? Or is there a time when unbuildable code commits have their place?
Or am I totally miss-understanding GitHub completely? If so, please inform me how it should be?
If the master needs to stay buildable, I recommend that you make a branch, and merge the branch only when the code is working as intended.
GitHub is a place for sharing your code to everyone, it's your wish if you want to make it public for everyone to use or contribute or keep it private.
There are so many advantages in uploading code to GitHub :
1> Others can look at your code for reference and can also contribute to it
2> It keeps all your coding records with history so you can show them to your company when you apply for a job
yes, you can also upload unbuildable code and open an issue and wait for anyone else to fix it.
and it's a good practice to keep 2 branches one for buildable code (master branch)
and another test branch for testing stuff
In general for git, the master branch is reserved for only buildable features. Other branches can be reserved for in-progress features to be later merged into the master branch once completed and tested. GitHub, for the most part, follows these rules too.
To me, it really depends on the kind of project you are working on:
If the commit is for a private project, (and therefore probably has little following) you can do what you want
If the commit is for a highly visited project, maybe think twice before submitting unbuildable code without making a note in the commit message that it is unbuildable
As always, if you own the repo, you can follow any rules you like, but if it is owned by another individual, be sure to follow the rules that they set out for the repo.
It just depends. Some argue that all commits should compile or be "build-able", but IMO that defeats the purpose of frequent commits.
Typically, when I'm developing a project my rule of thumb is commit after 20 minutes or so of developing, and push every hour or when I finish the branch/feature I was working on. So if you are working on a project individually, then committing with issues in your code may not raise any problems. Committing frequently is the whole purpose of version control applications like Git, and you have the ability to go back to any previous versions whenever you like. If you are working on a project with a team there may be some guidelines as to when you commit/push, so make sure to check with your team if that is the case. Check out What are the differences between "git commit" and "git push"? if you are trying to better understand Github.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I would like to publish a series of programming tutorials along with some code on github. The tutorials will be written in markdown. There will be several markdown documents with references to each other.
Now I wonder what would be the best option:
Put plain markdown files into the repository, together with the code
Use the github wiki for the tutorials and link to the code
Use github pages (e.g. with jekyll) for the tutorials and link to the code
I am not very familiar with github pages nor with the github wiki, so any hint about (dis)advantages in this context is helpful!
You have mentioned three different ways you can go about doing this, I'll elaborate on each of them...
Markdown files in repository
This method isn't actually too bad, because its possible for people to contribute to it as long as they know Markdown (and Markdown is very easy to learn anyway) as they simply need to send off a pull request after forking your repository. Also, since Github uses something called Github Flavored Markdown you can embed the code directly into each file and have some nice looking syntax highlighting.
Github Wiki
Using the Github wiki is a feasible option because it will make it easy for other people to contribute to it. However, you may prefer to have changes made by other people on a approval type system, this is when you'd go with the first option because of the pull requests feature. I personally wouldn't recommend that you use the wiki purely because it undermines the Github repository itself (having an empty repository with heaps in the wiki). This is just my personal opinion though.
Github Pages generator
You could use the Github Pages generator and make a website using that. However I would like to point out that it uses Jekyll to generate the site, and that the generator will only create one page automatically, the rest of the pages will be up to you to make using Markdown and a bit of HTML. It will look nicer, but it will be much more time consuming.
My personal recommendation
I recommend that you have the tutorial itself hosted in a Github repository written in Markdown, and then you can create a page using the page generator that will link to all of the parts of the tutorial (acting as a landing page)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Google Maps v2 is being retired, so I need to audit all our private repositories on Github for uses of it. I could clone them all down and run a grep, but there are a lot (mid 3 figures) so I’d rather do everything on the server if possible. Unfortunately Github’s search will only search public projects (as far as I can see), and I can’t see anything in the API to do what I want.
Any ideas?
Note that there already is a feature to grep code from private GitHub repos:
However, it has no API, so you'd need to do some good old scraping of links with the format:
https://github.com/creaktive/WUB/search?q=BEGIN&choice=code&l=&start=
To walk multiple repos, you could use iMacros for Chrome/Firefox, WWW::Mechanize if you're up to some Perl-fu, or PhantomJS if you're a JavaScript ninja.
If you know you're looking for patterns that are more or less consistent you can use the Github API to grep only the files that might be of interest to you.
For instance, you can get the contents of a file via the API: http://developer.github.com/v3/repos/contents/#get-contents
However, this assumes you know what files you've got (works well for Gemfile in Ruby, or requirements.txt in Python, not so great for Javascript).
The other option is to automate the search of the repos locally. It would be perfectly possible to write a script to git clone each repo in turn, grep it, and output the results (assuming you've got the time required for this to run, and the disk space).
I have seen a previous use of OpenGrok and typically has usecases such as yours.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm new to github and I like to help other people with their projects that I find interesting.
I know there are a lot of guides in the github place, but I think it could be nice to gather a bunch of real people's experiences.
So, I invite you to post about your first experiences in github.
Whether you are a not-so-newbie or you are a heavy rock in github comunnity, I think your lines could encourage real newbies like me about entering this great open source community.
It's pretty simple. You can summarise a simple community project's development into a circular process of just two simple actions:
Bug tracking. Testing the software, logging bugs, making sure they're filed in the right place, asking for more detail, etc. If valid, these reports carry the detail for the next phase:
Patching. Target a bug, reproduce it, change your code to fix it, test locally and push your patch. This loops back around to the first phase where the bug report is marked fixed or otherwise.
You've got to start with phase one. You don't have to follow a bug right through and you can help as simply as just hopping in and making sure other bug reporters are doing the right things (making sure there are dumps where applicable, making sure the tags are right, merging duplicates).
Or you can be more involved and test the software to find new bugs. The onus on getting things right is now your own.
Once you're more familiar with the project, its code and its maintainers, then you might be ready to get involved with fixing some of the outstanding bugs.
An important thing to remember is you can ask for help. Nobody expects an outsider to understand all the code or be able to fix all the bugs. Maintainers will very often be more than happy to help somebody get started because they'll often get their time back from work you do on the project.
EDIT: CodeTriage.com can help for this.
This is kind of an old question, but there is a new site that's trying to help people like the OP to find projects to contribute to.
The site is called Looking For Pull Requests (it's dead now in 2016) and it aims to help people looking for help to find people wanting to help.
You can just browse the list of projects and see how active they are, or you can even publish your project pretty easily.
Github is just a website which aggregates projects. You need to ask the project maintainers themselves how they want you to help. It is pointless asking here as we do not know the specific rules for the project you are interested in. Different projects have different ways of doing things and require help in different areas.
Learn how to use Git would be the number one thing to say. Oh, and make sure you following the coding standards.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm in a situation where some minor patches I've submitted to an open-source project were ignored or explicitly not accepted.
I consider them useful, but more important is that I need the functionality they implement.
I don't want to push my ideas and suggestions anymore to the main contributors, because I don't want to turn this into an ego issue. I've decided that my best bet would be just to use what I wrote for my own purposes. I don't want to fork the whole source code tree because I like how things are generally working, I'm just not happy with details.
But I do realize that the project will evolve and I would like to use the new features that will eventually appear. I understand that I'll have to merge all new things into my own source tree. Are there any best practices for this scenario?
The standard approach is to maintain a vendor branch in your repository. The idea is that you import a pristine copy of the original sources (called a vendor drop) into your local repository, and store it on a branch. This is the version of the code prior to applying your mods. You tag that with the version, then copy it to the main trunk and apply your patches.
When subsequent new versions of the vendor code are released, you check out the vendor branch (without your mods), and overlay the new version on top. Finally you merge the new branch with your mods, checking that they are still applicable/relevant, and you're ready to go again.
There can be complications e.g. with files being renamed, deleted etc. The script svn_load_dirs.pl, that comes with Subversion, can help with this by allowing you to identify files which have changed name and automating some of the bureaucracy.
This approach is discussed in detail (and much more clearly) in the Subversion book, under the section Vendor Branches.
If you are using Git, or could get used to use it, perhaps you should take a look at Stacked Git or Guilt.
They are layers on top of Git to keep track of patches.
Generally you would create a branch of the project in the repository. In your specific case, I would create a branch of just the directory that contains your code if that is possible. A lot of repositories like subversion will allow you to then check out your branch along side the main trunk. That should allow you to maintain your patches and ensure that they work with future changes that are made to the trunk.