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...
For further actions, you may consider blocking this person and/or reporting abuse
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 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
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'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 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
used as
example
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
commit,branch,tag, evenstashall 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
addandcommit. 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.
e.g.
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.
I have my Develop branch then I created a feature/nav-bar branch, my code needs to be rebased because there are new changes in Develop branch, how do I do that... so let's say I am in my feature/nav-bar branch in that "folder" should I run "git rebase develop" ?
Yes. From the feature branch, you would run
git rebase developto fast forward your branch with the latest change and replay your work. Check out my previous post for a closer look at git rebase.You don't have to be in any folder, just the repo.
Hi. We never used Git in our company. I have good knowledge of Git. I'm using my all open source projects. What should I do to teach it, my teammates?
They don't accept work with Git o related technologies. I just work with Git. What should I do to convince them?
I suggest showing them how quickly Git and Git services can do things - creating and switching branches, sharing work, enhancing the code review process with Pull Requests, etc.
I sometimes have trouble simply when checking out/resetting to a particular commit.
The perfect example is the git version of the Gentoo portage tree.
If I reset to some very early point in time and then go back to my origin/master, it often complains about newly added or modified files, without me actually touching anything.
Why is that?
resetdoesn't sound like the right command for what you describe. By default,resetwill uncommit the changes and put them in your index. So when you go to switch branches, it's likely complaining since Git sees changes in the index.To go back to a previous point in time,
checkoutis the more appropriate command.If I was to create a new branch and wanted it to be at exactly that commit, would I then use
checkoutfor a detached head and then acheckout -b foobar?Is there any better way to achieve this?
You could do that.
Many forget
checkouttakes second argument as a reference to checkout from. So if your goal was simply to checkout a branch from an older point in time (commitabc123), you could run:git checkout -b foobar abc123What is the best way to clean up old commits? E.g. I only want to keep history of the last 2 years and remove all older commits, in fact treating the 2 year old version as the initial commit?
Related: how to remove commits of a bigger file that was pushed in by a developer and that needs to be moved out (e.g. to git LFS or just a file repository server).
How would you recommend setting up a project that has multiple developers with Git, especially if you want to make sure that a rogue developer can't check in commits as another person or take the whole origin down?
Give them limited access (read only) and setup a code review process. Nearly all services - GitHub, Bitbucket, Gitlab - provide ways to restrict write/push abilities to branches.
For example, our team creates their own forks of the main repo. We also protect branches like
masterwhich prevents anyone from pushing directly to it without a Pull Request.Scenario: you work with 4 other developers on a project, where you use the Git Flow methods (though no pull-requests).
When will you use `
git rebaseand when will you usegit merge --no-ff`?I'd add to Jason's answer that
git rebaseis far more than an alternative workflow to merge. I use it heavily during local development for example, before and during merge/pull requests:Updating your in-progress branch to include changes someone else has merged that you need (this is the classic example)
Moving your work to be based on a different branch (eg. you originally branched from
masteras a hotfix, but part-way through you've found it makes more sense to fix with the changes already ondevelopto avoid additional changes when merging).Separating commits from a branch into multiple branches that make more sense for review. I often do this if I find a bug while writing a tests for existing code - commit a fix on the tests branch, then move the fix commit(s) to a separate branch once everything is done to submit them separately to the test changes. You can also do this with other people's commits and the authorship is not modified.
Changing the order of commits, dropping, squashing and combining commits (ie. fixup)
Amending a commit on my local branch that's not the last commit (rewording, adding/removing changes, etc).
git rebaseis likely reserved for feature branches to prepare them for merge. Under Git Flow, you'd likely never want to rungit rebaseon the long lived branches.The
git merge --no-ffensures the merge does not fast forward your commits onto the target branch. Essentially, this guarantees a merge commit.If I do a "git clone," I get the master version clone of the entire supermodule/submodule repository. If I subsequently do "git submodule update --init," my submodules are set to dangling HEADs (no branch), corresponding to the versions when the supermodule was (last?) set up.
I'd like to change the "update --init" to point to the (new) master versions of the submodules. Not sure what's the right commands/sequences to do this.
Please help.
We're finally moving to git from a dev/production server for website maintenance. I've used git before, but never set up workflows, etc.
2 q's :
In the Git Flow - Is there a way to maintain the development branch on one subdomain while the master branch is on another?
Is there a good method for tracking (and ignoring certain?) changes to databases?
I'm not sure I understand the first question.
As far as the second, are you tracking the entire database (structure + data) in Git? Or just migrations?
Hi Jason, thanks for your reply
2 - would prefer to track the whole database.
1 - Our current workflow uses a dev/staging copy of the site at dev.domain.com & the live/production site at (www.)domain.com. I'm trying to figure out how to merge that workflow into something close to a Git Flow framework if possible? I know I'm not explaining this well at all :\
For anyone who finds this post - worktrees were the answer to #1.
This was the ultimate solution: github.com/ferkungamaboobo/firmida...
I regularly use the basics: pull, add, commit, push, and merge. What should I learn next?
Sounds like you have the basics. Where are you experiencing a bottleneck?
No bottleneck, but I know that there is a lot more to git. What should I learn next?
Git used to be notoriously bad to manage binary files. What is the current situation with that?
You could use a .gitattributes file in the root directory of your repo to explicitly mark the file as "binary", see this link git-scm.com/book/en/v2/Customizing.... This should improve diffing!
I haven't leveraged Git to manage many binary files. Maybe someone from the dev.to community could chime in on this one.
What would be your branching model for a multi non-prod single prod system, where new features has to be signed off in non prods first, before they make it to prod? How would you set up your CI/CD?
I'd still use GitHub Flow. The rest is a deployment process. So promote the
masterbranch up through the environments to get signed off. Once approved then deploymasterto Prod.Admittedly the happy path is easy. Things get hard when a feature is not approved. In which case you could use Git to
revertit or adopt a strategy like feature flags.In the end, I don't consider this solely a Git problem. It's something that needs to be solved through code, deployment, and business strategies.
'It's something that needs to be solved through code, deployment, and business strategies'
thanks for an honest answer.
What's the best way to work around this limitation in git? stackoverflow.com/questions/376398...
Looks like there isn't - stackoverflow.com/a/37644574/164998.
As a new developer what parts of Git would you recommend mastering first to be productive in a workplace environment and how you go about mastering it?
If you can do all that, you'll be well ahead of most other developers. For reasons, see my previous reply.
How can I assign a GitHub user to a specific .git repo, and not global? I need to have different users for different repos in the same laptop
If I understand correctly, you use different GitHub users for different repos on the same machine.
The way Git configuration works is it will look for local config, then roll up to global config. So, you can set the author info for each local repo by running:
(note the missing
--global)What do you think of these git-tips?
Pretty awesome. Thanks for sharing.
Any book/website that you reccomend?
Of course I recommend Getting Git. It's a video series I created which covers nearly all of the core Git commands in two parts (basic and advanced usages). It's organized in four sections that build upon one another to take you, literally, from
git initto Git Master.However, outside of this, I recommend reading the first few chapters of Pro Git. This is something I do every few years and I always learn something.
What is your reccomended method for merging a feature branch into master?
Depends.
If working on a team, I recommend doing so through a Pull Request. This provides a formal merge process which serves not only as record, but also an opportunity for code review and discussion.
If it's just you, I recommend merging from the command line:
git merge the-feature-branchWhy git is one of the technologies to learn ?
It's the modern, popular tool for version control. So assuming your using version control (you should be), you should try it out.
I'm command line all the way, so I couldn't say. In general, if you've found a tool that works for you - use it.
Have the club split the cost of the Getting Git video series and watch them together in your next meeting.
How to understand source code of git and where to start?
I honestly have not dug through the source code. I find browsing around the
.gitfolder was enough for me. But if you were so inclined, the source is mirrored on GitHub.