Hi, I'm Jason McCreary. I go by JMac.
I'm a full stack and iOS developer who likes building products and services. Recently this includes services like Laravel Shift and Getting Git.
I've been programming for 20 years. I'm very passionate about what I do and lately I've been on a mission to empower developers to master Git. So I'm glad to answer any and all of your Git questions (or anything else).
My AMA will start at 2PM ET today, September 13th, so please feel free to Ask Me Anything!
Top comments (103)
Hi Jason, thanks so much for sharing your knowledge! I was wondering - how do you feel about interacting with git via the command line versus a gui like Github Desktop/GitKraken/etc? Do you prefer one or the other personally?
Command line all the way!
I love using
git add -pever since @maestromac told me about it, but I find myself using Atom's Git integration to pick out a few lines of changes I needed to discard. Also, their merge conflict handling is extremely easy to use.
Haven't touched their GitHub integration at all though.
Do you see any use of GUIs? I personally find I benefit from the visual component when I want to verify changes to avoid mistakes. While you can do this on the command line, I much prefer a visual tool.
Does this fall in the category of evil wizards?
I think if it's a tool that helps you do something more efficiently, then great.
I'll use a visual tool for diffs or complex tree visualizations. But really that tool is just GitHub.
It's when you're using a tool to do something you can't do on your own, then it falls into the category of evil wizards.
I have been suggested to stay away from ‘rebase’ by one of reputed software consultant who has GDE certification and authored several pluralsight courses. What is your take on that comment? I know I’m being very generic without including any scenario or examples. However is there any example situation in which you would recommend not to use rebase?
The reason people shy away from
rebaseis because it rewrites history - meaning it changes the commit SHAs. So if you're sharing your work with others, that can be a problem.
It's likely this consultant was the victim of a force push and made a sweeping statement to never use
rebaseagain. We've all been there. It's frustrating.
Being mindful of which commands, like
rebase, can rewrite history resolves this issue. Then you can use it appropriately. For example, I use
rebaseoften. But I do so at the end - right before merging - so I limit the chance for it to affect other developers.
What are you trying to learn next, as it relates to git?
I want to learn more of the options for
log. There are so many and virtually infinite combinations. These can be useful reporting on all sorts of thing in your code - not just recent commits.
I'm also interested in finding workflow alternatives to Git Flow that solve the requirement of scheduled release timelines.
What is your take on Continuous Integration and Feature Branches? Do you think Feature Branches inhibit CI?
I haven't experienced any issues where feature branches inhibit CI. However, I can envision it becoming complicated at scale. That is testing multiple feature branches in isolation would require many environments.
Typically I work quickly. So I don't build individual feature branches. They go through code review and testing before being merged into
master. Then they are deployed.
I have worked on teams that build sets of features. Normally their CI job has the ability to easily switch the source branch.
IRT CI and multiple envs to test feature branches, isnt there a way to segment an existing env to host a particular feature and then using existent LLs compare the results thusly? understand if this would be marked OT.
While Git is the tool I use every day, I feel that I'm using less than 30% of Git's full functionality. What is the best way for me to get acquainted with the rest of Git's features?
This really depends on your workflow. For example, if you're a solo developer, not sharing your work, you have no need to use commands like
In the end, you have to push yourself to use Git. For example, if you find yourself throwing away work or spiking out ideas, use feature branches.
Personally, I've adopted a workflow of using
git add -p+
git reset --hard. There's no reason I need to use these commands. I could just as easily use Cmd + Z. But I find it's faster with Git. I write all my code, add what I want with
git add -p(leaving out what I don't want). I make the commit, then discard what's left with
git reset --hard.
I would advice against "you have no need to use commands like push". The push command is your backup.. :)
You misunderstood. Please read the full comment for context.
Magit in emacs is a pretty good way to learn of other gut options and parameters.
Would you recommend a shop that is using the TFS Version Control System to switch to a TFS git repo? And if so, how would you make the argument? Keep in mind nearly all that would end up using it are unfamiliar with git so they would not have expertise.
I've done this on a few C# projects. From my understanding, there's little change on the surface. Previous TFS users can continue working via the IDE and users with Git now have the power to use other tools, like the command line.
So, my argument would be it's the best of both worlds - virtual no change for most users, but allows others to have an eye to the future.
I recently undertook this at our company. Admittedly, there's only 2 of us, which simplified things.
I would suggest that the basics of git are very easy to grasp. It's not hard to transition from another VCS if all you currently do is basic push/pull and the occasional branch/merge. IDE integrations make it so that you never have to touch the command-line (for the first little while anyway)
The combination of having a personal copy of the repo, and inexpensive branching really make git a joy to work with and enable stress-free experimentation.
Also, git is a first-class citizen in TFS/VS (maybe even more than TFSVC at this point) so there are no concerns there.
Thanks for the response!
I definitely agree about TFS and git becoming a first class citizen for MS now. Part of my reasoning is that it seems like MS is moving away from TFSVC so it may be inevitable that we'll need to do the switch.
I long for the local commits and easy branching. I use git for everything I do at home/github so it'll be less of a jump for me. I'm just not always great at making a case for these kinds of things at work.
I've been programming since around 1980 but generally on my own, either as the sole dev or mostly on my personal projects. Make files back in the day and RCS for the past 20 years so I have some familiarity with revision control. I've had a difficult time finding a git book that is helpful for someone like me who is familiar with RC but doesn't work with a team so haven't experienced the problems teams experience. The books seem to come from a more team and professional development environment than what I do. As a Systems Engineer, I'm working on DevOps methods which means becoming involved in the dev side of the house and CI/CD.
To the question, do you have a suggested book for someone like me? That I can take my RC experience and use it to leverage learning and using git.
It sounds like your challenge isn't so much learning Git, but leveraging some of its shared aspects. For that, I would recommend finding an open source project on GitHub and try to contribute to it. This will give you the chance to use commands beyond
For resource recommendations, see my previous comment.
That is possible. I've picked up some of the basics from one book (Jump Start git); setting up a repo, pushing the code, and cloning. I have a pretty extensive dev type environment using scripts and rsync to be able to sync updates from my dev server to the production servers. I was trying to take my manual, and a little hacky, process and use git, gitlab, and jenkins to automate the process. The branching and team aspect is what's new to me and where I'm stuck a little. Working on this will help me be familiar with CI/CD and the development to QA to prodlab to production path.
I appreciate the link to the video site. I have a subscription to Safari Online Bookshelf. Perhaps the videos are there already :)
What's the most common mistake people make when using git?
What's one thing everyone should make use of with regard to git, but (almost) no one does?
Often when things go wrong, we resort to deleting our local copy and recloning the repo. This is going to happen in the beginning, especially when we just need to get something done.
I think this is a mistake. That is you need to learn what went wrong. If nothing else, look at your command history and try to replay them to recreate the issue and determine what went wrong. Bottom line - don't deprive yourself the learning opportunity.
I don't think many people respect the
git addprocess. Many just add everything. As a developer, I like the opportunity to give my work a final review before I share it with my peers. So don't rush, use
git add -p.
What factors most affect the best git workflow for the job? Team size? Business goals? Tech choices? Personal preference?
I always start with GitHub Flow. I find this
master/feature branch workflow to be the easiest to manage.
In the hundreds of repositories I've managed, Git Flow on a small handful - like 3. These are normally projects that either need to support multiple versions (e.g. v1.0, v2.0, etc) or the business is unable to release features as they are complete (e.g. works to hard deadlines).
I'd challenge the latter is usually not a Git issue, but a deployment issue. As such, you may still adopt a GitHub Flow workflow.
What would you recommend to help developers become more comfortable deleting dead code (as opposed to commenting it out) with the confidence they could find it later in source control?
Commented code is dead code - REMOVE IT! Let Git do its job.
But yes, I recommend doing it as a separate commit with a clear commit message on what code was deleted so you have the best chance of finding it again.
However, from my experience, it's rare you'll actually look for code this way. Most people just go back to a known point in history to see old code instead of trying to pinpoint the exact commit.
Are there any git shortcuts or git bash scripts you'd like to see added (or you could contribute to) github.com/tj/git-extras.
Super useful project and I love using the extra tools there like git delete-branch (Local and remote on github Bitbucket etc) and even mundane stuff like git count.
git-extras is pretty cool.
I don't have many aliases. Only Git command completion. I like typing the full command so I'm explicit about what I'm doing. Too often with Git you can run some shorthand and forget the underlying commands.
Here are all my aliases:
Speaking of aliases and shortcuts aliases or git extras bash scripts aside.
Do you have a nice good clean shortcut to do git timestamp changes similar to git-redate (github.com/PotatoLabs/git-redate).
I find manually doing the redundant GIT_AUTHOR_DATE and GIT_COMMITTER_DATE changes for just one commit edit tedious (see stackoverflow.com/questions/454734...).
@gonedark / Jason McCreary do you have a response for my previous question about redo'ing the timestamps of old git commits?
What shortcuts do you have similar to github.com/potatolabs/git-redate?
What is the use case for needing to change the date?
Various reasons. Git rebasing and merging skew with the dates, and one wants to make the timestamp of the recent commits to "look" more reasonable.
Anyhow, what I'm really looking for is a shortcut for modify git timestamps without doing the manual work of setting GIT_AUTHOR_DATE and GIT_COMMITER_DATE with stackoverflow.com/a/3896112 .
Any insights @gonedark ?
@jonlai have you ever found a trick to get that alias to work?
My solution under zsh is
Git extras bash scripts seem to extend beyond aliases -- thanks for sharing your aliases by the way.
I'd like to start developing git bash scripts like git extras, but not on that level there yet.
What's your greatest personal frustration with learning Git?
Also, any common problems/patterns about Git that your students run into when learning?
I think visualizing the tree takes time to master. Once you're able to see the commit tree in your mind, it's easier to forecast what each command does.
Something else, a little more advanced, is to realize that everything is just a reference. A
stashall simply point to some changeset in the
.gitfolder. This also helps visualize the tree as well as understanding the various commands that accept a reference as an argument.
In the beginning, I recommend keeping is simple. Just use
commit. Don't worry about the other commands until you need them. And never be afraid to ask your local Git Master or me on Twitter - we all started as beginners.
That's a great point. Once I started picturing the git tree it really made a lot more sense.
On this note, how much is mastering git different from other parts of software development? Like, is learning to visualize the tree different from visualizing the structure of an application or data flow?
True, not much is different.
As with anything, it's all about experience. You have to push yourself to fully understand the problem and try new solutions. Many developers just do what they know, and in this case, only scratch the surface of Git.
I'm definitely guilty of continuing to grow my skills in most areas of software development, but only doing the minimum in advancing my deeper understanding of git. Something I plan to fix 🙃
This comment mad me think of your recent post Ben.
The myth of "never going back to fix it later" 🤣 so did you fix it?
Do you have any advice for helping a team clean up git hygiene? This is an in-depth question, so for clarity, I'm currently thinking about the actual commits.
Two difficulties seem to be "git trutherism" (rebasing or squashing is lying!) and developers fear of git and learning new ways to use it.
I suggest creating a Git Style Guide, similar to a Code Style Guide. I've helped teams create these. Often a quick meeting to get everyone on the same page and some sharing of resources like How to write a good commit message go a long way. Other rules (like don't squash commits) can be documented. As with any style guide though, it shouldn't be too restrictive.
I'd check out the article Writing Reviewable Code - commit messages are one of the things I see most underutilized. Having a body and explaining why changes were made is really helpful to both the author (they have to think about what they've changed) and to future readers who can see the code change but not the context for the change.
A useful rule of thumb for anyone scared of Git is that once you commit something, it's very hard to destroy that data. Rebase, reword, squash and fix-up as you want, and keep a clean history full of useful, searchable information for your project.
I pretty much just use Git to keep backup changes and roll them back if necessary, and to merge in changes from other developers. I occasionally might make a branch to explore a new idea and merge it back in. What else is there to know?
Sounds like you have the basics and are using Git to solve your problem.
If you want, you can challenge yourself and see if there are other commands you can use to do the same thing - maybe
revert. Also, if you're not, try using Git from the command line.
Cool. But it still does feel like I'm missing something. Like it's just a hipper Subversion.
Git really shines when you're working with multiple developers - when you start merging multiple branches from all over the history with overlapping changes multiple times in a day, you'll see why Git is so well loved.
If you're working by yourself,
git rebaseis a really good place to go next. It can be a little intimidating at first, but once you understand it, you'll have a good high-level understanding of how git works. Rebase is useful for tidying up multiple commits and keeping a clean history with atomic commits and details about why things changed. It might only be you using it for now, but I've gone back to plenty of pet projects years later and looked at the blame to figure out why I did something in a particular way. If you ever hand off a project to someone else (or just put it on Github), other developers will appreciate it too.
Personally I think Git offers an abysmal interface, conceived by elite engineers that wanted to do versioning their own way, but without any idea of usability. This isn't suprising from the minds that conceived Linux (including Torvalds) and its ecosystem. Just reading the documentation is a free pass to a massive headache for any novice, and this implies its discoverability is also more or less non-existent.
While some concepts and worflow methods have been a long awaited evolution of the ones found in SVN, others have a very weak connection with the main objective of the tool: versioning stuff.
I feel one of the biggest issues with Git is its monolithic nature: you can do a lot of things with Git, but some - from a more modern point of view - are better suited for external plugins. For example,
git rerereis something a nice middleware could do instead.
What can you say to convince me I'm wrong?
Keep in mind that I did read your article about not using GUIs - but it's far from enough, as its main point ("Don't use wizard code you don't understand") does not imply, in my opinion, that you need to understand the underlying Git commands, but just what a GUI command means to your Git workflow. In short, you should know what's a commit, a branch, a merge and so on, but you might not care how to do it with the CLI. (I have a draft of an article about it.)
Nothing. Aside from your viewpoint on the creators of Git, it sounds like we're on the same page.