6 min

GitHub info for newbies

And Git in general.


[X] http://rogerdudler.github.io/git-guide

After creating new repository through the Web browser at GitHub, do the following at the command prompt on local machine to create a new repository on the command line.

mkdir new-repo-dir
cd new-repo-dir
echo "# Waxwing" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/username/repo.git
git push -u origin master

--> if receive error: "git fatal 'origin' does not appear to be a git repository" then 'git -v remote' will probably show nothing, so execute: git remote set-url origin ssh://git@github.com/username/newRepoName.git
Then 'git -v remote' should show the fetch and push URLs for the new repository. Then execute 'git push -u origin master'


Then ...

You can add files using:
- git add
- git add README
- git add <folder>/*
- git add *

To commit files, use:
- git commit -m "<Message>"

Finally, to push files:
- git push -u origin master

other commands:
- git status
- git pull origin master (to ensure you have absorbed any upstream changes)
- git fetch (to fetch changes)
- get merge (to merge changes)
- get pull (combination of fetch and merge)

remove file
rm the files from the local drive. then do:

- git add --all *
- git commit -m "remove backup files"
- git push -u origin master

another way ...
git rm file1.txt
git commit -m "remove file1.txt"
git push -u origin master

Remove a directory

  • git rm -r doc
  • git commit -m "removed doc dir"
  • git push -u origin master


Markdown Format Text


# This is an <h1> tag
## This is an <h2> tag
###### This is an <h6> tag

Text styles

*This text will be italic*
_This will also be italic_

**This text will be bold**
__This will also be bold__

*You **can** combine them*


* Item 1
* Item 2
  * Item 2a
  * Item 2b

1. Item 1
2. Item 2
3. Item 3
   * Item 3a
   * Item 3b



![GitHub Logo](/images/logo.png)
Format: ![Alt Text](url)


http://github.com - automatic!


As Kanye West said:

> We're living the future so
> the present is our past.

GitHub Flavored Markdown

Syntax highlighting with GFM
function fancyAlert(arg) {
  if(arg) {

Task Lists
- [ ] a task list item
- [ ] list syntax required
- [ ] normal **formatting**,
      @mentions, # 1234 refs
- [ ] incomplete
- [x] completed

Using Git



To checkout (or clone) the BioPerl core package (most people only want the core package) from GitHub, use:
$ git clone git://github.com/bioperl/bioperl-live.git
Alternatively, you can checkout (or clone) a specific BioPerl package such as bioperl-db (assuming you know what you are doing):
$ git clone git://github.com/bioperl/bioperl-db.git

By default, after 'cloning' (above), your checkout is on the BioPerl 'master' development branch. Git makes it easy to switch to a release tag or branch. For more information on these version control concepts see the repositories and branches section of the Git user's manual.

To list tags and branches, use:
$ git tag -l
$ git branch -r
To checkout a release tag or branch (for example), use:
$ git checkout bioperl-release-1-6-1 # tag
$ git checkout origin/release-1-6-2 # branch
To pull all the latest updates into your local repository, hit:
$ git pull

It is recommended to run this command every time you start to work on code (or if you know there has been a bug fix).

The preferred procedure for most developers to contribute changes to BioPerl is to fork the project on GitHub, make changes, and then send a pull request on GitHub to the main BioPerl project describing the changes.

GitHub itself has excellent documentation on forking and pull requests, see:



This is — by far — my favorite aspect of working at GitHub. Everything is asynchronous.

GitHub didn't have an office for the first two years. Chat rooms (in our case, Campfire ) is where things got done. Today we've moved into our second office, and Campfire is still where we get things done. There's a reason for that: chat is asynchronous.

The majority of our development workflow involves Pull Requests. I'm going to be going into a lot more detail about this in future blog posts and talks but in the meantime let me say this: living in a pull request world is sublime. Gone are days at companies with complicated branching strategies, with in-person code-on-a-screen code review.

If I want to add a new feature or impact the codebase, I'll push a new branch, create a Pull Request for it, and my coworkers will review it 1) if they're impacted by those changes, 2) interested in the subject, or 3) when they have ample time to check out my changes. At that point, we can run a partial deploy of that branch on different subsets of machines and try things out in production, and if everything looks good, merge into master.

With Pull Requests, I don't have to drag anyone into a meeting that's inconvenient for them and for me. There's a good reason for that, too:

37signals originated "meetings are toxic" in Getting Real. I tend to loathe meetings even more than 37signals. I despise them.

Meetings are usually called when you need to hash something out. They tend to invite more people than necessary, and even if you're pretty interested in the meeting topic, you're still going to be frustrated because meetings pull you from doing actual work in order to talk about doing work. It's easier to push a branch up, check out the diff, and then iterate on that diff rather than assuming you're going to perfectly whiteboard system design ahead of time.

Beyond that, meetings are utterly forgettable. Even if you take meeting notes, you can't capture them all. You make a judgement at that point in time as to what to write down for later. Then three weeks later you try to remember what wasn't written down when it becomes apparent that that discussion was more important. You don't have this problem with chat transcripts. Forcing people to reduce their otherwise rambling thoughts into concrete sentences helps focus discussion, too.

Deleting a repository


Renaming a username

Aug 6, 2017 :

changed a github username from boghop to sawv. currently, it only contains one repo, which is the boghop.com version of my wren setup.

but i'm going to make sawv. org my main site, at least until i change my mind again, probably in a year or so to use junco.me.

anyway, for indieauth login stuff, i'll make github.com/sawv my rel=me account. and i'll store the sawv.org version of wren at that github account too, which will start off as the boghop.com version.

boghop is hosted at aws. sawv. org will be hosted at do.

for the boghop.com repo, i use git from the aws server while everything else operates from my linux desktop.

i'll probably manage the sawv.org version of git from the linux desktop too.



From JR's : articles
1212 words - 8289 chars - 6 min read
created on
updated on
import date 2013-08-12 21:50:19 - #
source - versions - backlinks

Related articles
Content creation at GitHub - Sep 07, 2014
GitHub system for writers - Oct 27, 2013
Using the Internet for fun and profit - Mar 03, 2014
Stop using e-mail as a collaboration and knowledge management tool - Oct 29, 2013
Mercurial source control management - Oct 08, 2013
more >>

A     A     A     A     A

© 2013-2017 JotHut - Online notebook

current date: Jun 14, 2024 - 4:08 a.m. EDT