Some of the commonly asked questions encountered whilst running this course are addressed below, grouped into the main topics. If your question is not answered here please do not hesitate to ask the course leaders or helpers.
A quick fix to this is to visit the GitHub Email Settings and uncheck Block command line pushes that expose my email
. This is not ideal though as its exposes your email address. A better solution
in the long term (described in detail on
StackOverflow)
is to…
Keep my email address private
is
checked.{ID}+{username}@users.noreply.github.com
.git config --global user.email {ID}+{username}@users.noreply.github.com
replacing {ID}
and {username}
with
the values you copied from above, then hit Enter
.git commit --ammend --reset-author
.git push
at the Command Line Interface or using the Push
button in GitKraken
Client.You can but its complicated and there are many options available which will be contingent on what you want the commit history to reflect, although typically most leave the commit history in place and add a new commit documenting the changes.
You can git reset
to roll the HEAD
back to an earlier point (for more see How To Use Git
Reset) or you can git revert
to undo the changes introduced by a
specific commit (see How To Use Git Revert). Other options include
using git rm
to remove specific files from being tracked (How To Use Git
RM) and git rebase
to move and combine a series of commits (How Tow
Use Git Rebase).
It is possible to roll back a branch to any stage in the history of commits by using git checkout <hash_id>
but this
will mean you are in a Detached HEAD state as
you are not at the HEAD
of that branch. It is possible to reset which commit HEAD
points to but it is a destructive
process and can cause a lot of problems and is not therefore recommended.
If you have not committed changes locally and only staged them you can delete or change anything, it will just unstage the modified files and you can then stage and commit them again after making corrections.
No a push can include multiple commits.
stage -> commit
instead of having a direct commit
?It is so that we can choose which changes to which files we wish to push at a given point in time. You may have a project where you have modified 14 files on a branch you are working on but at this point in time half of those are still experimental and not ready to be pushed. You therefore only stage the 7 files that are ready to be pushed, leaving the others in place locally for inclusion in a later push.
Technically you can, but GitHub isn’t really designed for sharing large files. Further there may be data governance issues that cover sharing of your data. For more information on sharing your data see the Sharing research data - Research Data Management - The University Library - The University of Sheffield.
It depends on your perspective. When you have made changes to a fork and you wish them to be incorporated into the original repositories branch then from your point of view you are pushing, just as you do from local to GitHub.
From the perspective of the original maintainer they, as recipient, see it as “pulling” your changes into their branch. Given the original is their branch and you are adding to it then the owners perspective takes precedence, hence why its a request to “pull” your changes into their repository.
However, it’s best not to worry too much about it, a “pull request” is a way of merging a branch into another branch in a repository, and an opportunity to have a discussion about it before doing so.
You could but you may not always have permission to submit pull requests directly.
Also you should never make changes directly to a main
branch, you should always make them to a branch and then merge
that branch via a Pull Request. This helps protect the main
branch from errors creeping in as Pull Requests get
reviewed. This is what forking is doing, its making a branch from the main repository for you to work on.
Many large code bases have a number of GitHub Actions that carry out such tasks as unit, integration and regression tests, linting of code to ensure it complies to style guides, building and releasing packages. This, along with careful code review of Pull Requests, helps ensure that newly submitted code does not break software.
Not when making edits directly to a single file online via GitHub as typically you are only changing a single file so there is no need to choose which files to stage. However, rather than committing them directly to the branch you are working on you do have the option to create a branch and pull request for your changes.
LFS is Git Large File
Storage,
generally you should be storing large files such as data on GitHub, there are Data Governance issues that probably
prevent you from doing so, particularly if you are working with individual patient or survey data. For most of your work
you should exclude the files by listing their file extensions in .gitignore
(e.g. to exclude all CSV files add *.csv
to ignore R Data files add *.RData
).
There are methods of version controlling data such as Data Version Control.
The 7-day trial period only refers to a short window where you get all of the paid features that are available to try out. After this trial period expires you will still be able to use GitKraken and nothing in this course requires the paid features, for more information on the different features see GitKraken Client Pricing.
If you are using a trial version of GitKraken for this course you won’t encounter any problems. Longer term though you will want to setup a GitHub account using your University email address which allows you to take advantage of their GitHub Campus Program. If your account isn’t already registered then you can find instructions on how to do so at Apply for an educator or researcher discount - GitHub Docs.
Once you connect to this GitHub account through GitKraken you will automatically receive access to the full GitKraken Client Stand-Alone through their GitKraken Resources for Schools, which is contingent on your account being registered with GitHub Campus Program.
Yes Git and GitKraken are aware of what files are within the repository, and which files are being tracked and which aren’t and which files have changed since the last commit.
Yes it is perfectly fine and is a required for you to interact with GitHub from within GitKraken.
Git Bash is a part of Git for Windows and will work fine for you if you wish to work at the command line, but GitKraken includes its own version of Git and will work fine.
This is likely due to trying to use your own SSH keys with GitKraken. You should instead let GitKraken manage the SSH keys. Under File > Preferences > SSH ensure the Use local SSH agent box is ticked. This greys out the other options and should resolve the issue.
No, the focus of this course is using GitKraken to interact with Git and GitHub, however the Git
manual contains all the equivalent command line options. There is man git
as well and each command has its own help page accessible with git pull --help
, git checkout --help
(generally its
git <command> --help
). There are also a number of additional resources in the Links section below.