GitHub - howto
Cheat sheet
Useful notes
- Git's ability to communicate with remote repositories (in your case, Bitbucket is the remote repository) is the foundation of every Git-based collaboration workflow.
- Git's collaboration model gives every developer their own copy of the repository, complete with its own local history and branch structure. Users typically need to share a series of commits rather than a single changeset. Instead of committing a changeset from a working copy to the central repository, Git lets you share entire branches between repositories.
- You manage connections with other repositories and publish local history by "pushing" branches to other repositories. You see what others have contributed by "pulling" branches into your local repository.
- Create a GitHub account
- Download GitHub console
- If you want the GUI, download it from here
You don't have to use fixed file locations on your harddrive, to initialise a file location that already has sources with git
- Open the git console and navigate to the location that you want manage with git
- Type git init - this will create the git database in that directory
- Type git add . - this will add all the files in the current directory and sub directories (recursively) the local git db, the files remain in staged state until committed
- Type git commit -m <some message in single quotes> - this move the files from the staged state to commited
- Type git push -u origin master
The files that have just been committed have not been pushed to the GitHub remote server so we need to do this
- Create a new repository or use an old one
- Type git remote add origin https://github.com/stream2stream/<repository name>.git - this will link the local directory to the remote GitHub
- Type git push -u origin master - this will pushed the committed the files to the remote GitHub
Git add
Git add does more than add files to the local repository, to moves modified from modified state to the staged state, once in the staged state, they still need to be committed using git commit. If you are sure the commit is definite, the execute a git push to push the committed changes up to git.
Git commit
Takes the staged snapshot and commits it to the project history. The changes are still only on your local system not on the origin server. To make the changes present on the origin server the changes must be pushed to the origin server.
Git push <git server> <project branch>
The git push command consists of the server id and the branch, so the typical command is git push origin master, where origin is the home server and master the main branch.
Git pull <options>
git pull --all
command to pull all the changes from Bitbucket. In more complex branching workflows, pulling and merging all changes might not be appropriate .
The git pull
command merges the file from your remote repository (origin) into your local repository with a single command.
Working with stuff that's NOT on a local computer
- Create a directory (anywhere of your choosing) on the local machine
- Use git clone <url to github repository>
- if you get a cloning or password error, enter the following command: git config --global core.askpass, then repeat step 2
- You don't have to use git fetch < branch>
- Read more at especially the paragraph headed Fetching and Pulling from Your Remotes
- Once the clone has completed you can edit the content as normal
Branches
Don't work of the master, work of branches, use git branch <branch name> to create a new branch. Then use git checkout <branch name> to switch to the branch. If you already have a branch in the git repo execute git pull to get all the latest version history from the repo, you can switch to the branch using git checkout <branch name>.
Sometimes you’ll need to keep information locked down. Branches will allow you to update your files and only share the information when you're ready.
Branches are most powerful when you're working in a team. You can work on your own part of a project from your own branch, pull updates from origin server, and then merge all your work into the main branch when it's ready.
A branch represents an independent line of development for your repository. Think of it as a brand-new working directory, staging area, and project history. Before you create any new branches, you automatically start out with the main branch (called master). For a visual example, this diagram shows the master branch and the other branch with a bug fix update.
Typical method of woking
Create a branch where you can add future plans for the work you are doing and that you aren't ready to commit. When you are ready to make those plans known to all, you can merge the changes into your origin server repository and then delete the no-longer-needed branch.
It's important to understand that branches are just pointers to commits. When you create a branch, all Git needs to do is create a new pointer—it doesn’t create a whole new set of files or folders. Before you begin, your repository looks like this:
To create a branch you use git branch <branch name>
For example git branch future-plans
if <branch name> does not yet exist on the local machine, it will be created. The command does not switch you to that branch (if you are using the command line you should notice that the branch mane hasn't changed), so your repository looks something like this:
The repository history remains unchanged. All you get is a new pointer to the current branch. To begin working on the new branch, you have to check out the branch you want to use using git checkout <branch>. For example git checkout future-plans.
The git checkout
command works hand-in-hand with git
branch . Because you are creating a branch to work on something new, every time you create a new branch (with git branch
), you want to make sure to check it out (with git checkout
) if you're going to use it. Now that you’ve checked out the new branch, your Git workflow looks something like this:
Once you make changes to any of the content in your project you must use git add and git commit to make the changes to the branch. Remember git add stages the changes and git commit commits the chages so they are now part of the history. Once the commit has taken place your repo will look like this
If you do a git status, you see a message to this effect
Merging
Once the ideas in a branch become a reality, you can merge that branch into the main branch on your local system.
If you created only one branch and made one change, you can use the fast-forward branch method to merge. You can do a fast-forward merge because you have a linear path from the current branch tip to the target branch. Instead of “actually” merging the branches, all Git has to do to integrate the histories is move (i.e., “fast-forward”) the current branch tip up to the target branch tip. This effectively combines the histories, since all of the commits reachable from the target branch are now available through the current one. So your workflow will look like this
This branch workflow is common for short-lived topic branches with smaller changes and are not as common for longer-running features.
Consider if you have a branch called future-plans that you have been working on and you ares still on that branch, you would need to perform the following steps
git checkout master - This will switch you back to the master branch, essentially you must first postion yourself into the branch that you are merging into
git merge future-plans - This will essentially moved the pointer for the master
branch forward to the current head and your repository looks something like the fast forward merge above.
If you no longer need the branch you can delete it using git branch -d <branch name>. A branch can still be accessed after it has been deleted using it's commit id.
A git status would give the following result
This is because you a branch that branch this is ahead of the master on origin, so a git push is required to sync things on origin. The diagram below shows the current status of the local and remote repository before and after a git push
Git push of changes in abranch
A git push of branch changes will make it possible for everyone else to see your branches changes. To do so, you can push the current state of your local repository to the origin server.
make sure you are in branch where you merged the working branch into (a git status will inform of the need to perorm a git push), then enter the command git push origin master