Note: When connecting to remote from Windows make sure
that the private key is loaded ok in pageant.
Tracking other DEV/Remote
Branches
On my local host I now have ‘master’ that is a clone of
DEV which is a clone of LIVE. However, I had created other branches on DEV and
they didn’t come down with the clone of DEV. These steps will track these and
other new DEV branches on the local host.
Run GIT gui from the
moodle folder
Select ‘Branch’ ->
‘Create’
Select ‘Match Tracking
Branch Name’
Select the one you want
to track
Click ‘create’
OR GIT bash over the repository:
Look at the local branches (this shows only local
branches):
$ git branch
Now look at all of the possible tracking branches:
$ git branch –a
Lets assume that this shows a ‘bugFixes’ branch that is
origin/bugFixes that isn’t in our local repository. We could take a look at it
(but not work on it) with:
$ git checkout
origin/bugFixes
To create a tracking branch and be able to work on it:
$ git checkout –b
bugFixes origin/bugFixes
Editing Local
We develop on our local machines and push up to dev to do
some final testing before it all goes live. As a side note I personally use
Eclipse to do my editing (and, while there is a GIT extension for Eclipse, I
don’t use it due to the performance issues when working with PHP). Another
developer uses NetBeans.
Firstly I check to see I am on the correct branch, let’s
assume I am working on ‘master’. Opening up the GIT gui over the GIT repo it
will tell you what branch is checked out. In GIT bash it will tell you which
branch you are on when you navigate to the folder where the GIT repo is.
Switching Branches
From the GIT bash:
$ git checkout
[branchname]
From the GUI
‘branch’
‘checkout’
Click on the branch name
and click checkout
Now I am on the correct branch I can edit the code in
Eclipse and test in my browser to localhost. Then I want to commit them to the
repo in my ‘master’ branch.
Staging and
Committing
Staging the files is adding them to the index, which is
telling GIT to add those to the next repo. (You can change files and not commit
them). All new files will also need to be ‘added’ to the repo.
GIT Bash:
Show all files that need adding or have been altered.
$ git status
Add new files/stage files:
$ git add [path/filename]
Add all new files/stage all files:
$ git add *
Commit the files with a message:
$ git commit –m”The
message to use”
GIT GUI:
Rescan changes
Stage Changes
Add a message in the
dialogue box to the right
Click commit
Testing on Dev (Pushing to
Remote)
When we are happy with our changes on our localhost we
push them to DEV to test. The first thing that is required is to fetch down the
branch in question from DEV to make sure that we are up to date.
GIT Bash:
$ git fetch [alias]
(usually origin)
$ git merge [branchname]
The first command with fetch the data from origin. The
second command will merge the currently
checked out branch with the one specified in branchname, in our case, its
origin/master. It will merge into the currently checked out branch. Use branch –a to see all available branches. Or, you can use:
$ git pull [alias]
This will do a fetch and a merge together.
GIT GUI:
‘Remote’ -> ‘Fetch
From’ -> ‘Origin’
Assuming it’s a success
‘Merge’ -> ‘local
Merge’ -> Select Tracking Branch
Click on the branch name
and select merge
Assuming that the merge went ok we can now push our
changes up to the DEV machine:
Pushing:
On Dev(The remote repo) we need to make sure that the
branch we are pushing to isn’t checked out, so checkout another branch, then:
GIT Bash:
$ git push origin master
Git Gui:
‘Remote’ ->
‘Push’
Then select origin and
Push
Then on DEV checkout the master branch and test.
Merging Branches and Conflicts
At some point you will want to merge branches, and, at
some point you will get conflicts when merging.
Merging
To merge into the currently checked out branch:
GIT Bash:
$ git merge [branchname]
Git Gui:
‘Merge’->’Local Merge’
Select the branch and click
merge
Conflicts
We normally merge our branches on the local windows
machines. This is purely out of laziness of either merging using the command
line over putty or firing up the VM every time to do it graphically on DEV.
To merge on Windows I use TortoiseGit and then just my
normal editor.
Assuming there have been conflicts and there are now
conflict markers in the code, I edit the code in Eclipse and then right
click on the file in windows explorer, click tortoisegit and then click
resolve. This lets me resolve the conflict.
Alternatively on the moodle folder itself I click ‘resolve’.
This then brings up a list of files (similar to above) that have conflicts.
Rick click on each file and ‘edit conflicts’. The new window that this brings
up lets you select the remote or local version to use. Or this window can be
used to copy, paste and edit the code to fix. Once edited/resolved click ‘edit’
-> mark as resolved. Once all files
have been resolved the changes can be committed.
Pushing Live
On dev logged in as the ‘git’ user we simply push up to
origin using the same as above (git gui or git bash) and it will fire off the
hooks. The only difference is that we don’t need to have another branch
checked out out on HUB as it doesn’t have a working repository.
Our solution conclusion
So, we have set up:
·
Local Development on Windows
·
Development Centos test server
·
Live server that hosts our website on Centos
We can:
·
Update a live website using GIT
·
Have multiple developers and branches.
There are a few rules that we use:
1. Each
developer commits to dev at least once a day
2. We
merge branches on Dev (mainly out of sheer convenience for us)
3. We
use descriptive and good comments
4. We
use tags to tag some of our commits.
We have branches for:
·
Master
·
Current live (if different from master)
·
Bug fixes (sometime one for each bug fix)
·
New Features (one for each)
No comments:
Post a Comment