Git workflow
Draft bitbucket/git workflow for CASTEP developers: NB: Not a git tutorial!
-
Bitbucket web - create fork (“myfork” for this example)
-
Make fork visible to CDG (bitbucket group, very least to dominik.jochym@stfc.ac.uk so that the CI works)
-
Clone to local machine
git clone git@bitbucket.org:mybitbucket/castep-myfork.git castep-myfork
-
Setup local githook (see readme in .githooks)
-
Configure remote “myfork” and “upstream”:
Can verify remotes with git remote -v (useful to have more remote aliases if you want to check out a branch on someone else’s fork) -
Name branch
git branch foo
-
Switch to branch
git switch foo
-
(Stage and) Commit changes
git commit -m “Cool stuff”
-
If planned destination branch (usually default) has changed:
-
Fetch from official
git fetch upstream default:default
[NB: reference to “upstream” might be different if your remote aliases are configured differently]. This not only performs the fetch but also updates the local "default" branch to sync with the upstream. -
Rebase using destination (default) branch
and then in your editor, leave the first line as 'pick ....' and then change all subsequent lines from 'pick ...' to 'squash ...'. Save the file and then you will get a squashed history for this PR.git rebase default
. This makes it so that your changes are sitting on top of the latest “official” default. If your branch contains many PRs it may be better to "squash", using the bitbucket merge option "squash merge", or -
Fix conflicts if needed
git mergetool tool=kdiff3
[kdiff3 is just my personal preference] and then:git rebase --continue
(and commit)
-
-
Push branch to fork (
git push myfork foo
) This is a very good habit to get used to: always specify the remote and branch so you know exactly what you’re trying to push and where! Synchronise your fork’s default branch with upstream:git push myfork default
-
Create pull request (bitbucket web, from fork) "Delete this branch after merge" should be checked in most cases. The exception is with long-term development branches and release branches.
-
If another PR is merged first, you have two choices:
-
-
Do NOT click “Sync now” on the PR page as this does a merge and commit, which breaks our --ffonly policy
-
At your local clone, go back to step 9
-
Similar to step 10, except this is a “force” push as the rebase has changed the commit history:
-
-
On the website interface, click "merge". Then change the merge strategy to "Squash". You will then get an opportunity to edit the commit message.
-
-
Switch back to the default branch
git switch default.
Do not do any further work on your foo branch and attempt any merging, or you risk creating a "spaghetti" of loops in the commit graph. You may re-use the name of your branch if you delete the old one withgit branch -D
.