|
Anyone using gitolite to manage their git repository hosting? I've got a very simple setup where all users have full access to my repository there. And today one developer managed to do something stupid with their GUI git client and pushed a bunch of code into our master branch right before a deployment. That sucked badly. Now I need to lock it down so only one or two developers can push to the master branch. I'm having a terrible time figuring out gitolite's configuration syntax. Anyone had any experience with this?
|
# ? Mar 7, 2012 21:17 |
|
|
# ? May 30, 2024 12:59 |
|
Dromio posted:Anyone using gitolite to manage their git repository hosting? I've got a very simple setup where all users have full access to my repository there. Gitolite user here, far from an expert though. But here's an example of what I have set up: code:
1) Everyone [the "@all" magic word] has read [R], write [W], and destroy [+] access to the testing repository. 2) The other guy and I have RW+ access to the company repository. 3) However, when it comes to the master branch, I only have RW+ permissions; other guy can only read it. http://sitaramc.github.com/gitolite/conf.html isn't the easiest read but you'll find most of what you need there.
|
# ? Mar 7, 2012 22:21 |
|
Dromio posted:And today one developer managed to do something stupid with their GUI git client and pushed a bunch of code into our master branch right before a deployment.
|
# ? Mar 8, 2012 00:20 |
|
Mithaldu posted:Bullshit, that's not your dev being stupid. That's your devops being stupid and deploying from master instead of a dedicated release branch. Ok, so I'm the stupid "DevOps". And the way I build for deployment is I create a new branch off the current production code (master), merge in the branches we want to release, then deploy. After that I merge this deployment branch back into master so it is always up to date. So yeah, 'master' is the dedicated release branch. In fact we've renamed it to 'Production' here just to drive that point home. The only thing I think I should have done differently to prevent this is take a more carefully look at the master history when I started my latest deployment branch. How else can I do this better?
|
# ? Mar 8, 2012 02:17 |
|
Testing the result of merging several branches before pushing to production would be a good first step.
|
# ? Mar 8, 2012 02:19 |
|
That and humans don't deploy code to production. CI servers deploy code to production after the tests run.
|
# ? Mar 8, 2012 02:39 |
|
Dromio posted:How else can I do this better? Well, first off, step by step, what did happen here: Dromio posted:And today one developer managed to do something stupid with their GUI git client and pushed a bunch of code into our master branch right before a deployment. Dromio posted:I create a new branch off the current production code (master), merge in the branches we want to release, then deploy. Dromio posted:The only thing I think I should have done differently to prevent this is take a more carefully look at the master history when I started my latest deployment branch. Dromio posted:So yeah, 'master' is the dedicated release branch. In fact we've renamed it to 'Production' here just to drive that point home.
|
# ? Mar 8, 2012 12:50 |
|
Mithaldu posted:Bullshit, that's not your dev being stupid. That's your devops being stupid and deploying from master instead of a dedicated release branch. Depending on your setup, there's nothing wrong with pushing from master. GitHub does it, for instance. We do it as well, but our "master" is less of a typical mainline, and more of a deployment branch. The only branch that ever gets merged into master is development or a hotfix branch we branched from master. Nothing gets to master unless all tests pass on development, and our staging server always has the current state of the development environment. The second something gets on master, it gets pushed to production. It works fine for us, and branching off release branches would add a lot of complexity for literally zero benefit. enki42 fucked around with this message at 13:17 on Mar 8, 2012 |
# ? Mar 8, 2012 13:10 |
|
What does GitHub do when you do a merge pull request with conflicts? Does it help you solve them interactively, solve them by itself or stop you with an error message?
|
# ? Mar 8, 2012 17:12 |
|
ufarn posted:What does GitHub do when you do a merge pull request with conflicts? Does it help you solve them interactively, solve them by itself or stop you with an error message? It will tell you if the merge can happen without conflicts, and if it can't, it'll show you the commands to resolve the conflict on your local machine.
|
# ? Mar 8, 2012 17:38 |
|
Mithaldu posted:Well, first off, step by step, what did happen here: Whew... wasn't looking for all this. I know our process could use a bit of improvement, and that's not exactly what I was hoping to fix today. But since you asked, here goes: Basic Development/Deployment Process Our process is pretty simple. We have one "Production" branch which should ALWAYS be deployable. Developers create new branches from there to do their work. When the work is done they mark it "ready for QA" in our ticketing system. Our product manager comes to me and says "I'm thinking about rolling out tickets 1,2, and 3". I create a new branch off Production. I merge in the branches created by developers for tickets 1, 2, and 3. I push this as a "QA" branch back to origin. Unit tests are run. The build is deployed to a QA server where we look over things and make sure they look right. When we feel everything is good, I merge the QA branch back into Production. I run unit tests again. I deploy the result to our production server. I push Production back to origin so everyone who creates new branches will do so from the latest code base. We do not automate deployment to production because I haven't been able to find a way to copy files from our CI system (in the office) directly to the production system (at our hosting service) without human interaction (entering a password). I'm still working on that part, but for now I simply enter a single command on my machine and it builds, runs tests, prompts me for the password, then copies and deploys. I know it's not ideal and I promise I'll try to find a better way. Where *I* Went Wrong This release took more time. When I made sure my local copy of Production was up to date, some files had been changed since QA was built. This isn't too unusual-- our designer will often update some minor UI assets without going through QA. But this wasn't one of those times. Instead, it was code changes from another developer. I absolutely SHOULD have examined these changes before rolling out. I failed. I updated my local copy of Production, then merged in QA. I ran the automated tests (which passed), then deployed. What the Developer Did The developer doesn't/can't use CLI git for various reasons. He's finally settled on SmartGit. Apparently he set up a tracking branch in SmartGit wrong when creating a new branch to do some work. SmartGit was pushing his changes back to Production without his even knowing it. He was as surprised as I was when I told him he had put code directly into the Production branch. AND, he wasn't ready for this code to be shared, so he'd commented out the unit tests around this particular code so he could experiment. I've discouraged this practice, but he did it anyway. So when I ran my tests, all was green. So... We both made mistakes. I know that. He knows that. He doesn't WANT to be able to commit directly production, and has no real reason to. Which is why I asked about it. And hopefully Golbez's answer will do the trick.
|
# ? Mar 8, 2012 20:37 |
|
What do teams do to solve the problem of "Does Bill have changes he needs to check in?" We have people that aren't in this office (or just not in every day), and it'd be nice to be able to go to a website and see that Bill has 2 files he needs to check in and Tom has 3. I guess it'd depend on some sort of client-side program that checks for modified code on a users machine and reports back.
|
# ? Mar 14, 2012 14:29 |
|
Bob Morales posted:What do teams do to solve the problem of "Does Bill have changes he needs to check in?" This is not a problem that needs to be solved with software. Or even solved at all. How do you know what branch they have checked out/cloned, where it is checked out or any of that information? Just tell your developers to commit their poo poo.
|
# ? Mar 14, 2012 15:25 |
|
Maybe they are non-mergeable files? Whatever version control you are using might have features to indicate that these files are checked out by somebody, but we don't know what you are using.
|
# ? Mar 14, 2012 16:40 |
|
How I solve that problem is to set things up so any sort of deployment and such happens out of source control. If it aint checked in it don't exist. Personally I would also slap the piss out of Bill too.
|
# ? Mar 14, 2012 20:37 |
|
Okay, I have merged my branch with master and resolved all conflicts in my local repo, but can it really be true that I am 40+ commits ahead of origin, just because my other branch was that many commits ahead of my master branch? Final question before I press the `git push` trigger.
|
# ? Mar 15, 2012 13:00 |
|
Run this (assuming that 'master' is the right branch name):code:
Lysidas fucked around with this message at 15:43 on Mar 16, 2012 |
# ? Mar 15, 2012 16:01 |
|
Also, this doesn't exactly answer your question, ufarn, but one thing that we use to ensure that we aren't pushing unwanted changes to master, and just as a good way to review your code, is require that all changes to master are sent up as a pull request to GitHub. If you guys are using that, the diff view on a pull request really is excellent, and it lets you interactively add comments on certain line numbers and other nice things like that.
|
# ? Mar 15, 2012 16:11 |
|
Bob Morales posted:What do teams do to solve the problem of "Does Bill have changes he needs to check in?" we use jabber
|
# ? Mar 19, 2012 05:41 |
|
Bob Morales posted:What do teams do to solve the problem of "Does Bill have changes he needs to check in?" Perforce (or I suppose another well functioning, centralized SCM) handles all that by default. You can see at a glance if someone other than you has checked the file out, figure out who it is by clicking another tab, and even map out files (explicitly or by pattern match) to say "these files multiple people can check out and edit because their changes can be resolved, however these other files are first-come-first-served only because there's no meaningful way to merge conflicts in an excel spreadsheet so go find who has exclusive checkout on it and kick their rear end." I've got something like 400'ish devs crawling all over a mountain of spaghetti platform code plus an undefined number of contractors allowed to touch the encryption widgets or the video storefront legal boilerplate etc etc etc and it works okay (In as much as they get any training letting them know what it means that someone submitted a change before their change.) I'm also kicking around a concept to bundle up a developer workspace at the end of each cycle and "p4 shelve" to stash it on the server in a non-committed state. That way they can go home, hit the VPN, and grab the changes to keep working. Or just refresh their workspace back to point-in-time 5:30pm yesterday. Or get checked into rehab overnight and need someone else to take their code over first thing tomorrow morning.
|
# ? Mar 20, 2012 06:03 |
|
I have a question on VisualSVN. I use non-default repo structures, but I'm wanting to take advantage of using tags. As far as I can tell, without setting up with tags/trunks/branches, the ability of SVN/Tortoise to recognise a given folder as a "tags" folder, then the ability is lost. What I'm wondering is: Is it possible to tell SVN that a given folder is a "tags" folder (i.e. it's a folder not called "tags" but is recognised as a tags folder as far as SVN is concerned)? Branching and Tagging does work, but it's possible to change things (not that I do) in the Release folder, which is obviously not desirable. Can I tell SVN that my folder called "Release" is actually a "tags" type folder?
|
# ? Mar 29, 2012 16:41 |
|
SVN does not have any concept of a tag; it's purely convention. Even with the standard setup, you can freely commit to existing things in the tags directory.
|
# ? Mar 29, 2012 17:04 |
|
^^^this. We had some idiot contractor who did a whole 6 month dev cycle in a tagged folder.
|
# ? Mar 29, 2012 17:23 |
|
Plorkyeran posted:SVN does not have any concept of a tag; it's purely convention. Even with the standard setup, you can freely commit to existing things in the tags directory. Ah, it must be a Tortoise thing then. Setting up a folder in the Tags folder popped up with a message warning that the current path is in the tags (it isn't). I'll carry on as normal then, cheers
|
# ? Mar 29, 2012 19:12 |
|
For a personal repository here, I suddenly got myself a steaming pile of broken links. I can't find the targets of the links anywhere. Since this is just for me, I don't have another developer against which to compare. My backups don't seem to have them either. Is there anything else I can do to at least make git happy again? It looks like I've lost some of my history.
|
# ? Apr 1, 2012 16:29 |
|
Rocko Bonaparte posted:For a personal repository here, I suddenly got myself a steaming pile of broken links. I can't find the targets of the links anywhere. Since this is just for me, I don't have another developer against which to compare. My backups don't seem to have them either. Is there anything else I can do to at least make git happy again? It looks like I've lost some of my history. This such an incredibly vague description that i can't even begin to guess what you mean.
|
# ? Apr 1, 2012 17:23 |
|
Mithaldu posted:This such an incredibly vague description that i can't even begin to guess what you mean. Git won't let me do my normal operations against the repository right now due to various errors and error messages. When I run git fsck I get a pile of broken links. Say, tree abc's link to tree xyz is broken. I can do an ls-tree for abc but I can't ever do one for xyz. I have some backups and nothing has xyz. I have a few cases of that. I'm about to do some crazy code changes so I wanted source control available for reversion, but I'm at a good spot now. Since this is a personal repository, I'm tempted to init myself a fresh repository and just add the latest version of the current files. I am not sure I could do a push because of the broken links. Update: I ended up having to start over. I got a little help over at #git. Specifically, that I was pretty well screwed. This is kind of annoying so I'll share. I had a broken tree links where the source existed but the destination, as it was hashed, didn't exist in the database. With file objects I can rehash them and shut this up. The directories did still exist but had different hashes. One cannot use the object hashing command on directory trees. I tried to do mk-tree and got a different hash. From there, I couldn't figure out how to mend all links to that new hash. From what I could see given the circumstances, that didn't really matter. I'm now looking into more rigorous backup strategies. I have some online web storage that takes SSH, but they won't add git. Regardless, is there a way to use scp to at least mirror stuff? Rocko Bonaparte fucked around with this message at 14:21 on Apr 2, 2012 |
# ? Apr 1, 2012 19:30 |
|
BitBucket if you want private repositories or Github if you want to be public (or pay to be private). You can probably run your own Git server if you want but that's beyond my knowledge.
|
# ? Apr 2, 2012 14:57 |
|
Rocko Bonaparte posted:I'm now looking into more rigorous backup strategies. I have some online web storage that takes SSH, but they won't add git. Regardless, is there a way to use scp to at least mirror stuff? If you can SSH into a machine, you can install Git yourself. If you don't have root access, you can still install it into your home directory: code:
I strongly recommend that you just use Bitbucket or GitHub though.
|
# ? Apr 2, 2012 15:41 |
|
Lysidas posted:If you can SSH into a machine, you can install Git yourself. If you don't have root access, you can still install it into your home directory:
|
# ? Apr 3, 2012 04:36 |
|
Rocko Bonaparte posted:I'm now looking into more rigorous backup strategies. I have some online web storage that takes SSH, but they won't add git. Regardless, is there a way to use scp to at least mirror stuff? Github is pretty excellent. Furthermore, if you have ssh access to something, you can stick a repository on it even without the ability to install git on it - just mount it using sshfs and create a "local" repository on the remote drive. Failing that - since it's really a backup you're after, not a mirror - any dumb storage will do; just copy or archive your .git directory.
|
# ? Apr 3, 2012 05:53 |
|
We use git, nobody has been trained to use it. Due to the rear end-backwards way we work, we treat it like SVN. There is a main repository I have to pull changes from to keep my code up to date, then I push my changes back up when they are done. However, in order to have to code work on my machine I have to have unique configuration files which I must not commit or push back up. I have been keeping these file uncommitted. Whenever I have to update, I git stash my config files, git pull to get the latest updates then git stash apply to reset my config files. I have a problem now that whenever I run git stash apply I get quote:Auto-merging s/main.css I have fixed the conflicts in the file, run git add s/main.css and even committed it but every time I run git stash apply I still get the exact same conflict error over and over and the rest of the stash is never applied. I can't find anything in the git book, stackoverflow or Google about what I need to do.
|
# ? Apr 3, 2012 11:22 |
|
nexus6 posted:We use git, nobody has been trained to use it. is there any reason you're not putting those config files in .gitignore, or the repo exclude? it seems that would streamline your workflow quite a bit
|
# ? Apr 3, 2012 11:51 |
|
Or better yet fixing the app so it can choose the right environment so you don't have to fight this particular boogeyman.
|
# ? Apr 3, 2012 13:40 |
|
nexus6 posted:We use git, nobody has been trained to use it. This has me thinking now. We've just started adopting git on some of our two-man projects (moving from CVS on Sourceforge ), and we pretty much do the same thing. Each of us clones the repo, does some work, pushes changes back, pulls the other guys'... and it just feels wrong. We've run into some merging issues here and there but we weren't sure how much of that was our fault for not having the best workflow. We primarily develop in Eclipse so we're using Egit -- not sure how much that's adding to our problems. Can anyone recommend a good resource that just lays it out in simple terms, "here's the best way to set up your workflow for a small number of users working concurrently"? I don't need any of that dictator-model stuff -- both of us know what we're doing on the project and don't need to complicate things by adding access tiers. I've got the Pro Git book, but I'm looking for something that dumbs it down even more than that.
|
# ? Apr 3, 2012 13:46 |
|
I'm pretty partial to this model: http://nvie.com/posts/a-successful-git-branching-model/ Works good for teams of one or more.
|
# ? Apr 3, 2012 14:41 |
|
Flobbster posted:Can anyone recommend a good resource that just lays it out in simple terms, "here's the best way to set up your workflow for a small number of users working concurrently"? I don't need any of that dictator-model stuff -- both of us know what we're doing on the project and don't need to complicate things by adding access tiers. I use Github for everything and it works very well. We have an organization set up and that has our canonical repository. It only has one remote branch, master, and everything is built and deployed from it. No one ever pushes anything other than master to the canonical repository. I have a Github Post-Receive HTTP hook set up to hit our build server every time something is committed to the canonical master. If the build is good, it's deployed with capistrano. Makes for very efficient releases. Next, each of us have personal Github accounts and we fork the canonical repo to our personal accounts. This is where I'll push remote branches and don't have to be worried about messing things up. On my clone, I set up two remotes, one to the canonical repo and one to my fork. I can branch, do all of my work, push to my fork. I use capistrano for everything, so I need to stage my branch? Make sure it's pushed and do: code:
This works pretty well for a small team of 3, 4, 5 people. Team of 50? You'd have to have a lot of disciplined developers.
|
# ? Apr 3, 2012 15:01 |
|
ToxicFrog posted:Github is pretty excellent. Furthermore, if you have ssh access to something, you can stick a repository on it even without the ability to install git on it - just mount it using sshfs and create a "local" repository on the remote drive. I had actually tried this so maybe I have something else to ask about here. I'm working on Windows here, using Git Extensions. The closest I found to being able to mount sshfs is DokanSSHFS. For simple copy kind of operations it was working fine. However, I couldn't even init a repository with it. Something in the Git Bash with Git Extensions was also getting in the way; it was flipping around path separators and then not finding the path. I have no idea what the deal was there. I imagine you were thinking about mounting sshfs on Linux, but I'm wondering instead if there's a well-vetted method for doing the same on windows.
|
# ? Apr 3, 2012 15:13 |
|
Flobbster posted:This has me thinking now. We've just started adopting git on some of our two-man projects (moving from CVS on Sourceforge ), and we pretty much do the same thing. Each of us clones the repo, does some work, pushes changes back, pulls the other guys'... and it just feels wrong. We've run into some merging issues here and there but we weren't sure how much of that was our fault for not having the best workflow. Seems ok to me. Pull. Do work, commit. Repeat that step until you feel like pushing. Then pull & merge anything that changed while you were working, and push. Of cource, if you're one of those weirdos that insists on a linear history, then never mind.
|
# ? Apr 3, 2012 18:00 |
|
|
# ? May 30, 2024 12:59 |
|
A -ful git branching model.
|
# ? Apr 3, 2012 18:45 |