|
Hi all, another git newbie here. I'm trying to plan an architecture for using git across a small team of web developers. I've worked with SVN before, but never set up a shared git repo. This is the environment I'm thinking of: Each developer has a LOCAL machine We all share an internal STAGING server Our web sites are hosting on a PRODUCTION server at our data center LOCAL machines have Apache, MySQL, git as well as whatever development tools the developers need STAGING has Apache, MySQL as well as Gitolite PRODUCTION is running Apache and MySQL, but not git(?). We have FTP access to this machine. This is how I see the workflow happening: When a new project starts development a team leader create a new git repo on STAGING The developers working on it pull it down to PRODUCTION and start working Developer can commit changes locally. At key times the will commit and then push their latest work (or a stable branch of it) to STAGING for others to view or pull down. Internal testing happens on STAGING Once the site is done and tested we run a process to push the site from STAGING to PRODUCTION If the client ever needs an update we follow the same procedure, and the final process just pushes the changed files from STAGING to PRODUCTION So my questions are: - Does the above make sense? Is it a fairly standard way to run a web shop or am I doing something strange. - Should I be running git on my PRODUCTION server as well and use that to push changes live? Or is this last step commonly done with FTP. - Are there tools that work with git that can FTP only the changed files from STAGING to PRODUCTION? - We use Eclipse as an IDE. I've played with eGit and it keeps complaining that I shouldn't have my .git repository inside my project directory. Am I doing something wrong? Is there a better tool that integrates with Eclipse? Or do people generally stick to the command line and shun the IDE tools. - Is Gitolite the best tool to share a repo like this? I started using Gitosis but then realised it's been abandoned. Thanks
|
# ? Sep 5, 2011 08:32 |
|
|
# ? Jun 8, 2024 09:02 |
|
RyanNotBrian posted:Hi all, another git newbie here. While I don't have a comment on the rest, I decided against hosting my own git repo's and just pay Github for private repo's. It acts as a backup, a centralized location, and a really nice online viewer all in one.
|
# ? Sep 5, 2011 15:56 |
|
RyanNotBrian posted:- Are there tools that work with git that can FTP only the changed files from STAGING to PRODUCTION? If you're rolling your own you can use git diff --name-only old..new to find out which files changed between commits old and new. However, a better solution is to have a PRODUCTION that you can access via ssh rather than ftp and use something like rsync, which automatically transfers only changed files.
|
# ? Sep 5, 2011 16:40 |
|
RyanNotBrian posted:So my questions are: I think you're unnecessarily conflating source control and deployment. I've heard of people doing things like this, pushing to repos on the web server, but I've never done it and it doesn't sound like a very good way to do it. Just set up one repo somewhere (ie a private github repo) and store your stuff there. Then let deploy tools (you're using Java, right? use whatever capistrano equivalent you prefer) do the deploying.
|
# ? Sep 5, 2011 17:37 |
|
Ziir posted:I just started using Git and I'm really not sure what I'm doing. Say I edit a file and want to commit the changes, if I type "git commit -m 'comments'" then it tells me that there were no changes to commit and suggests that I do "git add file" first and then commit. This doesn't make sense to me because I already added that file before, and I don't feel like I should have to re-add the file again just because I edited it. Plorkyeran posted:when actually writing code I almost exclusively use -am with a <5 word commit message then before pushing review each commit, squash and split like crazy, and add actual commit messages RyanNotBrian posted:(setting up shared git repo) Oh, and in that Git for Ages 4 and Up, he's using git-achievements to generates that achievement. I just installed it and it seems like fun. Here are my achievements. stray fucked around with this message at 18:51 on Sep 7, 2011 |
# ? Sep 5, 2011 22:59 |
|
stray posted:
Thanks for the advice folks. We currently have SVN repos on Assembla that work pretty well, the annual fee is not too bad. I wanted to move to an in-house server for a few reasons: - We are in Australia so big network operations take some time - We wanted a VCS that will integrate with our tickets in Redmine The network speed issue may not be an issue with git, as I understand there is much less traffic going back and forth after the initial clone. Has anyone had experience integrating either Github or Assembla repos with Redmine? edit: This looks interesting! http://eddieringle.com/easily-integrate-a-github-repository-with-redmine-using-the-github-hook-plugin/ RyanNotBrian fucked around with this message at 00:07 on Sep 6, 2011 |
# ? Sep 6, 2011 00:04 |
|
stray posted:When you do, let us know, because I want to make a note to never fork any of your code. You are trying to find a way to avoid one of Git's biggest and best features, while also ensuring that no one will ever be able to comprehend your commit history. I think you missed this part: Plorkyeran posted:then before pushing review each commit, squash and split like crazy, and add actual commit messages The commit history you see would be clean, well documented, precise changes.
|
# ? Sep 6, 2011 02:40 |
|
Plorkyeran posted:I've strongly considered trying to figure out a way to just autocommit every time I save a file so that I can completely forget about dicking around with source control while coding
|
# ? Sep 6, 2011 08:04 |
|
RyanNotBrian posted:Thanks for the advice folks. I can't speak to the redmine integration (I normally just keep everything issues, pull requests etc in Github). But as for network operations the only time git actually uses the network is when it actually needs to. A clone makes just that, a clone or mirror of the entire remote repo locally on your hard disk. Any commits you make will be made to that local repository. Then when you are ready, you push your changes to github, and then other people can pull them. Basically the only operations that actually hit the network are clone, pull (fetch technically), and push.
|
# ? Sep 6, 2011 12:38 |
|
Sailor_Spoon posted:I think you're unnecessarily conflating source control and deployment. I've heard of people doing things like this, pushing to repos on the web server, but I've never done it and it doesn't sound like a very good way to do it. As I understand it, it's a pretty common part of Continuous Integration setups. I know it's how Heroku does things. What part of the idea bothers you?
|
# ? Sep 6, 2011 21:05 |
|
Doc Hawkins posted:As I understand it, it's a pretty common part of Continuous Integration setups. I know it's how Heroku does things. For things like that, you typically have hooks on the remote repo to run the deploy. What RyanNotBrian is describing sounds too much like "to deploy, just ssh into the server and run 'svn up'", a pattern best avoided.
|
# ? Sep 6, 2011 21:26 |
|
Sailor_Spoon posted:For things like that, you typically have hooks on the remote repo to run the deploy. What RyanNotBrian is describing sounds too much like "to deploy, just ssh into the server and run 'svn up'", a pattern best avoided. You should mention that it should be avoided because having checkouts on your web server might give attackers access to your code repo.
|
# ? Sep 6, 2011 21:27 |
|
Is there a term for "having part of your repository be mirrored on a completely different repository?" Specifically, I have a SVN repo with a bunch of code. Part of this code also needs to live on a different respository. The users of that repository won't be making any changes or anything; they only need read access, and they only really need snapshots of milestones, not every little change. They can't just use the main one because there's no way to get them access to it (it's a different company). Is there a more elegant way to do this than "export and commit to the other repo at every milestone?"
|
# ? Sep 7, 2011 19:50 |
|
No idea what to call it, but if the milestones hit a specified branch (copies are cheap) then you could use svn synch to mirror that branch pretty easily.
|
# ? Sep 7, 2011 20:03 |
|
Mithaldu posted:You should mention that it should be avoided because having checkouts on your web server might give attackers access to your code repo. This is what a coworker said when I suggested a 'deploy' branch but I don't understand what's so hard about not having your server serve files out of .git or .svn directories. It's not that hard.
|
# ? Sep 7, 2011 20:22 |
|
Factor Mystic posted:This is what a coworker said when I suggested a 'deploy' branch but I don't understand what's so hard about not having your server serve files out of .git or .svn directories. It's not that hard. Yeah, but what if i exploit your image thumbnailer to permit me read access to arbitrary paths on your system? (Just as an example.)
|
# ? Sep 7, 2011 20:28 |
|
Mithaldu posted:Yeah, but what if i exploit your image thumbnailer to permit me read access to arbitrary paths on your system? (Just as an example.) If you can read arbitrary paths, you can already access the source code. There's nothing extra to read from having read-only access to the repository.
|
# ? Sep 8, 2011 01:18 |
|
He's saying arbitrary paths on the whole system. What about the password file?
|
# ? Sep 8, 2011 01:37 |
|
Janin posted:So what? You don't have much practical experience with system intrusion, do you? It gives me the urls of your source repo, which may be accessible on the internet, or at least proxied throught he server; as well as the login credentials, which may be read-only, but provide strong hints on how to brute-force the write creds; in either case, having read credentials at least gives me the whole history of the repo, as well as any other projects stored in there; and with git i don't even need any credentials because the history is right there; and who knows what nice extras like hastily reverted passwords the history contains... Try thinking about what someone with determination AND creativity could do. Leaving the security impact aside there's also the fact that a source checkout is not an atomic operation, the changes of it happen as git/svn/whatever touches the files, which, combined with ongoing user access can lead to interesting situations. In short: Just don't loving do it, for any possible point as to how you could make it feasible i can give you two counters and even if i run out, you'd still have a huge massive list of poo poo to look out for that you can just avoid by not doing it.
|
# ? Sep 8, 2011 01:37 |
|
Mithaldu posted:You don't have much practical experience with system intrusion, do you? There's no reason to expose a source repo on the internet. There's no reason to let the webserver have any sort of credentials (just git/bzr/hg push to it). There's no reason why passwords should be stored in the history (they should be changed immediately, and the relevant history expunged). Mithaldu posted:Try thinking about what someone with determination AND creativity could do. Mithaldu posted:Leaving the security impact aside there's also the fact that a source checkout is not an atomic operation, the changes of it happen as git/svn/whatever touches the files, which, combined with ongoing user access can lead to interesting situations.
|
# ? Sep 8, 2011 04:00 |
|
The idiots I work with and my own stupidity are more of a danger to our operations than most hackers I can think of. Deploying backed by source control is a much better way to fly than not for us. YMMV.
|
# ? Sep 8, 2011 05:45 |
|
wwb posted:The idiots I work with and my own stupidity are more of a danger to our operations than most hackers I can think of. Deploying backed by source control is a much better way to fly than not for us. YMMV. Well of course you should be "backed by source control", that's where the source is. Most of the projects I work on are set up to tag releases, so it's trivial to see what has been deployed where, and when. My point was really that deployment is usually more than just changing code. I've never personally worked on anything that was simple enough to deploy by updating a repo on the server. And if you think your project is, how much longer will that be true?
|
# ? Sep 8, 2011 05:55 |
|
Janin posted:Mithaldu posted:you'd still have a huge massive list of poo poo to look out for that you can just avoid by not doing it. So, at this point trying to convince you is pointless since your world view is already massively divorced from reality.
|
# ? Sep 8, 2011 10:15 |
|
Hey, guess what? Github actually will let you pay annually! I submitted a support request asking about annual payments and got this back in return:quote:From: XXXXXXXXXXXXX (Support staff)
|
# ? Sep 9, 2011 19:05 |
|
I'm looking for suggestions on what sort of source control I should be using and how I should set up my projects. I've worked with Subversion a fair bit (and Sourcesafe, but we don't talk about that), along with a few minutes with Git. I'd like to have one primary project where I do work meant to be shared between clients. I'd like to have many client projects that make use of the primary project for the most part. The client projects would each have some custom files though, some that may be intended to override the primary project's copy of the file, some that may not exist in the primary project at all. Can anyone suggest what would be the most appropriate source control system for this? I'm guessing most systems would be fine with it. How about how to set these projects up? With Subversion I'd consider setting the shared files in each client project as externals pointing at the primary project but this feels like it'd involve some suck where the externals would have to be configured manually for each client project. Is there a decent way to do what I'm looking for, ideally in a manner that would cause all client projects to automatically be updated with the newest versions of the shared files anytime I commit to the primary? I'm sure this update could be scripted in the end but it'd be nice if it were handled for me. Or, alternatively, can you tell me why my ideas are stupid and what I should be doing instead?
|
# ? Sep 21, 2011 22:11 |
|
Melraidin posted:I'm looking for suggestions on what sort of source control I should be using and how I should set up my projects. I've worked with Subversion a fair bit (and Sourcesafe, but we don't talk about that), along with a few minutes with Git. Use Git. There's a couple ways you could do this, depending on what you like. If each client project needs to be coupled with a specific version/branch of your primary project, then Git submodules is the obvious tool. This is probably the route you want to take if your projects are going to grow to a size where verification and testing become important. But if you're not going to bother with being rigorous, then you could just set up a repository for each client and one for the primary project and have your client project build systems refer to the external primary project. Then when you do a build, they will refer to whatever is in the primary project's working tree. There's probably others, but these came to mind immediately.
|
# ? Sep 21, 2011 23:50 |
|
I'm trying to set up a git repository on Assembla (assembla.com) and I'm having trouble making my first "push". I'm fairly ignorant of git but I've previously successfully pushed to a repository on github. I'm using git on Windows Vista. When I run git bash from the relevant directory and type "git push", I get: The authenticity of host 'git.assembla.com (64.250.188.42)' can't be established. RSA fingerprint is 31:06:...(omitted)...:07:e6. Are you sure you want to continue connecting (yes/no)? Entering "yes" is no good, it doesn't accept the passphrase. I know that this has something to do with SSH keys, but I can't figure out what might be wrong with mine. My git name and email on my local machine match up with the ones I've entered on Assembla, and I've tried generating a new SSH key and uploading the id_rsa.pub file to Assembla to no effect. A search turned up this forum thread: http://forum.assembla.com/forums/3/topics/2754 As far as I can tell none of the suggestions raised by the administrator in the final post apply. 1 and 2 shouldn't apply because this is a vanilla account on the site and I haven't changed any settings. 3, 4 and 5 I believe I have done. 6 I have done, although I deleted the line "GSSAPIAuthentication" because it generated an additional error message. Edit: I have found the cause after asking on Stack Overflow. The config file referenced my private key file when it should have referenced my public key file (or vice versa, I can't remember). Hammerite fucked around with this message at 19:14 on Sep 24, 2011 |
# ? Sep 23, 2011 15:35 |
|
Is there any way to set rules for how hunks returned by git-diff are determined? I have figured out how to change the hunk header text but I can't figure out how/if you can change the actual hunk generation. For example: code:
What I'm attempting to do is get a list of all functions within a file that were modified. Maybe there is an easier way.
|
# ? Sep 30, 2011 23:08 |
|
Abusing git's diff hunk header generation to figuring which functions were changed is a terrible idea, simply because git has no knowledge of the source language's syntax.
|
# ? Oct 1, 2011 00:53 |
|
Wasn't sure which question megathread to put this in; .NET, General or this one, I think it is more relevant to making source code public via version control so am going to ask it here. I have a .NET C# form project using git for version control which uses a web API to pull data from. At the moment it requires an API key which should remain private. I am also currently in the process of switching the authentication over to OAuth, but I will have the same problem with the consumer secret. The project source is public but I obviously need to include the API key/consumer secret somewhere. I would like the source to remain easy to compile without too much effort from anyone else, but also have the API key/Consumer secret hard coded into binary releases. If I put it in a config file to keep it out of the source I expose the key to anyone I give out the binary to. If I hard code it in, the binary is fine but anyone can look at the source and get it. My current line of thinking is to create a basic "template class" say "SecretTemplate" or something and also have a "Secret" class. The secret class is in the gitignore and I can put the key in. The "SecretTemplate" is an exact duplicate with instructions to rename it to "Secret" and fill in the details for compiling. The application will call the static Secret.Key or something when using the API. This seems like a rather hackish way to go about it but would allow me to work on it freely, compile it with ease for binary releases and be relatively simple for others to compile and use (assuming they get their own key/consumer secret). Thoughts?
|
# ? Oct 4, 2011 14:09 |
|
I use something like that template method you mentioned. Say my config file is named config.xml. I tell version control to ignore that file (because it's going to be different for my environment versus another developer's versus the production environment, etc) and I create (and version) a file config.xml.tmpl. It contains a line like: pre:SECREY_KEY=~~SECRET_KEY~~ At that point I usually write a script to inject/replace (via sed, or ant's replace task, etc) all the ~~BLAH~~ parts of config.xml, so I can clone, rename the config file, inject appropriate values, and deploy the project in one click. Not sure why you'd need a special class in your code... epswing fucked around with this message at 14:50 on Oct 4, 2011 |
# ? Oct 4, 2011 14:40 |
|
+1, this is essentially what I do for disqusssharp.
|
# ? Oct 4, 2011 14:48 |
|
When you distribute a binary your secret key will be viewable to the end user if it is stored in a config file, unless I'm missing something completely obvious (very likely). What stops someone from just opening up the XML file in a text editor and looking at your secret key?
|
# ? Oct 4, 2011 14:59 |
|
I finally got sick of dealing with SVN, so I'm forcing HG down the designers throats today. Wish me luck.
|
# ? Oct 4, 2011 15:19 |
|
I had two graphic designers at my side job using Git. It went remarkably well, actually. I was so proud when one of the designers asked me why there were divergent history and merges when it was just me (at the time) working on the website. (Hot fixes on the live server while working on larger features on a local machine.)
|
# ? Oct 4, 2011 17:05 |
|
Xik posted:When you distribute a binary your secret key will be viewable to the end user if it is stored in a config file, unless I'm missing something completely obvious (very likely). Oh, I see, this isn't a web-app (or other centralized program). Sorry, I didn't read closely enough. The api key is for some service your program uses? Why can't the end users get their own api key? Or if that's not feasible, you could host your own proxy service which always uses your api key to the actual service, and you provide each client with their own api key to your proxy service. Not saying these are great ideas, I don't know what your program does, nor what the api is even for. vvv E: Yeah, Xik, you can't "hide" your key in a binary, I forgot to mention. epswing fucked around with this message at 19:02 on Oct 4, 2011 |
# ? Oct 4, 2011 18:32 |
|
Xik posted:What stops someone from just opening up the XML file in a text editor and looking at your secret key? Nothing, which coincidentally is exactly what is stopping them from opening your .exe in ILSpy and looking at the value of YourApplication.Secret.ApiKey.
|
# ? Oct 4, 2011 18:52 |
|
Xik posted:When you distribute a binary your secret key will be viewable to the end user if it is stored in a config file, unless I'm missing something completely obvious (very likely). What stops someone from opening your compiled app in .NET Reflector and looking at the secret key? Go ahead, download it, open the EXE, see how easy it is to find.
|
# ? Oct 4, 2011 23:29 |
|
Lysidas posted:
Sweet, there is hope. Dilemma I'm facing is I can either teach them to merge or just have them work in the main integration branch. Any advices?
|
# ? Oct 5, 2011 00:41 |
|
|
# ? Jun 8, 2024 09:02 |
|
You guys are right, there is nothing stopping someone from using another piece of software to view the key within the binary. If someone really wants it they will get it I suppose. It's really not all that important in this particular case, but I thought that this would be such a common problem these days that the problem would have been "solved" somehow. Especially with the market being flooded with useless applications which use things like the twitter, facebook, flikr API etc....
|
# ? Oct 5, 2011 00:51 |