7,649
edits
Changes
Jump to navigation
Jump to search
1. #When adding a new feature or fixing a bug, ALWAYS check out a new feature branch from the master. NEVER checkout a feature branch from next (see below). The feature branch should be named user/feature_name.
2. #After feature development is complete merge your feature-branch into next.
3. #The next branch is intended for testing and confirming things do not break. So, after feature branches are merged into next and conflicts resolved, we merge into master. After this, you can end the feature branches if you want.
You can also use [https://www.sourcetreeapp.com/ SourceTree] which is a free GUI interface for git-client. This is installed on the RDP.
Like using git from CLI (see below), SourceTree constructs appropriate commands. But the good thing
is it automatically generates all error check/logging options with each command that are difficult
to recall from memory. To use SourceTree you should have basic understanding of git (like branches,commits etc).
no edit summary
Our aim is not to break things in the master branch. All commits on the master should work.
==Quick and dirty github tutorial==
You can also use [https://www.sourcetreeapp.com/ SourceTree] which is a free GUI interface for git-client. This is installed on the RDP.Like using git from CLI (see below), SourceTree constructs appropriate commands. But the good thing is it automatically generates all error check/logging options with each command that are difficult to recall from memory. To use SourceTree you should have basic understanding of git (like branches,commits etc).
*''Installing - '' Depending on your operating system you can install git in three different ways:
* to checkout code from remote repository, use the <code><big>git clone</big></code> command. This will create a local repository on your disk as well as download the source code of the project you wish to work on. Here's an example:
<div style="text-align: left; direction: ltr; margin-left: 5em;"><code><big>git clone http://128.42.44.182/codebase/Matcher.git</big></code></div>
* to update your repository to include others' work in your project use the <code><big>git pull</big></code> command. Its always a good practice to update your code before you commit to ensure that others' code doesn't break yours. Also, you cannot push to remote unless your local repository is up to date. If you commit on a stale local repository that is fine, just that this would mean you are likely to have more trouble merging your code with others later on thanks to all the conflicts that you'll face when you actually try to update your repository later. See example:
<div style="text-align: left; direction: ltr; margin-left: 5em;"><code><big>git pull <optional folder path></big></code></div>
* to commit your changes to your local repository use the <code><big>git commit</big></code> command. Committing your changes is an essential step whether you are adding/removing items from the repository or changing existing items. See example :
<div style="text-align: left; direction: ltr; margin-left: 5em;"><code><big>git commit -m "mandatory commit message"</big></code></div>
