I have taken a project live with the help of Heroku. I set secret keys properly, using environment variables etc, not committing local settings containing any secret keys etc.
Then, reviewing which actual files had been pushed to the git repo within Heroku, I found an 'old_settings'-file which in a pure oversight had been missed. That file contained the secret-key.
I cleaned out the file and pushed the changes to the repo (git push heroku master). Then I deleted all past commits following the last answer:
removing commit history in git
Should this be fine? Reading Mipadis answer so it seems:
Pushing secret keys to heroku, safe?
Should this be a problem, or would this be considered problem solved?
Appreciate any feedback, and should my English be confusing at all I'd be happy to clarify.
Edit
Generated a new secret-key the same way Django does it, and updated the Heroku environment-variable
heroku config:set secret_key=NEWKEY.
Question remains: would this be sufficient?
GitHub states:
Warning: Once you have pushed a commit to GitHub, you should consider any data it contains to be compromised. If you committed a password, change it! If you committed a key, generate a new one.
This article tells you how to make commits with sensitive data unreachable from any branches or tags in your GitHub repository. However, it's important to note that those commits may still be accessible in any clones or forks of your repository, directly via their SHA-1 hashes in cached views on GitHub, and through any pull requests that reference them. You can't do anything about existing clones or forks of your repository, but you can permanently remove cached views and references to the sensitive data in pull requests on GitHub by contacting GitHub Support or GitHub Premium Support.
It would be best to generate a new secret-key just to be sure.
Related
I'm using the code from a github repo for my project, and have been trying to understand some of the dev history about a problem I'm having. However, I'm unable to list the commits from one particular developer. Usually, you will see a link option to list all the commits, on the page of any one commit of any given author. But for this one dev only, that link isn't there. Github docs say this could be due to that author no longer having a github account, but that isn't the case here. Also, I can manually append a commits?author=username to the URL, but that doesn't work either. The only way I can see the commits is to load the network graph, scroll the timeline, and mouse-over each commit dot one at a time. It is a difficult way to scan through dozens of commits.
This is best done locally. Clone the repo and then use log or shortlog:
git log --author=author#email.com
or
git shortlog --author=author#email.com
gitk also supports the --author option to filter commits by author.
I currently use the lovely Github Pages to host a website. I would now like to try out some stuff, adding content, new scripts, ... So I have a dev branch in which I do this, and run a local webserver to test it. Once I'm happy with it I can push it to the gh-pages branch for 'release'.
However, I was now wondering. Is it possible to have the dev branch also be reachable anywhere just like the gh-pages branch? This would be very helpful in letting other people try out the new stuff I'm working on without having to risk releasing buggy code to everyone. So basically two gh-pages sites in one repo, one for release one for development.
Is this (or something similar) possible with Github?
So going carefully through the github pages documentation seeking for any solution using the offered functionalty it seems what you are looking for might have been nice but is not available, maybe the closest thing is to have two repositories for example username.github.io/production and another one that is forking it like username.github.io/development and working on it while pushing changes back to the production one using pull requests or any technique you would prefer
And if you like you can check out my post and see some techniques of altering your websites, as well jekyll has a _drafts directory which allows staging of a post and seeing it before being posted.
I think any branch can be reached via rawgit.com.
For example, if your user/organization is XYZ, you can reach the dev branch for your user/organization jekyll site at:
http://rawgit.com/XYZ/XYZ.github.io/dev/_site/index.html
Just don't include _site in .gitignore. You still have to build the site locally with jekyll build, so it's still not a perfect solution.
Alright, so I have started using Github to easily share my code, and to keep track of updates. My main problem is that I have put my code in my repo, but I am not sure how to update it without saving the updates as a different file, and then pushing that to my repo.
Short version: Is there a way to update my code without pushing a whole new file.
Your question isn't very clear but if I'm understanding you correctly, you can do the following:
Edit the files you need to change
Do git add for each file to make git track the changes i.e. add the files to the staging area.
When you're ready to commit, do git commit to commit the changes. This will commit locally.
When you are ready to push up to github, do a git push. Git is smart about sending up the changes, not whole files.
Git takes a while to understand and it sounds like you're not there yet. I would spend some time going through at least the first few chapters of the Pro Git book, which is available free online at http://progit.org/book/.
Hope this helps.
I started my Django project locally and have been using git just fine.
I got ahead of myself and copied the code to the server which instantly became out of sync with my local version. I hadn't done a branch or anything.
The two part question is what's the best structure for me to work locally, push/pull to test server and then update live server when test is solid, and how do I get it setup from where I'm at?
I've been developing with no branches in these early stages, but I'd like to instead follow standard practices for branching and merging.
I'm using NetBeans 6.8 locally for coding and I've also got GitX. So any integration tips would be helpful also but I'm comfortable doing whatever command lines are necessary.
Thanks!
James
First you should be able to have some form of communication between the git repositories you've got on your local machine, the test server and the live server. Git is very flexible in this regard so a few of the options are:
Have the test and live server pull
from your local repository.
From development push to the test and live servers on appropriate times.
From development push to production and have the test server pull from production.
Have a fourth location where you'll store your git repo and push from development to that repository and have test and live pull from there.
Either way, once you reach a stage where you'll want to try something on the test server, create a tag. On the test server checkout that tag (git checkout <tagname>) and do your testing. (And once you are satisfied that it works the way you want, you can also use that tag on production. But I guess that's pretty obvious. :) )
The intermediate step, between creating the tag and checking it out, completely depends on your setup. Using the fourth option I just mentioned you'll need to push your tag first and fetch it on the testing machine. So the whole process would look similar to this.
<development>$ git tag v1.0
<development>$ git push
<development>$ git push --tags
<testing>$ git fetch --tags
<testing>$ git checkout v1.0
<live>$ git fetch --tags
<live>$ git checkout v1.0
Optionally you can (ab)use git decribe to check which tag you've got checked out at currently.
Regarding the branching and merging: what I like to do is create a branch for every feature I'm working on. Once I complete that feature I merge it back to master. So If I need to release before a feature is done, I can just leave that feature (and every releated) commit out of the release.
But this is just one way of doing it. You can setup the workflow to suit your situation. Especially regarding the use of branches. A more complex setup is described by Vincent Driessen in his article A successful Git branching model.
Disclaimer: I'm using git almost exclusively with one authoritative repo on a server (the fourth option). I haven't personally tried the other setups I suggested...
Update to respond to the comment by iJames:
To make dev push to and test pull from a new/different repository by default from now on, see the accepted answer of this question:
$ git branch --set-upstream master origin/master
With regards to the terminology:
Push is relatively simple: it pushes your local commits to a different repository. See for instance the Git User's Manual.
Fetching does the opposite, it "will update all of the remote-tracking branches to the latest version found in the repository". (Quote from the Git User's Manual.)
The pull command not only fetches the changes in, but also merges them into the current branch. (See the example in the official Git tutorial.)
After my first question, id like to have a confirmation about the best git workflow in my case.
I have a single django project, hosted at github, and differents clones with each his own branch : customerA, customerB, demo... (think websites)
Branches share the same core but have differents data and settings (these are in gitignore)
When i work on CustomerA branch, how should i replicate some bug corrections to the other deployments ?
When i create a new general feature, i create a special branch, then merge it into my master. Then, to deploy on the 'clients', i merge the master branch into the customer branch. Is it the right way ? or should i rebase ?
# from customerA branch
git fetch origin master
git merge origin master
Also, i have created a remote branch for each customer so i can backup the customers branches to github.
It looks a very classic problem but i guess i dont use git the right way
Thanks.
Ju.
I would have a single project repo at a well-known place containing a master branch with the common code, and branches for specific deployments (e.g. customer/A customer/B demo).
Then I would have checkouts from each of these branches for each customer, for the demo server, and so on. You can let these pull automatically from their respective branch with a commit hook on the single project repo.
Every developer would have their local copy of the project repo, do local work, and then push stuff back to the single project repo.
The challenge will be to maintain the branches diverging from master and doing the regular merges so the diversion do not grow over time.
I have seen this solution describe somewhere in much more detail somewhere on the web, but I could not find it quickly again. Some blog post on using git for a staging and production web server, IIRC.
If the three sites share some 'core' code (such as a Django app) you should factor that core out into its own repo and use git submodules to include it in the other projects, rather than duplicating it.
I would have a repo called project-master or something like that and a repo for each client. Then, when you have code you need to be available to those client repos, you pull from the project-master to that repo.
Don't separate the projects in branches, separate them into different repositories.
Make the "common" code generic enough so that costumerA's copy of the common code is exactly the same as costumerB's copy of the common code.
Then, you don't have to pull or merge anything. When you update the common code, both costumerA and costumerB will get the update automagically (because they use the same common code).
By "common" code: I'm referring to the package/series-of-apps that power the websites you're developing.
I'm assuming costumerA and costumerB repositories would only include things like site-specific settings and templates.
The key here is making the "common" code generic: don't let costumerA use a "slightly modified version" of the "common" code.
Also, I'd suggest using a deployment mechanism that doesn't rely on git. git is a great source code management tool; but it's not designed (AFAIK) to be a deployment tool.