You have some fundamental misconception about how git works. 1. Its not a deploying tool. Your git server is only meant for "providing a neat way" to synchronize everyone's work. Not for deployment. Best idea is to make your release tarballs from your local dev machine and ftp it into the server. Don't use the files inside server's repo as production use.
2. Git does not recognize a file by its file_name. It considers files as "blob" object, which resides in "tree" object. A particular tree snapshot makes a "commit" object, some pointer to a commit object is "branch" object etc. All these objects has unique ID , identified by a SHA1 checksum. Now if you edit a file, its SHA1 hash changes, so from git's perspective its no longer the same "blob" object, its a different object. That's why you have to "git add" every time you make modification on a file. you have to do "git status" to see what have changed since last commit. And decide which changes should go into a particular commit, git add them, then do git commit. There is a shortcut "git commit -a" which adds all the changes. But i prefer adding them by hand because that way i can organize my commit. If two edits are functionally separate, they should reside in different commits. A commit should not be larger then one screen full of edits. If its a huge, then you're doing something wrong. Because the idea of VCS gets killed if your diffs are "huge" to comprehend. 3) My advice is git is for managing "source code versions" and its useful for the "developers". Your deployment strategy should not be based on git. It should be different. Tag your releases. Use "git archive" to make release tarballs. Then push them in the production server for deployment. You can write scripts which can automate the whole process. On Sat, Jun 29, 2013 at 2:21 PM, Ed Pataky <ed.pat...@gmail.com> wrote: > Gergely > > you said "Again, you can only do this if you don't need the source files to > be present on the server, or you can clone it to a separate directory to > access, test or serve them." ... > > I do not understand this .. why cant the files be on the server? I have a > std web server with web files ... scripts, html, etc .. can I not use this > bare repo idea for this? Why not? > > ed > > > On Fri, Jun 28, 2013 at 11:22 AM, Gergely Polonkai <gerg...@polonkai.eu> > wrote: >> >> Hello, >> >> if I was you, I would use a bare repository on the server side. This will >> render the server's repository unreadable for the human eye, but the >> server-side merging would become unnecessary. To do this, create a new >> directory on the server, and issue the command >> >> git init --bare >> >> in it. After that, simply `git push` into it from your local machine, and >> tell your developers to use that repo from then on (or overwrite the old >> plain text repository with the new, bare one). >> >> Again, you can only do this if you don't need the source files to be >> present on the server, or you can clone it to a separate directory to >> access, test or serve them. >> >> Best, >> Gergely >> >> On 28 Jun 2013 20:14, "HWSWMAN" <ed.pat...@gmail.com> wrote: >>> >>> Ok, I want to start over after having spent a few hours trying things ... >>> >>> Here is my situation ... I need to use GIT for some source control .. i >>> have never used any source control before and I want to use it in the >>> simplest possible way first, to get running, and have some version control >>> going on ... i have a very small team of only a few people, but in different >>> locations. >>> >>> I read some stuff and this is what I am planning on doing, please tell me >>> if this makes sense: >>> >>> I went on the server and used "git init" to create a new repo >>> added some files and directories, and commited them from the server >>> i installed and opened GIT GUI, simple and free, this is what i want ... >>> i cloned the repo to my local machine ... all good >>> now my understanding is that on the server is the master branch, so all >>> the developers who develop locally on their machines, should create a branch >>> so that they can push ... i created a branch on my machine called >>> <company>-<name>-<desc>, I will recommend all the developers to do this >>> I made some changes to files in the repo, staged, and commited ... all >>> good ... i also pushed and no issues ... >>> Now I notice i have to go to the server to merge the changes so the files >>> actually show up on the web server ... worked fine .. >>> So the idea is, since this all worked, that i would tell the developers >>> to (1) clone the repo (2) create a branch to work out of (3) do their >>> development and stage and commit changes locally, then push to the server >>> ... (4) then they should tell me they need me to merge the branch, and I >>> would ask for the branch name ... i would then go to the server and merge >>> the changes >>> Does this all sound good so far? Will it work fine? ... >>> Now if yes, if there is an issue, how do i roll back a change? .. can i >>> simply issue a command on the server, and have the files roll back to the >>> state before the last merge? How do i do this? >>> >>> Otherwise please let me know if this is not right in some way how i am >>> thinking ... note i do not care if i do not have the 110% most optimal way >>> of doing things, i just need a simple method to have some control, and some >>> tracking for now .. this seems to work and i just want some verification .. >>> i am sure more experienced users have suggestions as to how to make this >>> better/smoother/more efficient, and I welcome that too, but please do not >>> just say i am "wrong" because you know more than i do and you know a fancier >>> way .. what i want to know is if this above is reasonable, and if it will >>> work for basic tracking and control of source files ... >>> >>> Thank you >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Git for human beings" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to git-users+unsubscr...@googlegroups.com. >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Git for human beings" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/git-users/uZ15XbPK8zk/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> git-users+unsubscr...@googlegroups.com. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -Cheers -Arif -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
