-
The
master
branch is the stable main branch. No one should ever need to edit themaster
branch, and even if they do, they should definitely never push it to the Github repository. All changes tomaster
will come as merges from other branches, which Lee will be responsible for merging withmaster
. -
Branches are easy and cheap to create, and should be used extensively. If you ever want to "try something out", make sure you branch from
master
(or some other branch) first. If you want to add a feature to a project permanently, create a branch for it while you test it, and once the bugs are ironed out, then it can be merged tomaster
(by Lee or whoever is managing the project). If you find a bug inmaster
, create a branch to fix it. If you want to add some code for an experiment for a paper, create a branch for it. I cannot emphasize enough: things will be easier for all of us if we always create branches for any changes tomaster
that we need. -
Whenever Lee updates
master
by merging in a branch, everyone else will need to download that change and merge it manually into all branches that may eventually contribute tomaster
. For example, if you have branchesnew_feature
,bug_fix
, andcrazy_thing_that_will_never_be_added_to_the_project
, you should definitely merge a newmaster
branch intonew_feature
andbug_fix
, since these will likely end up in the project someday. It's probably fine not to merge it into the third branch, since it will likely never leave your repository, but unless it breaks things, might still be a good idea.
Do this if you want to create a new feature for a CI Lab project.
-
Create a new branch from
master
to implement and test the feature.$ git checkout master $ git branch new_feature $ git checkout new_feature
-
Make your changes to the code.
-
Commit those changes in one or more commits.
$ git add [filename(s)] OR $ git add . $ git commit
-
Push your branch to Github.
$ git push origin new_feature
-
Tell Lee about the new branch, either by email, or by a pull request.
Every time that Lee makes changes to master
, we will all need to merge them into any open branches that we have in our local repositories.
-
Lee tells us that
master
has changed. -
Fetch the changes to
master
from Github.$ git fetch origin
-
Merge the changes into your
master
branch; this should not have merge conflicts.$ git checkout master $ git merge origin/master
-
For any local branch
my_branch
that may eventually end up in the project: -
Merge the changes into
my_branch
; this may have merge conflicts.$ git checkout my_branch $ git merge origin/master
-
If there are merge conflicts, resolve them and commit.
$ (edit conflicting files) $ git add [filename(s)] $ git commit
For Lee to integrate code into master
, whether from one of his branches or one of ours, he will need to merge that branch into master
. He should only do this for code that he wants to be included in the main branch of the project, which is the body of code that everyone will have in common, and will be used by people outside our lab.
-
Let's call the branch to be merged
feature_branch
. -
If
feature_branch
is Lee's creation, skip the next step. -
Fetch the branch from the Github repository.
$ git fetch origin
-
Create local branch
temp
to inspect and test changes.$ git branch temp origin/feature_branch $ git checkout temp $ (test and look at code. to look at difference from master: $git diff master)
-
Make any necessary changes to the code and update the version number.
$ (make changes) $ (update version number in project.clj to "A.B.C") $ git add [filename(s)] OR $git add . OR $git add -u (the last one also removes deleted files from the repository) $ git commit
-
Checkout
master
and merge in the new branch, and then deletetemp
. This should not have conflicts; if it does, the contributor did not merge in previous changes tomaster
, and they should do so before doing this.$ git checkout master $ git merge temp $ git branch -d temp
-
Tag this commit with the new version number.
$ git tag -a vA.B.C -m 'Version message here'
-
Push the new
master
branch to Github, as well as your tags.$ git push origin master $ git push origin --tags
-
Lee now tells the lab to fetch this
master
branch to merge it with their branches. -
Merge
master
with all your branches, includingworking
. See "Merge in Changes from master" section above. -
feature_branch
can now be deleted; to delete the branch on the Github repository:$ git push origin :feature_branch
-
Checkout whatever branch you're working on.
$ git checkout working