Scale up as you grow — whether you're running one virtual machine or ten thousand.

From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.

This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Really good set of tutorials on Git. Thanks very much.
I have taken it a step further and created a ‘post-receive’ so that when I do a push to the live server it should then checkout to the virtual hosts directory of the website.
#!/bin/sh GIT_WORK_TREE=/var/www/domainname/public_html/ git checkout -f
However, when I try to do my push, it goes out the master successfully but I get permission denied errors when trying to create those files on my server web root.
e.g. remote: error: unable to create file index.php (Permission denied)
These errors actually make sense to me due to the way I have setup my server as per D.O.'s great how to articles. I disabled root access and created a new user that is added to the sudoers through visudo. Then setting up SSH keys for this user. I use this user for pushing out my git changes to the server.
The issue is, I believe, that this user that I connect to push doesn’t have the rights to write to the virtual hosts directory. All my files in these folders are owned by www-data (my nginx user) with the same group.
What is the solution? Create another user (SSH key) to connect with just for git that has higher permissions or is there a way to grant the post-receive sudo like abilities?
Apologies for the very long winded comment but wanted to be absolutely clear.
BTW you really should link the 2nd and 3rd git articles to the first making them easier to find.
I guess this sounds silly, but now I do have a master and develop branch of my project, but they are still in the same folder.
What I mean is, I do want a spot on my server where I can develop, and then merge/push/pull (or whatever this is called haha) my developed files to the ‘master’ spot on the server where the live website is.
Or did I completely miss the correct use of git?
@martijn: The spot where you develop and merge is basically where your repo is.
You can switch from master<->develop any time you want by running the ‘git checkout [BRANCH]’ command where [BRANCH] is either master or develop.
That part I thought get, but in my case (as I expect many people) are not developing using the nano editor over SSH, for instance i’m useing notepad++ with an SFTP connection, and if I’m not mistaken, it does not matter which brance I checked out all files and the latest version of the files are availible…
@martijn: I recommend you read more on branches: <a href=“https://www.atlassian.com/git/tutorial/git-branches”>https://www.atlassian.com/git/tutorial/git-branches</a>
Hi, thanks for the great article,
One question I have and don’t seem to find any answers is what if I want to publish remotely the build version of my app not the whole master branch. The story is the following, on the master you might have all the source files but than maybe you use an automation tool (like grunt) to modify your files and prepare them for the deployment and put this in a build or distro folder. Is there a way to push only this from the master to the remote repo?
basically the workflow would be
thanks for any ideas :)
Great tutorial.
One quick suggestion, could you please elaborate on the --no-ff flag of the merge command. It will help those who are new to git understand the concept of fast-forward, especially because there are so many different use-cases that can exist with a merge. Maybe it should be taken up in a new article in detail, but a small text around the flag will be very useful.
@pandey.vaibhav: I found this explanation fairly good:
The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature. Compare:
In the latter case, it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it is easily done if the --no-ff flag was used.
It’s a little confusing to have the branch called develop and the file too.
Call the file test_file or something.
Otherwise: great!