Sun Aug 07, 2022 11:15 pm
Login Register Lost Password? Contact Us

Please Note: The HPCC Systems forums are moving to Stack Overflow. We invite you to post your questions on Stack Overflow utilizing the tag hpcc-ecl ( This legacy forum will be active and monitored during our transition to Stack Overflow but will become read only beginning September 1, 2022.

Expansion of the Git Hub Step-by-Step Instructions

A place for developers to ask questions about contributing to the open source code base

Fri Mar 29, 2013 3:35 pm Change Time Zone

Step 0 – Setup and Configuration
Git Hub has setup instructions on the page and instructions on creating your fork of a project repository, and your local clone of that fork on the page. We adopt the Git Hub recommendation and name the project repository upstream and the page supra explains how to configure the remote repository aliases.

It is very important to not introduce spurious differences, and so we have adopted some rules on white space, particularly the line endings, use of tab characters, and trailing white space. We provide a pre-commit script, and the developer should enable this script.

Step 1- Resynchronization of your repository
It is a good idea to bring your fork and local clone up to date with the main repository. The upstream alias points to remote main repository. You should be able to accomplish the re-synchronization with fast forward merges (simple file replacements). If you had previously diverged in a significant way, then you will need to perform more elaborate file merges. We also recommend that you push your local clone up to the Git Hub clone of your repository. We follow the Git Hub recommendation that the main development line has master as the branch name. We also create branches for release candidates, releases, and maintain stable as a branch that lags master but is considered to be stable code.

Step 2 – Branching
A branch should be a logical packaging or work that has a high degree of cohesion. We prefer contributors to use separate branches for each bug or feature.

Step 3 – Staging your changes
You will need to tell Git about your changes by using the rm and add sub-commands.

Step 4 – Committing your changes
We provide guidelines for commit messages on the ... guidelines page.

Step 5 – Rebase your repository
If enough time has passed between step 1 and when you are ready to make your changes available, you will need to re-synchronize your changes with the then current code base.

Step 6 – Push your changes up to your Git Hub clone.
You should consider pushing your changes up to your Git Hub clone on a regular basis during development just to provide a copy for safe keeping. Whether you have or not, after the rebase you will need to push your changes again.

Step 7 – Generate the Pull request
On on your repository page, you will see a pull request button at the top of the page. Use this to generate your pull request. This tells the maintainer that your changes are ready.

The wiki pages provide information on code reviews and how we integrate with Jira for issues tracking.
Site Admin
Site Admin
Posts: 209
Joined: Thu Jan 27, 2011 10:58 am

Wed Nov 27, 2013 2:14 pm Change Time Zone

I've been having problems with using git especially when I'm doing something none standard. I felt I needed to know more about how it works. I found the following web page that does a very good job of explaining how it works:

The explanation is fairly short and very understandable.
Posts: 260
Joined: Mon May 07, 2012 6:23 pm

Return to Contributors

Who is online

Users browsing this forum: No registered users and 1 guest