-
Notifications
You must be signed in to change notification settings - Fork 13
about working with GitHub (glossary)
GitHub is one of the most used open source project hosting sites in the world, and it is using a distributed version control system called Git. This is different from the plain old VCS, as a result, brings its own terminology and workflows. So there are some conceptual barriers that you want to overcome to use git to its full capacity.
The decentralization makes git an excellent tool for coordinating collaborative editing. But if you are accustomed to collaboratively work on the same copy of a document simultaneously (e.g. Google Drive) the workflow might be confusing at first.
A good analogy would be a paper document collaboratively edited. Everyone gets a copy and a different color marker. After one editing process (e.g. from one editor on one paragraph) is done, the changes get merged into the original document and the others can see the changes and decide to 'sync up'. This is where the specialized terminology comes into play.
A repository contains a collection of documents, possibly in different instances of editing - your branches.
Forking a project on GitHub, the entire projects repository gets copied to your GitHub account, including the files and the change history. In general, the repository you fork is called upstream, your fork is origin. Forking allows you to make edits without disrupting anything others are working on. Also, the upstream is easily kept 'clean', and you can experiment uninhibited in your fork. Inviting contributions from out of the team is easy (see Pull request).
A branch is an instance of a repository, branched off the shared change history at a certain point. Usually, branching occurs to keep order and track of progress when working on different topics in the same repository.
If a branch is 'ripe', it can be merged into upstream. Facilitates 'access' control, as the right to accept a pull request lies usually only with the team. But as anyone can just fork, branch, change and request a pull (into upstream) this makes it easy to invite collaboration from outside of the team. The discussion board on a pull request is also a prolific environment for discussions.
To 'clone' a repository (or a fork thereof) from GitHub to your local machine. It is worth noting that you can also edit (and preview) files directly on GitHub - just make sure you are working on a branch/fork not to disrupt everyone's merge process.
To get your edits from your local machine to òrigin. This also means that your changes get visible for anyone looking at your repository unless you are operating a private repository.
Should often be done and with unambiguous, concise and informative commit messages. Builds the smallest entity in the revision history. Commit messages are visible in a plethora of views.