Posts for the month of October 2014

Git/Github Tutorial

GitHub is an open source version control system (VCS) called Git. Git is responsible for everything GitHub-related that happens locally on your computer.


Setting up Git in command line

  1. Download and install the latest version of Git
  2. On your computer, open the Terminal application.
  3. Tell Git your name so your commits will be properly labeled. Type everything after the $ here:
$ git config --global user.name "YOUR NAME"
  1. Tell Git the email address that will be associated with your Git commits. The email you specify should be the same one you used to sign up for GitHub
$ git config --global user.email "YOUR EMAIL ADDRESS"

Authenticating with GitHub from Git

When you connect to a GitHub repository from Git, you'll need to authenticate with GitHub using either HTTPS or SSH. To learn more.: https://help.github.com/articles/set-up-git#next-steps-authenticating-with-github-from-git


Fork a Repository

A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project. Most commonly, forks are used to either propose changes to someone else's project or to use someone else's project as a starting point for your own idea.

  • Propose changes to someone else's project → using forks to propose changes is for bug fixes. If the project owner likes your work, they might pull your fix into the original repository!
  • Use someone else's project as a starting point for your own idea → Use someone else's project as a starting point for your own idea. At the heart of open source is the idea that by sharing code, we can make better, more reliable software. In fact, when you create a repository on GitHub?, you have a choice of automatically including a license file, which determines how you want your project to be shared with others.

Forking a repository is a simple two-step process.

  1. On GitHub, navigate to the repository https://github.com/octocat/Spoon-Knife
  2. In the top-right corner of the page, click Fork.

That's it! Now, you have a fork of the original repository.


Keep your fork synced

You might fork a project in order to propose changes to the upstream, or original, repository. In this case, it's good practice to regularly sync your fork with the upstream repository. To do this, you'll need to use Git on the command line.

Create a local clone of your fork

Right now, you have a fork of the Spoon-Knife repository on GitHub, but you don't have the files in that repository on your computer. Let's create a clone of your fork locally on your computer.

  1. On GitHub, navigate to your fork of the Spoon-Knife repository.
  2. In the right sidebar of your fork's repository page, click to copy the clone URL for your fork. This will either be an HTTPS or SSH clone URL, depending on how you authenticate to GitHub.
  3. Open Terminal (for Mac and Linux users) or the command line (for Windows users).
  4. Type git clone, and then paste the URL you copied in Step 2. It will look like this, with your GitHub username instead of YOUR-USERNAME:
    $ git clone https://github.com/YOUR-USERNAME/Spoon-Knife
    
  5. Press Enter. Your local clone will be created.
    $ git clone https://github.com/YOUR-USERNAME/Spoon-Knife
    # Cloning into `Spoon-Knife`...
    # remote: Counting objects: 10, done.
    # remote: Compressing objects: 100% (8/8), done.
    # remove: Total 10 (delta 1), reused 10 (delta 1)
    # Unpacking objects: 100% (10/10), done.
    

Now, you have a local copy of your fork of the Spoon-Knife repository!

Configure Git to sync your fork with the original Spoon-Knife repository

When you fork a project in order to propose changes to the original repository, you can configure Git to pull changes from the original, or upstream, repository into the local clone of your fork.

  1. On GitHub, navigate to the octocat/Spoon-Knife repository.
  2. In the right sidebar of the repository page, click to copy the clone URL for the repository.
  3. Open Terminal (for Mac and Linux users) or the command line (for Windows users).
  4. Change directories to the location of the fork you cloned in Step 2: Create a local clone of your fork.

To go to your home directory, type just cd with no other text. To list the files and folders in your current directory, type ls. To go into one of your listed directories, type cd your_listed_directory. To go up one directory, type cd ...

  1. Type git remote -v and press Enter. You'll see the current configured remote repository for your fork.
    $ git remote -v
    # origin  https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
    # origin  https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)
    
  2. Type git remote add upstream, and then paste the URL you copied in Step 2 and press Enter. It will look like this:
    $ git remote add upstream https://github.com/octocat/Spoon-Knife.git
    
  3. To verify the new upstream repository you've specified for your fork, type $ $ git remote -v again. You should see the URL for your fork as origin, and the URL for the original repository as upstream.
    $ git remote -v
    # origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
    # origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)
    # upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch)
    # upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push)
    

Working with git/github

Local repository flow

Add and commit


You can register the changes by adding them to Index. For that, you must use:

$ git add <filename>
$ git add .

This is the first step in the work-flow. Then, to do a commit for this changes in local repository, you must use:

$ git commit -m "Commit message"

Now the file is included in the HEAD, but not yet in your remote repository.

Send changes to remote repository

Your changes are now in the HEAD of your local copy. To send this changes to your remote repository, you must execute:

$ git push 

Branches

The branches in Git are used to develop functionality isolated from each other. When you create a repository, the main branch by default is "master". The idea is create new branches during the development, and when you finish, you must merge them in the main branch.


Create a new branch

$ git branch feature_x

Change current branch

$ git checkout branch_name

Create a new branch named "feature_x" and change the current branch to the branch created

$ git checkout -b feature_x

Return to the main branch

$ git checkout master

Delete a branch

$ git branch -d branch_name

Keep in mind that, a new branch will not be available to others unless you upload (push) the branch to your remote repository

Update and merge

Update your local repository to the last version in remote repository

$ git pull

Merge a branch with active branch in your local repository.

$ git merge <branch>

In both cases Git will try merge automatically the changes. Unfortunately, it is not always possible and may cause conflicts. In this case, you are responsible of the merge those conflicts manually by editing the files shown by Git. After modification, you need to mark them with:

$ git add <filename>

You can review the changes before merging using:

$ git diff <source_branch> <target_branch> 

Tags

It's recommended create tags for each new released version of software.

Create a new tag named 1.0.0

$ git tag 1.0.0 1b2e1d63ff

1b2e1d63ff refers to the "commit id" (10 characters). You can get the commit id

$ git log

Also you can use less characters for the tag but it must be a unique value.

Push tags to git repo

$ git push --tags

Replace local changes

If you do something wrong, you can replace local changes using the command

$ git checkout -- <filename>

This command replaces the changes in your working directory with the latest content from HEAD. The changes that have been added to the Index, as well as new files, will remain unchanged. If you want reset the local repository to the original repository. Note that, all changes will be lost.

$ git fetch origin
$ git reset --hard origin/master

Working with git/github in ESGF

Installation of Egit

The last versions of Eclipse includes the EGit plugin in their default configuration and is not needed install it.

You can install it via the Eclipse installation manager. Start this manager via the Help → Install new Software menu entry.

URL:

http://download.eclipse.org/egit/updates

for more -> http://www.vogella.com/tutorials/EclipseGit/article.html#egitconfiguration

Import a Project

In eclipse go to File > Import...

  1. Select Git > Projects from Git. Then, select a repository source. In case of local projects select "Existing local repository". In this tutorial we will import a remote project, for import remote projects select "Clone URI".

  1. Select a wizard for import projects in a eclipse project. In this case select "Use the New Project wizard". Then select the appropriate project. RememberUncheck use default location and select the git directory in your file system.


Gitflow Workflow (Vincent Driessen workflow)

This workflow is Vincent Driessen branching model post it http://nvie.com/posts/a-succesful-git-branching-model. The "rules" Vincent states in his blog is an example of how git allows us to implement a workflow for our team.

Remember that this workflow presented here are an example of what’s possible—they are not hard-and-fast rules for using Git in the workplace. So, don't be afraid to adopt some aspects of a workflow and disregard others. The goal should always be to make Git work for you, not the other way around.

The Gitflow Workflow defines a strict branching model designed around the project release. While somewhat more complicated than other workflows.

This workflow doesn’t add any new concepts or commands beyond what’s required for the Feature Branch Workflow. Instead, it assigns very specific roles to different branches and defines how and when they should interact. In addition to feature branches, it uses individual branches for preparing, maintaining, and recording releases. Of course, you also get to leverage all the benefits of the Feature Branch Workflow: pull requests, isolated experiments, and more efficient collaboration.

The Gitflow Workflow still uses a central repository as the communication hub for all developers.

Historical Branches


Instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. It's also convenient to tag all commits in the master branch with a version number

The rest of this workflow revolves around the distinction between these two branches.

Feature Branches


Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. But, instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master.

Release Branches


Once develop has acquired enough features for a release (or a predetermined release date is approaching), you fork a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Once it's ready to ship, the release gets merged into master and tagged with a version number. In addition, it should be merged back into develop, which may have progressed since the release was initiated. Using a dedicated branch to prepare releases makes it possible for one team to polish the current release while another team continues working on features for the next release. It also creates well-defined phases of development (e.g., it‘s easy to say, “this week we’re preparing for version 4.0” and to actually see it in the structure of the repository).

Maintenance Branches


Maintenance or “hotfix” branches are used to quickly patch production releases. This is the only branch that should fork directly off of master. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch), and master should be tagged with an updated version number. Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow or waiting for the next release cycle. You can think of maintenance branches as ad hoc release branches that work directly with master.

More

GIT CHEAT SHEET https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf
Git Cheatsheet -an interaction from NDP Software http://ndpsoftware.com/git-cheatsheet.html
Visualizing Git Concepts with D3 http://onlywei.github.io/explain-git-with-d3/
Understanding the GitHub Flow - https://guides.github.com/introduction/flow/index.html

Links & References

https://help.github.com/
http://git-scm.com/book/
https://www.atlassian.com/es/git
http://rogerdudler.github.io/git-guide/index.es.html
http://nvie.com/posts/a-successful-git-branching-model/