Topics: Telecommuting tips, Heartbleed tools, the end of crapware?, Git tutorials, free education, ideas into products, humanize numbers, better Datetimes, a Git GUI.
Projects, etc.
This blog post was written specifically for my co-workers at Washington State community and technical colleges, but I suspect will be useful to anyone getting started with Github, so I am posting it here. This post is Copyright (c) 2013, Bellevue College and the State of Washington.
Git
A software tool for managing source code. Typically referred to as an SCM (Source Control/Code Management) or VCS (Version Control System).
These systems allow multiple developers to work together on the same project/product. They write code at their workstation and then check in or commit those changes to a repository. Git is a distributed VCS – which means that there is not a single, centralized server that developers must check their changes into (although it can be configured to simulate that behavior). Instead, each developer has their own (usually local) repository. Repositories can then be linked with other (usually remote) repositories. Repositories that are linked can share checked-in changes with each other – merging those changes into a common whole.
Repository
The location where committed/checked-in source code is stored, shared from, etc. A repository typically contains the source code, commit/checkin history, etc. for only one project/product.
Github
A web-based service that provides hosting for (remote) Git repositories.
In addition to hosting Git repositories, Github also provides additional features like:
- A Wiki for each repository.
- A simple issue tracking (e.g. bug tracking) system for each repository.
- Various tools for forking/merging/etc. repositories.
So, to put it all together:
If you’re not already familiar with Git – or at least some other source control tool – I’d strongly recommend spending some time learning how it works, and how to integrate it into your own workflow, before adding Github to the mix. Source control and Git itself are far too large a topic to get into here, but the following are a number of resources Bellevue College has collected:
As previously mentioned, Github is an online service which provides public hosting of Git repositories. With your repository on Github it is easy for others to find your project, download your code and (hopefully) submit useful contributions. They can even fork your project to create a new offshoot. In addition to just hosting source code, Github provides some additional features that can be useful when collaborating with others.
Besides personal accounts Github also allows any user to create organizations. Organizations act much like accounts in that they can own repositories, but they do not have a login of their own. Instead, the person who first creates the organization becomes the first Member in a Team (similar to a role group) called “Owners”. Owners have full, administrative access to the organization. For example, they can create repositories and add new members – including adding members to the Owners Team.
While each college is free to set up their Github accounts in a manner that works best for them, I would recommend each person who is going to access Github create an account and then one of you create an organization for your college. You can see how we set up ours at https://github.com/BellevueCollege.
To create an organization:
To add or manage members of an organization edit that organization’s profile, click the Members tab on the left and then click the team management link. Here you can
Teams essentially provide the ability to define access groups that members can belong to. You can define the permissions (push, pull and/or administrative), members and repositories for each Team. I recommend setting at least two people from your college (3 or 4 would be ideal – so as to maintain a healthy Beer Truck Index) to be on the Owners Team for your organization and setting up another Team with Push & Pull access for granting trusted individuals the ability to make modifications directly to your code, should you so desire.
Once you are a member of an organization on Github, when creating a new repository you will have the option to create it with your account as the owner or one of the organizations you belong to. If you choose the organization as the owner the new repository will appear on the organization’s page and “belong” to that organization.
This means it will benefit from the Member and Team access that can be configured as outlined above.
As you navigate your way through Github, you might find the following information useful:
Github includes 3 different ways to monitor activity. To be honest, this is still an area I’m a little fuzzy on. But this is what I’ve been able fo figure out so far:
When viewing the profile page of another user you have the option to follow them by clicking the Follow button. I have not observed an particular notifications (e.g. via e-mail) from following another person, but they do show up in my following count and list. A lot of people have asked how to find other users and/or repositories. This is the primary way I do so – by following other people, seeing who they follow, etc.
When you Star a repository, this seems to have a similar effect as following a user. Starred repositories show up alongside the users you are following. I have no idea why Github felt the need to use different terminology.
If you click the Watch button for a repository, you will be presented with 3 options:
There is also a short description of each, but for completeness, I will include here that selecting Watching will cause you to receive notifications for all discussions that occur in the repository.
As we progress in our use of Git and Github, I will post additional articles on such topics as
In the meantime, I recommend the resources listed under the Getting started with Git section above.
The preceding post is Copyright (c) 2013, Bellevue College and the State of Washington. ]]>Working as a member of a software development team (as opposed to being the only programmer on a project) can have some subtle, but very important differences. I’d like to share with you some of the tips and advice I’ve come up with over the years to reduce headaches and frustration – both for me and my fellow team members:
NOTE: “Documenting” doesn’t need to be a formal process. An e-mail, IM or shared discussion area is fine. The important thing is that the information is recorded and shared.
NOTE: I do this even when nobody else is working on the project – because that might not be an accurate assumption. If the project is in the repository, anybody can make a change at any time.
Even if nobody else is going to be looking at your code, any experienced programmer will tell you that in a couple of months you won’t be able to recall what you were thinking either.
All this can seem like a lot to do in the moment. It can feel like you don’t have time. Establishing a routine can help. Decide on a few things you are going to do every morning, before you start coding, or first thing when you get back from lunch. This can also help you get into the right frame of mind for getting back to work.
]]>