I have a VPS running a Node.js / React app.
I want to update the files in the vps each time I push data to the git(hub).
I found out, using this answer, that I can add some hooks in git, executing commands on "post-receive".
What I didn't quite understand :
Why did he init another git ? Couldn't he have done this in the .git directory and create the hooks/post-receive file?
Why git checkout -f ? If the goal is to update local files, so nodemon / create-react-app restarts the server / app, why not execute a git pull instead ?
Is there a better way of doing this ?
In the recommended answer there, nobody is using GitHub and there is no other Git repository yet. So the answer to your question:
Couldn't he have done this in the .git directory and create the hooks/post-receive file?
is: No, there was no .git directory in the first place. The target machine had nothing at all, no Git repository, no working tree, etc. The git init --bare created the Git repository (the ".git directory").
The git checkout -f is a poor-man's / low-quality implementation of push to deploy. A receiving repository is normally "bare", and this one is no exception.
why not execute a git pull instead ?
That would require creating a third Git repository. That would have been an option.
"Better" is in the eye of the beholder. There are many ways of doing this, each with its own pluses and minuses. See also Deploy a project using Git push, which notes that since Git 2.3, receive.denyCurrentBranch = updateInstead is available; it was not available prior to 2015 (and in 2015, many people had older versions of Git installed).
Note further that if you're using GitHub as a hosting system, this changes a number of variables. The questions and answers you and I have linked here are aimed at those not using GitHub.
Related
I setup a git server on Debian and created a folder called git in /srv/git/.
Inside the folder, I'd like to divide my git projects by cloud hosted cloud and on-prem hosted on-prem. Inside of these two folders contain the hostname and it's specific files needed for deployment, redeployment, etc.
So a server that does apache on the cloud with a hostname like webapp will have a folder structure like /srv/git/repos/cloud/webapp.
Should the command git init be ran from the cloud folder or webapp folder?
I presume your setting up the bare repo.
As you mentioned in the question, you want to have separate git projects plural here so what I understood is you want to have more than one project under cloud directory.
Method 1:
cloud
|------->webapp
|------->something1
|------->something2
Very straight way is doing /srv/git/repos/cloud/webapp.git here webapp is the git repo.
Setting up the webapp as git repo.
git init --bare /srv/git/repos/cloud/webapp.git
--bare: for the bare repo you can skip this using on exisiting repo.
Though init is not harmful to give on existing repository is safe. It will not overwrite things that are already there
Method 2:
cloud (git repo)
|------->webapp (submodule)
|------->something1 (submodule)
|------->something2 (submodule)
In another option where you can keep cloud as git repo and make webapp as submodule. That is repo inside the git repo.
You can choose what fits to you best.
I suggest to use two different repo, if your have plenty of submodules in one git repo it might be cumbersome at the start to keep track of things.
The answer to your question is that you should run git init from the cloud folder, giving webapp as the first argument, i.e. git init webapp.
That said, you could also create the webapp directory, change into it, and then run git: mkdir webapp; cd webapp; git init; The end result will be exactly the same, but why bother?.
One project of mine stopped showing history or reacting to push events in any way after upgrading to gitlab version 8.3.2 (but it could also be on previous versions as we update frequently).
I'm using a plain gitlab docker installation. Is there a way to let gitlab reload the commit history ?
UPDATE:
This is happening on serval projects not just one, but until now there's no common factor between them apart from having recently enabled CI and being imported from an external git repository.
Finally I got it!
The cause of this behavior was that the git repository was imported with the wrong directory structure.
It was:
repository.git/
|
+-> .git/<bare-repo-content>
Instead of just:
repository.git/<bare-repo-content>
The fix was to simply rename and move the bare repo:
mv repository.git/.git tmp.git
rm -rf repository.git
mv tmp.git repository.git
Just installed a fresh new 6.8 Gitlab on a brand new high performance server.
Before considering to forget my repositories history (comments, issues, etc...), do one know of a way to export a repository data from a Gitlab server to another Gitlab Server ?
I just failed to found anything on the documentation for exporting/migrating the whole project data (not just the git repository and its wiki).
For GitLab versions >= 8.9 (released in June 2016) you can use the built-in export and import project feature.
Please not that for the existing installations of GitLab, this option has to be enabled in the application settings (URL: /admin/application_settings) under 'Import sources'. You have to be a GitLab admin user to enable and use the import functionality.
Here is the feature complete documentation: https://gitlab.com/help/user/project/settings/import_export.md
I have actually done this recently, we were upgrading our instance of gitlab and needed to save and import repositories to the new installation.
First, create a bundle of the checked-out repository. For example, say you checked out a repository we will call myrepository
To check out the repository use git clone (let's assume your repository is under the root account and the ipaddress is 192.168.1.1)
git clone http://192.168.1.1/root/myrepository.git (or match your environment)
Now this step is somewhat important; you need to change into the working directory that has the .git folder of your checked out repository.
cd myrepository
Next, you create a bundle file:
git bundle create myrepository.bundle --all
Import the bundle file into the new instance of gitlab.
Create a new 'myrepository' on the gitlab gui interface
clone the empty repository; let's say this new gitlab has the ipaddress 192.168.1.2:
git clone http:\\192.168.1.2\root\myrepository.git (or match your environment)
You will get warnings that you cloned an empty repository. This is normal.
Change into the working directory of your checked out repository and do a git pull:
cd myrepository
git pull file/path/to/myrepository.bundle
this will pull the repository into your clone. Next you can do a git add, git commit and git push
This should work assuming you have the gitlab server settings set up correctly; you may have issues such as needing to add a client_max_body_size parameter in your nginx.conf file and also a 'git config --global http.postBuffer' to push large files.
Another way to do this is to make patch files of each commit and then deploy them:
This involves doing a 'git format-patch -C 0badil..68elid -o patch_directory_path' and reference the range of all your commits and have them pushed to an output directory; this should give you one patch file per commit. Next would involve git cloning the new empty repository, changing into the working directory of the clone and applying the patches to the new repository using 'git am patch_directory_path'
For GitLab versions < 8.9, without built-in export/import feature, I recommend a great tool from Marcus Chmelar, gitlab-migrator. I used it successfully many times with older GitLab versions so you should too. Just be aware of its limitations.
For the repos themselves, you can use git bundle: that will generate one file, that it is easy to copy around.
(as I described in "Backup a Local Git Repository")
But another way is simply to git clone --mirror your repos from the first server on a local workstation, and git push --mirror to the new server.
This is what GitHub details in its help page "Duplicating a repository".
In both cases, you need first to declare those repos on the new GitLab server, in order for them to be initialized, and ready to receive commits.
But for the rest... not easily. There is a feature request pending:
(Update August 2016, 2 years later: GitLab 8.9 has that feature implemented)
(for GitLab version older than 8.9, see and upvote Greg Dubicki's answer)
I agree that issues are the main thing to make exportable first.
They are stored in the database. Storing them in git is not an option. Maybe export them as a formatted file (SQL, YAML or something else).
This blog post illustrates the export of a mysql database.
Use mysqldump to create dump of old database, then create a new database on the new server and import this.
On old:
mysqldump gitlab | gzip > gitlab.sql.gz
On new:
gunzip < gitlab.sql.gz | mysql gitlab
Run the db migrate command to make sure the schema is updated to the latest version.
sudo -u gitlab -H bundle exec rake db:migrate RAILS_ENV=production
So I have been plagued with this weird git problem that myself and a few other developers have not been able to solve. Here it is:
I created a bare repo for managing website changes using git on test server.
For this example the repo is here: /home/website/website.git
The website public root would be here: /home/website
I created the repo by doing this command: git init --bare
inside the git repo directory "website.git"
Next I have my local repo on a machine elsewhere. This is a standard git repo. I build the site get it ready to deploy. When its ready I push it to the bare repo. From my local repo.
There is a post-receive hook that checks the latest file tree out into the public root of the website. So when I change things on the local repo and test them in the localhost environment, once satisfied I can push them to the live server.
Here is the problem I face:
I can push fine. No issues. All works as expected. Code gets checked out to public root. Everybody is happy and goes on with their life.
BUT!!!:
The site is a CMS site. Users log in to it and upload things. Files get created on the public root of the website which is the GIT_WORK_TREE.
So NBD right?! I can just commit the files every now and then from the live bare repo and pull them back to my local environment like I have before. So I log into SSH on the server. Navigate to /home/website/website.git
Then run this command:
GIT_WORK_TREE=/home/website/ git add ../
I get this mess:
error: unable to create temporary sha1 filename ./objects/cb: No such file or directory
error: error_log: failed to insert into database
error: unable to index file error_log
fatal: adding files failed
I have done this before on other servers and it worked fine from what I remember. So I was like WTF, must be something strange on this server. I went to another server I have and replicated the EXACT same steps. Got the EXACT same problem. So now I fear I am loosing my sanity and maybe these previous git experiences are all made up in my head.... *Well, lets not go that far yet.... :)
Maybe somebody can help me out here. I have used git plenty and can't seem to crack this one.
Oh, some other maybe useful specs:
running CENTOS 6.2
I double checked all permissions. I even tried changing everything to 777 recursively just to make sure Im not loosing it somehow. Made sure all the files are owned by the correct user. chowned recursively. I also tried the standard solution to this problem which is described here: https://answers.atlassian.com/questions/132671/git-commit-fails-with-sourcetree-error-unable-to-create-temporary-sha1-filename-git-objects-d8-file-exists
That didnt work either. Not sure where to go from here.
PLEASE HELP ME!!!!
I feel like Linus is playing cruel tricks on me right now.
You have a bare git repository in /home/website/website.git which is inside of a git repository in /home/website? And then you try to trick the bare git repository into having a working tree using GIT_WORK_TREE?
Maybe it is worth understanding this setup but only if you intend to be a git developer. As you are a user focused on delivering website functionality, I suggest using a standard git setup.
Move the bare git repository elsewhere:
$ mkdir /home/repo
$ mv /home/website/website.git /home/repo/website.git
$ cd /home/website
$ git remote set-url origin /home/repo/website.git
I got the solution. This is it. I was running the above command from the git repo.
Turns out the command should be run from the work tree and altered to look like this:
GIT_WORK_TREE=/home/website/ git --git-dir="./website.git/" add ./
First off, forgive me if this is a duplicate question. I don't know anything but the basic terminology, and it's difficult to find an answer just using laymen's terms.
I made a project, and I made a repository on Github. I've been able to work with that and upload stuff to it for some time, on Windows. The Github Windows application is nice, but I wish there was a GUI for the Linux git.
I want to be able to download the source for this project, and be able to edit it on my Linux machine, and be able to do git commit -m 'durrhurr' and have it upload it to the master repository.
Forgive me if you've already done most of this:
The first step is to set up your ssh keys if you are trying to go through ssh, if you are going through https you can skip this step. Detailed instructions are provided at https://help.github.com/articles/generating-ssh-keys
The next step is to make a local clone of the repository. Using the command line it will be git clone <url> The url you should be able to find on your github page.
After that you should be able to commit and push over the command line using git commit -am "commit message" and git push
You can use SmartGit for a GUI for git on Linux: http://www.syntevo.com/smartgit/index.html
But learning git first on the command line is generally a good idea:
Below are some basic examples assuming you are only working from the master branch:
Example for starting a local repo based on what you have from github:
git clone https://github.com/sampson-chen/sack.git
To see the status of the repo, do:
git status
Example for syncing your local repo to more recent changes on github:
git pull
Example for adding new or modified files to a "stage" for commit
git add /path/file1 /path/file2
Think of the stage as the files that you explicitly tell git to keep track of for revision control. git will see the all the files in the repo (and changes to tracked files), but it will only do work on the files that you add to a stage to be committed.
Example for committing the files in your "stage"
git commit
Example for pushing your local repo (whatever you have committed to your local repo) to github
git push
What you need to do is clone your git repository. From terminal cd to the directory you want the project in and do
git clone https://github.com/[username]/[repository].git
Remember not to use sudo as you will mess up the remote permissions.
You then need to commit any changes locally, i.e your git commit -m and then you can do.
git push
This will update the remote repository.
Lastly if you need to update your local project cd to the required directory and then:
git pull
To start working on the project in linux, clone the repo to linux machine. Add the ssh public key to github. Add your username and email to git-config.
For GUI you can use gitg.
PS : Get used to git cli, It is worth to spend time on it.