Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm currently looking to release an MVC / RavenDB as an open source repository mostly just to let people look around rather than as a full on project.
However I don't want certain production settings such as SMTP Server details and Connection Strings publicly exposed (but still under source control).
I'm looking for suggestions on how I should structure public and private repositories so that I can easily work on the project and have reasonably hassle free deployment.
Cheers
In cases similar to yours where I need to publish parts publicly and keep import data hidden, I usually very simply keep a branch only for production.
In your case, you could either make the dev branch where you publishing everything open source, clone it and receive some contributions from other people. Then have a production branch somewhere different. (heroku..)
You normally don't put those files under version control. Inside a company, say, you can put a template under version control and ask your developers to copy it into place and update as necessary. Like a config.ini.template file with
[smtp]
host = smtp.company.com
user = USERNAME # update this
pass = PASSWORD # and this
where it's clear that the developers need to update the credentials when they rename it to config.ini. The config.ini file should then be excluded from version control.
For an open source project I would probably not put any template under version control. I would still configure it so that the config.ini file is excluded from version control so that I can have my own config.ini file in my working copy without committing it by accident.
I find the above system much easier than putting the real config files under version control. Even if I can put it in a private branch of some sort, then it will require me to constantly merge with that branch and I'll have to be careful not to accidentally push the config file to another repository.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 1 year ago.
Improve this question
I am a newbie to both StackOverflow and Opensource contributions, excuse me if I didn't put it correctly.
Here's the question :
I heard some contributors saying that you need to clone the open-source project's code to your machine to be able to contribute to that project, And at the same time they say that you fork it.
I don't understand why we need to clone the code when we can fork it. Or both ways are fine?.
Please help me with this.
On GitHub, a fork of a repository is a copy of it that the owner (in this case, you) controls. That lets you make changes to it by pushing additional branches containing code, and then, if you want, to make a pull request from your fork into the main project, requesting that the owner of the main project include the code from that branch. Both the fork and the original project are Git repositories that are stored on GitHub.
Technically, you don't need to clone the code from GitHub if you've forked it since you can just edit the code in the GitHub web interface. However, practically, people prefer to write code on their own machines with their own editors and development environments. Usually you want to test the code you're writing as well, so you need it to be local to do that. So typically, you clone the repository to your system, create a branch, and make changes there. Then you can push the branch to your fork on GitHub, and then, if you want, create a pull request to the main repository.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am trying to create a book on Github and honestly I don't have the time to learn how to code and dig into all the new terminology/technology and learn the in and outs of Github as it's really not user-friendly.
All the tutorials are too dense and not suited for beginners. I just want to generate content for my book. How can I do this? I'm pretty good at just taking a template and adapting it to my needs, but I can't even get a template to work.
I've installed the bookdown package in R and have opened up the sample book in R. How do I get this sample book onto Github website? I just uploaded all the files and when I go to my website, it just takes me to README.md
I am using Github through my browser and don't plan on installing whatever Github software there is and all that kind of stuff. I really don't have time to dig into how to use Github. So any tutorial will require me using Github through the browser.
When writing content for my book, is there a way to do it on the Github, or is doing it in Rstudio the easiest way?
I don't have much desire to upload my book to bookdown.org. Can I still build my website on github?
Do I need to convert Rmd files to md files? How do I do that?
There are plenty of books out there on Github (bookdown.org show cases many). I believe you are able to view the files/code and what not on Github, so it may be pretty easy to just grab a couple necessary files there. I don't know which ones are important, and even if I did, I don't know how to get it to work with my Github.
You can fork the rstudio/bookdown-demo and make it your own GitHub repository.
From there, follow yihui/bookdown/get-started.html, with, at a minimum:
Download the GitHub repository https://github.com/rstudio/bookdown-demo as a Zip file, then unzip it locally.
So no need for "Git/GitHub software" there.
Install the RStudio IDE. Note that you need a version higher than 1.0.0. Please download the latest version if your RStudio version is lower than 1.0.0.
Install the R package bookdown:
# stable version on CRAN
install.packages('bookdown')
# or development version on GitHub
# devtools::install_github('rstudio/bookdown')
Open the bookdown-demo repository you downloaded in RStudio by clicking bookdown-demo.Rproj.
Open the R Markdown file index.Rmd and click the button Build Book on the Build tab of RStudio.
Try that with a minimal example like yihui/bookdown-minimal
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 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 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.