In an Organization, the repositories are owned by the organization instead of the user who created them.
In stage one with Alison you created a new repository. 0:00 That repository is owned by your user. 0:04 In an organization like Acme Inc the repository should be 0:06 owned by the organization instead. 0:09 Let's start by creating a new repository in the organization, give it a little bit 0:11 of content, and give our developers team access to the new repository. 0:16 From the GitHub dashboard click the plus icon on the top right of the page, and 0:21 choose new repository. 0:25 This screen should look pretty familiar, but 0:28 we need to do something a little different. 0:30 Where you see your username you'll wanna choose your organization. 0:33 I'm going to choose kdaigle-inc. 0:36 Choosing kdaigle inc means the repository will be owned by the kdaigle inc 0:40 organization. 0:44 You can name the repository magnum opus. 0:45 Okay, let's make this repository public. 0:52 Public repositories are free, but you may want to use private for 0:55 any real code within your organization. 0:59 Next, click the check box that says initialize this repository with a readme. 1:01 This will give us a simple text based readme to start working with. 1:06 All right, click create repository. 1:10 There you go. 1:14 You have a brand new repository owned by your organization. 1:15 We have a really simple readme all set and ready to go. 1:19 At the moment only you can access the repository. 1:22 Let's give access to the developers team we created in the last video. 1:26 At the top of your repository click the settings tab. 1:30 This will bring us to settings specific to our repository. 1:33 On the left side bar click collaborators and teams. 1:37 At this point the screen will be pretty blank. 1:42 You just created the repository and 1:45 we haven't given anyone else in the organization access yet. 1:47 On this screen you have two options to give people access to the repository 1:50 using teams or using collaborators. 1:54 Like in the last video teams are great when you have a functional area, 1:57 skill set, or a project that you'd like to group people by. 2:01 Sometimes though you only wanna grant a single person access to the repository. 2:04 This is useful when you have a rare exception or you have someone outside your 2:09 organization that you'd like to give access to just this one repository. 2:13 This is when you'd use the collaborators feature. 2:17 For our repository since it's a product our whole team will be working on 2:20 we should give access to the developers team. 2:24 Click the add a team button, and then in the drop down 2:26 we'll select the developers team that we created in the previous video. 2:31 Now we'll need to choose the level of access the developers team should have to 2:36 this repository. 2:39 There are three permission levels. 2:41 Admin, write, and read. 2:43 Read means you can only read the code. 2:47 Write means that you can write the code as well as a few 2:50 other things in the repository like creating labels and milestones. 2:52 Finally admin means you can read, write, and 2:57 manage the settings in access like we're doing right now. 3:00 For the developers team write makes the most sense. 3:03 We want them to be able to make changes to the code, but 3:06 not allow them to give others access to the repository. 3:09 Let's go ahead and give them write access. 3:13 That's it. 3:16 Now we have an organization owned repository and 3:16 we've granted the developers team the ability to make changes to 3:19 the code >> In the next video we'll cover creating 3:22 a great poll request for code review within your organization. 3:25
You need to sign up for Treehouse in order to download course files.Sign up