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!
Latest comments (102)
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.
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-branch
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?
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.
What do you think of these git-tips?
Pretty awesome. Thanks for sharing.
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.
What 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 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
)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 develop
to 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.
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 rebase
and when will you use
git merge --no-ff
`?I'd add to Jason's answer that
git rebase
is 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
master
as a hotfix, but part-way through you've found it makes more sense to fix with the changes already ondevelop
to 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 rebase
is likely reserved for feature branches to prepare them for merge. Under Git Flow, you'd likely never want to rungit rebase
on the long lived branches.The
git merge --no-ff
ensures the merge does not fast forward your commits onto the target branch. Essentially, this guarantees a merge commit.