I'm a Git Master, Ask Me Anything

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

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.

Command line all the way!

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.

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.

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 haven't leveraged Git to manage many binary files. Maybe someone from the dev.to community could chime in on this one.

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!

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 init to 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.

I honestly have not dug through the source code. I find browsing around the .git folder was enough for me. But if you were so inclined, the source is mirrored on GitHub.

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.

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.

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.

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 master which prevents anyone from pushing directly to it without a Pull Request.

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?

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.