I attended the ScotSoft 2016 conference way back in October 2016. I was asked to do a brief ten minute talk for the company that I work for monthly TechX event. The talk that I chose to discuss was Advanced Git and GitHub by Mike McQuaid. Mike works for GitHub and wrote a book called Git In Practice. I thought it might be useful if I also wrote down in a blog post what I spoke about at the TechX event.
So without any further ado, here it is:
Since joining the company I have used Git in a number of projects and for about a year and a half I have been GitLab Admin in our sector and a wee bit beyond. Using Git almost daily, you are just really using the commands clone, checkout, commit, push, pull, and occasionally branch. Being a GitLab Admin, I’m trying to improve my Git skills and learn more because when someone comes to you, you want to help in any way that you can and give them the correct information. I thought the ScotSoft talk might help.
Mike’s talk was fast paced and involved him going through a large number of commands explaining what they were and giving small examples of how to use them. I was interested in learning from someone that had advanced knowledge and eager to pick up any tips and tricks from an expert. For me there can be a wee bit of fear when dealing with the edge cases when merges go wrong, commits go missing, or you push the wrong branch.
Git Commands
The talk was based around GitHub but Mike had to explain the Git commands to do the GitHub chat. I can’t remember him going into too much detail about GitHub, maybe the occasional url or reference to GitHub GUI. I vaguely remember him referencing SourceTree first in the talk but could be mistaken.
A list of commands that I had in my notebook are:
gitk (Windows and Linux) and gitx (Mac).
gitk comes with git but gitx is a clone of gitk for the Mac (open source). It allows you to see commits and branches visually. Clicking on each line allows you to see the commit message and the details around the commit. Before I knew this existed I used SourceTree (other Git GUIs available) for this purpose because I like a visual representation of my commits and branches.
Blame
git blame displays the every single of line and tells you who changed it. I have only ever seen this within GitLab by clicking a button and seeing a visual representation rather than at the command line.
Bisect
Scan through history quickly.
If you have a bug and you know at what commit that bug didn’t exist, you could traverse through your commits checking and marking that commit as bad until you reach the good one.
Examples:
- git bisect start – kicks off the process by cleaning up any previous bisect operations.
- git bisect bad – would mark the current commit as bad and checkout the next commit.
- git bisect good – would mark the current commit as good.
- git bisect run ls <filename> – have some of testing of that code for bug on each commit and let “run” go through the commands until that test passes.
rerere
Reuse recorded resolution. It is not enabled by default. To enable you would type, “git config –global rerere.enabled true”
If you are finding yourself fixing the same merge conflict again and again, this command can look at the input files and git knows you have solved it before and used the resolved version of the file instead of the conflicted one.
The git merge command would print out an extra message detailing that it has done the action above but you would still need to commit in case you did not want to go ahead with the action for any reason.
Mike has never seen the command doing the wrong thing.
Config
Personally configure git
Examples:
- User details
- Aliases
Describe
Generate a version number based on tags. If you have a tag but have a one or more commits after the tag.
Example:
- · V1.0- n- sha1
Reflog
It is very hard to lose information that you have committed.
A history of the commits is kept in Git (for about 30 days), every action is recorded. It has to be on the same machine. Think of it like when a banking website records the places/actions you have performed on their site or the government records every website you have visited for a year.
git reflog – commits to the head pointer.
Rebase
Moves the parent of a branch.
If you create a branch from a tag but then realise that the branch should have been taken from a release branch instead of deleting the branch and creating a new branch from the release branch you can rebase with the release branch and move the parent commit over to release. Rebase will replay the commits and rewrite the history.
After a merge conflict, you will need to run git rebase –continue
-i: advanced version that allow you play about with commits. You can move commits, edit commit messages, squash to meld commits.
Filter branch
Let’s the git user rewrite the history. Goes through the entire history to find and remove a file. You would need to get other people to re-clone their repository.
Cherry pick
The command can be used to select a commit from another branch typically and adds it to the current or another branch.
Cherry
It can be used to view if the cherry pick has gone a bit wrong. The man pages say that it would find commits yet to be applied to the upstream (I take the upstream to mean remote branch).
Subversion (SVN) / Team Foundation Server (TFS)
Git SVN is part of Git
Talks to SVN repo, not just for migration, can be used for SVN repo clone, create branches, merge and submit back to subversion.
Clone the trunk of the SVN repository and you can use git locally creating branches and merging those branches back into the main trunk then pushed back into the subversion repository.
git-tfs is provides the same function as SVN but you will need to download from GitHub and configure. This wasn’t part of the talk but I thought it was worth mentioning while talking about the inbuilt Git SVN.
Housekeeping – commit messages
Like an email, first line subject, other lines body.
Conclusion
In conclusion, I found the talk to be fast paced and sometimes that led to him talk about something with you saying “Wait a minute, what?” and Mike had already moved onto a different command or discussion. As time did march on, Mike said at one point that he wasn’t going to cover some commands in any big detail but he designed his talks so that the listener could try these commands out and research them.
I did enjoy the talk and I now appreciate how difficult it is standing up in front of people trying to produce content. I had started a “TechX project” at home to showcase and understand some of commands during this talk. However, I don’t think it would have quite worked with the time and probably could not get a repository big enough to demonstrate all the commands.
What I got most from Mike’s talk is that there are the tools in Git that allow the user to recover and it removes ”the fear” when you are going to do something slightly advanced and out of your comfort zone.
A video of the same talk at Java One
The Inner Donkey Sanctuary 