Forking, remotes and pull-requests
This might be just me, but I don’t contribute that much to open source, by far not as much as I really ought to. This leads to me every time I do end up contributing needing to remember how I update my fork from the original one.
In the end of the day, it is actually fairly easy. Git allows for several
remotes, IE sources to fetch changes from and/or (if you have the right permissions) to push to. The standard one, your local fork, is most often known as
origin, though you can change the origin if necessary (I think that’s a touch out of scope for this set of tips & tricks, however). So, without further ado, this is how you interact with the so-called
upstream (that name isn’t set in stone, but it’s fairly well-known).
# You can add more remotes by name and url git remote add upstream firstname.lastname@example.org:<original author>/<repository name>.git # Fetch changes from upstream, using fetch rather than pull to not merge in changes immediately git fetch upstream # Now that you’ve established that you want to merge in the changes git merge upstream/master
Now you can do all the changes you want in your own local repository, push them to your github repository, and create a new pull request to the upstream repository.
.gitignore and the big “whoops!”
I’ve been there (several times) and I’m not fully certain I believe you if you claim you haven’t. You forgot to initiate a
.gitignore file before your first commit, or you changed your mind on where something that should be ignored was stored, or you missed something in the pattern leading to your entire set of bower-components ending up being part of your repository. Did I mention whoops!?
Warning, following these instructions may lead to the loss of the files you are wanting to ignore, so keep a backup of them, or in some other way ensure that you will get them back!
Before you do anything, make sure you commit your changes, or they are likely to get lost too. You have been properly warned, so let’s see what needs to/can be done. Also, make sure you have fixed and commited your proper
.gitignore file before starting, or it’s going to be a tad inconvenient.
git rm -r --cached . # This recursively removes everything from the commits git add --all # adds/deletes files git commit -m "Working .gitignore" # commits, using the given message
And if you didn’t know, you can replace
. with a particular file, or a file pattern.
There are several places in the git workflow that you can attach shell scripts, so-called hooks. The full list can be found in
.git/hooks, where each available hook has a sample script named by the hook and the extension
.sample. Simply remove the extension and the hook will be active.
If you create your own script, you need to make sure it’s a valid shellscript, and that it has permission to be executed. I’ve been tripped up by it changing the line endings on me, so if there’s issues,
dos2unix is always very helpful.
The only hook I really use at the moment is
pre-commit, which runs right before the commit is finalized, meaning that if it fails, the commit will not go through. The one I use the most uses
grunt commit, which runs the linting and testing tasks, and the script also uses parts of the default script:
I intend to gather a few more of the hooks, once I understand what exactly they do, and how to fit them into my workflow the best.