I'm a Git Master, Ask Me Anything

Command line all the way!

The reason people shy away from rebase is 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 rebase again. 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 rebase often. But I do so at the end - right before merging - so I limit the chance for it to affect other developers.

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.

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.

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 with git add -p (leaving out what I don't want). I make the commit, then discard what's left with git reset --hard.

Magit in emacs is a pretty good way to learn of other gut options and parameters.

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.

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 add and commit.

For resource recommendations, see my previous comment.

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 add process. 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.

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.

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.

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:

unstage: reset HEAD --
logo: log --oneline
append: commit --amend --no-edit
lola: log --graph --oneline --decorate --all

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, even stash all simply point to some changeset in the .git folder. 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 add and 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.

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.

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.

What can you say to convince me I'm wrong?

Nothing. Aside from your viewpoint on the creators of Git, it sounds like we're on the same page.