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 (102)
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 userebaseoften. But I do so at the end - right before merging - so I limit the chance for it to affect other developers.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.
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.
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
push,pull,remote.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 withgit add -p(leaving out what I don't want). I make the commit, then discard what's left withgit 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
addandcommit.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 :)
Thanks!
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'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, usegit add -p.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.