I have 2 rails applications that live inside the same git repo.
There is a shared folder where common logic lives.
- app_1
- shared
- app_2
The shared folder is really just a symlink to the appropriate places inside the app_1 folder. There is also a shared_public folder that is symlinked to app_1/public/files and app_2/public/files.
How can I do this? I'm open to anything, it's a clean slate. The project was never deployed previously, so I don't have a existing infrastructure to rely on. And splitting the shared logic out is (unfortunately) not an option currently, because of the timeframe I have to work with.
Git
When you mention the shared folder is a symlink - this only exists in operating systems, not git
Since git is just a deployment mechanism in this instance (I.E will place your files from your repo onto your server), you'll probably be able to do the following:
Initialize a git repo on your server ($ git init on your server)
Clone your github repo locally (git clone https://github.com.... on your local box)
CD into your new folder and add the server's repo as a remote
$ git push [server repo name] master
This isn't what you want, I know.
It will push your files onto your server - so you'll get the following folder structure:
app1
app2
The shared folder could then be created on your server itself.
If you have your appropriate server setup, you should be able to get this running from performing these steps
Capistrano
If you want to use Capistrano, you'll have to do something a little more involved, as this does more than just push your files to your server
If you want to use Capistrano, you'll have to split your app1 and app2 into separate applications, and deploy them individually. This will still allow you to create a symlink on your server, except you'll have a slightly different structure to your directories
Related
Im using jenkins to pull a git repo then deploy all folders to a remote server. But the problem is I want to push all folders including its subfolders which may contain its own subfolder and so on.
I tried to use **/**/* for source files filed but it is ommitting some folder specially in sub folders. How can i use push over ssh to push n level of directories and all of their containing files to remote.
I'm working on an Xcode project and my brother wants to start helping out. I have the .git folder in my Xcode project directory, how can my brother pull / push / commit to / from my computer? Do I have to use OS X server and put the repo inside of there, or is there a simpler way to do this?
One simple option is to enable "remote login" in sharing, which enables ssh, then you can use the ssh protocol to clone the repository. Remote login preferences will tell you:
To log in to this computer remotely, type "ssh username#computer.local".
username#computer.local will be replaced with your username and hostname. In terminal, use:
git clone username#computer.local:[path]
on your brothers computer to clone the repo to him, where [path] is the path to the folder containing the repository. You will need to enter your password, and you will need to enter it in order to copy changes back later with git push or whatever.
You can set up passwordless ssh with private keys, but bear in mind that by doing this you are effectively giving your brother entire control of your computer.
If you want to push code between two non-bare repositores, I recommend having a look at git-annex.
It is usually used for syncing large files between repositories, but it also contains a nifty way of syncing non-bare repositories (pushes go to synced/master branch that is automatically merged).
Basically, if one can write a ls path or ssh [user#]host:path ls command that would list your repository, then you can use the corresponding git clone [[user#]host:]path [optionalNewName] to clone from it.
Also if he (or you) is working on the same local machine, or has access to the local filesystem, one need only point to either the .git directory or the directory containing the .git directory.
To make clone a repository into another directory:
git clone . ~/2015Archive/repositoryB # copy pwd's repository elsewhere
git clone .git ~/2015Archive/repositoryB # same
git clone ~path/path/repositoryA . # clone other repository into pwd
git clone /home/brother/2015/projects/CoolProject ~/WORK/BrosCode
# with ssh from a remote machine
git clone me#brosmachine:/home/brother/projects/CoolProject WORK/BrosLameCode
git clone me#brosmachine:../brother/projects/CoolProject WORK/BrosLameCode
If you change into the target repository and do a git remote -v it will show you an absolute path to the 'origin' from which it was cloned. If it was a local dir, it will be just a plain, absolute path. If it was accessed through ssh, it will be a ssh [user#]host:path identifier.
Scenario
Project A is a Rails application:
Code hosted on GitHub on a private repo.
Deployed on Heroku (which has a readonly file system).
Project R that is an instance of Redmine, used to manage my project A:
Code hosted on GitHub on another private repo (same GitHub account).
Deployed on Heroku (which has a readonly file system).
Project CI that is an instance of Integrity, used to continuous integrate (by running tests) my project A:
Code hosted on GitHub on a third private repo (same GitHub account).
Deployed on Heroku (which has a readonly file system).
What I want
I want to be able to:
Use the Repository feature on Redmine on project R (in essence, to be able to see the repository from project R).
Run the tests on CI.
My problem
To clone and keep up to date the code of project A on both project R and project CI.
What I tried
For the 1. point, I've tried to follow the instructions found on http://www.redmine.org/wiki/1/RedmineRepositories, with the only difference that I've created the local bare copy of A into the root of R (because of Heroku's constraints on file system), which caused the creation of /A.git dir.
After that, I've re-deployed on Heroku the project R, and in the Redmine's project A settings I've configured as SCM "Git" and A.git as Path to .git directory (I've also tried ./A.git).
However, when I point to the tab Repository of A project on Redmine, I got a 500 with message:
"The entry or revision was not found in the repository."
Where am I wrong?
Any suggestion?
Thank you!
I think it is currently impossible to integrate Git or Mercurial repos with a Redmine instance running on Heroku due to the read-only filesystem constraint. I asked Eric Davis and he thinks so too. SVN and CVS don't require Redmine to have a local copy of the repo, and so I think they work, whereas Git and Hg don't.
I am new to the world of Git, GitHub and Heroku. So far, I am enjoying this paradigm but coming from a background with SVN, things seems a bit complicated to me in the world of Git. I am facing a problem for which I am looking for a solution.
Scenario:
1. I have setup a new private project on GitHub. I forked the private project and now I have the following structure in my branch:
/project
/apps
/my-apps
/my-app-1
....
/my-app-2
....
/your-apps
/your-app-1
....
/your-app-2
....
/plugins
....
I can commit the code in my Fork on GitHub from my machine in any of the folders I want. Later on, these would be pulled into the master repository by the admin of the project.
2. For every individual application in the apps folder, I have setup an app on Heroku which is a Git Repo in itself where I push my changes when I am done with the user stories from my local machine. In short, every app in the apps folder is a Rails App hosted on Heroku.
Problem:
What I want is that when I push my changes into Heroku, they can be committed into my project fork on GitHub as well, so, it also has the latest code all the time.
The issue I see is that the code on Heroku is a Git Repo while the folders which I have on GitHub are part of a Repo.
So far, what I have researched is that there is something known as Submodule in the Git World which can come to the rescue, however, I have not been able to find some newbie instructions.
Can someone in the community be kind enough to share thoughts and help me to identify the solution of this problem?
The idea behind submodules is that they're all separate git repositories that you can include into a master one and rather instead of including all the files it includes a link to that submodule instead.
How to use submodules
To use a submodule, first you must extract out the directory and create it as its own git repository by using git init. Then you can upload this separately to Github or [place of your choosing] and to use it as a submodule use the command: git submodule add [place/to/put/it] git://github.com/you/proj1.
Separation is best
I would think it better to leave these separated out as their own git repositories and push to heroku from each one. The reason? It's more likely (I feel) that you're going to be working on one at a time and doing a git commit and git push heroku master for that one only.
If you wished however to deploy all applications at the same time you could recurse down the directory tree using this Ruby script placed in the top-level directory:
Dir["**/*"].select { |dir| File.directory?(dir) }.each do |f|
Dir.chdir(dir) do
`git push origin master`
`git push heroku master`
end
end
Of course this would only work if you have staged all your changes. I can't think of a way to automate that as Ruby <= 1.9 doesn't have the module to read your thoughts.
In production, I maintain two sites - beta and release. Each points to a different directory via a soft link (e.g.)
beta_public_html -> /home/scott/myapp/trunk/public
public_html -> /home/scott/myapp/branches/1.2.3/public
I'm a longtime svn user, moving to git. I'm used to deploying via svn update and changing the soft link on a new branch, things are pretty simple.
Now I'm moving to git. I still need to have the two soft links (it's a Rails app using Passenger), though now I want them to point to two different git branches ("beta" and "release", say). And I want to be able to update them via git push (or git pull).
Question Part 1: I'm not sure the best way to do this.
The way I had started to do it was to just deploy to two different remotes, e.g.
git push ssh://scott#x.com/home/scott/myapp-beta beta
git push ssh://scott#x.com/home/scott/myapp-release release
But this doesn't work because push doesn't update the working tree by default.
So I go into the remote directories and run git reset --hard the first time, and it pulls the working tree. But I push again and I can't get the new push to show up - it just stays at the initial one.
(BTW, note that I can't seem to push to "myapp-beta.git" - that fails, I have to push to the directory name. I am worried that this is part of the problem, but I don't know what I did wrong here.)
So, if the answer to Question 1 is that my method is fine, Question Part 2: what's wrong with what I'm actually doing? If there are hooks I should be using, can someone point me to them?
(An answer to Question 1 that says "run these seven manual steps" will not be a terribly useful answer, seeing as svn checkout + ln -s are two steps.)
Thanks. I want to get back to writing code.
The article Git push is worse than worsless has an interesting discussion about a similar issue.
One of its solution and conclusion involves:
a bare repository on the production server
a cloned repository with a hook to pull what has been pushed into the bare one
So in your case,
one bare repo on which you can push beta and release branches
two cloned repo 'beta' and 'release' with a hook to pull their respective branches from the bare repo.
In short: one step: git push. No more link to manage (since the directory no longer represent a branch in Git, unlike SVN)
Regarding the hook part, a post-receive hook in the bare repo could be all what you need
See Git Tip: Auto update working tree via post-receive hook
$ cd bare
$ chmod +x .git/hooks/post-receive
with a post-receive hook like
#!/bin/sh
cd ../../beta
env -i git reset --hard
cd ../../release
env -i git reset --hard
Note:
the post-receive hook starts out with the GIT_DIR environment variable set to the repo/.git folder, so no matter what path you 'cd' into it will always try to run any following git commands there.
Fixing this is simply a matter of unsetting the GIT_DIR.
'env -i' does just that: it ignores the inherited environment completely and uses only the supplied variables and values.
The solution is to push to single repository, which would employ update or post-receive hook.
There are a few separate possibilities to create two checkouts, which can be used in hook (on server). Going from most lightweight:
If you don't need for those two checked out directories (checked out versions) to actually be git repositories, you can simply use git-archive to export two snapshots (two branches)
git archive --format=tar --prefix=public_html/ master | (cd /var/www/html && tar xf -)
git archive --format=tar --prefix=beta_public_html/ devel | (cd /var/www/html && tar xf -)
where 'master' and 'devel' are names of branches that you wanted to have checked out. Note that --format=tar is not strictly speaking needed, as tar format is default for "git archive". You might also want to remove old contents ("rm -rf public_html/" before "tar xf -" in first line, joined with "&&", and similarly for the second line).
Alternate way of exporting files would be to use low-level commands "git read-tree" (which writes tree to index) and "git checkout-index" (which copies files from index to working area).
In this solution the repository you push into can (and should) be bare, i.e. without working directory itself.
Another solution would be for the repository you push into to have two working directories, which can be created using git-new-workdir script from contrib/workdir. Each of those working areas would have be a checkout of appropriate branch of this repository.
Then update or post-receive hook would unset GIT_DIR, go to those working areas (public_html and beta_public_html), and do "git reset --hard" there.
In this solution "checkouts" would have some git-related metainfo in them (in hidden .git directory).
Yet another solution would be to have two (additional) slave repositories. Pushing into main (master) repository would then (via hook) either push into those two slave repositories, where their hooks would do "git reset --hard" or equivalent, or go to those two slave repositories and do a "git pull" from master there.
Those two slave repositories would be non-bare, and can be [directly in] public_html and beta_public_html. In this solution "checkouts" would be full-fledged git repositories itself.
You can improve this setup by having those slave repositories to have "alternates" (alternate object database) to point to master repository (i.e. be cloned with "git clone --shared ..."); without this object database in slaves starts hardlinked to master. This of course is possible only if master and slaves are on the same filesystem.
Note this solution allows for master repository to be on different host than slave repositories. (although I guess this is flexibility you don't need).
Finally you can instead of current setup deploy gitweb or some other git web interface (see InterfacesFrontendsAndTools and Gitweb wiki pages for a partial list), so that your users can browse different versions and different branches of your repository at their leisure.
In gitweb (and I guess also in other git web interface) thanks to path_info URL support you can view files in browser, and follow links correctly (if they are local), see e.g. git.html from 'html' branch of git.git repository at repo.or.cz.
P.S. "git push" does not update working directory in remote repository by default, because if somebody is working in the non-bare repository you push into, such sideways push can be very unexpected and lead to loss of work.
I use a post-receive hook like this to publish my website, because Git does not touch the working directory when doing a push. The remote repository is a non-bare repository, i.e. it has a working directory.
if [ -n $GIT_DIR ]; then
# Current dir is "<reporoot>/.git/", but we need to run reset at "<reporoot>/".
# Clearing GIT_DIR is needed, or reset will fail with "fatal: Not a git repository: '.'"
unset GIT_DIR
cd ..
fi
git reset --hard
(BTW, note that I can't seem to push to "myapp-beta.git" - that fails, I have to push to the directory name. I am worried that this is part of the problem, but I don't know what I did wrong here.)
When creating a bare Git repository (git init --bare) which does not have a working directory, it is a convention to name the directory "something.git". When having a non-bare repository, the repository is actually in the ".git" subdirectory, so the full path is "something/.git". It seems that in either case you can leave out the ".git" part and Git will detect it automatically.
I'm not really opposed to the other solutions, but I think there's a less hack'ish "Git way" to do this. Here's what I would do:
On my server, I'd set up a sort of a centralized repository (to be managed by Gitosis or some such thing).
From the client end, I'd constantly pull from the repository, make changes and push back. Branches are ofcourse, managed automatically.
I'd pull the required branch from Gitosis into public_html/ beta_public_html of the server. I'd keep it in sync with Gitosis periodically using a Cron job. If you don't like the Cron job idea, you could always use some sort of a hook + script as the others have pointed out.