If I setup a bare repo, and all developers track their changes, all is good .. but then one developer makes a bunch of changes that were not tracked and files are out of sync .. how do i tell GIT to revert back to the old file versions when everything was ok?
On Sat, Jun 29, 2013 at 8:15 AM, Ed Pataky <ed.pat...@gmail.com> wrote: > thank you very helpful > > i am seeing everywhere that a bare repo is the way to go for distributed > developers .. it seems to me we should essentially make a rule that you > make your changes and test locally if possible, then ftp them to the server > when ok ... once all done the next step is (i am choosing SourceTree Gui) > stage changes, commit and push .. > > My only question now is can developers have different set of files in > thier local repos? for example i use python and other developers use php, > and we all edit html as well...so in my repo i added only html and python > and in thiers i would tell them to add thier php ad the same html .. is > there any issue with this? i just do not want to download the entire > website directory contents because it is huge > > > On Saturday, June 29, 2013, aft wrote: > >> 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 ef-Cheers >> >> -Arif >> >> -- >> 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.
