Congratulations! You have been accepted into second phase of the interview process.
During this phase your skills as an individual will be tested according to the requirements
of the position.
All tasks will be demoed live after the submission date. We will contact you with the demo
date. Please contact in advance of you do not possess a laptop to demo with.
There are two main branches: master and develop. Each has a specific function: master stores the last release (including any hotfixes), and develop stores the most recent development work. The only times you may commit to master is if you are releasing a new version of the project, or if you are releasing a hotfix. The only time you may commit to develop is if you are completing a feature, or resolving an issue.
At various times there will also be temporary topic branches. These are for implementing a feature, or fixing an issue. They will be deleted, so they may have dirty commit histories.
The workflow also has two directions: upstream and downstream.
Upstream looks like this:
feature > develop > master
hotfix > master
It is used for getting new features into a release.
You must exclusively use git merge --squash downstream-branch-name for this
direction.
Downstream looks like this:
master > develop > feature
It is used for getting hotfixes and global changes into develop and the various feature branches, respectively. You must use git rebase for this direction, except if this would require merging a change more than once or twice. In that case, you may use git merge, since this will likely only happen to topic branches, and they will be deleted in any case.
This is for downstream development, then merging upstream. Replace branch names as necessary with correct downstream and upstream.
#!bash
# Clone repo.
git clone git@xxx:xxx/xxx.xxx
# Create feature branch.
git checkout -b my_new_feature
# Work and commit some stuff.
git commit
# Rebase to pull in changes. *Don't* merge.
git rebase develop
# Switch back to develop branch.
git checkout develop
# Now merge.
# Take note of --squash, it makes sure we don't have a lot of commits per feature.
git merge --squash my_new_feature
# Get rid of the branch, it's not needed anymore.
# But make sure you merged everything! Once it's gone, it's gone forever.
git branch -D my_new_feature
Some people say you only want to put feature branches on your local machine, i.e. they should be invisible to other contributors. I say that's silly because it's a nice backup to have. Therefore, make sure feature branches are tracking branches and not local ones.
This leads to a problem when you rebase a topic branch: git will ask you to merge
the origin version.
In that case it's totally fine to git push -f, overwriting the remote's commit
history.
These are topic branches and will be deleted, so it doesn't matter if we do bad
things to their commits.
