git is one of those tools that no matter how much you know about it, there is an infinite supply of new things to learn. Here’s a handy bit I’ve discovered recently, thanks to this StackOverflow comment:
Since Git 1.8.4, git log has -L to view the evolution of a range of lines.
And you want to know the history of what is now line 155.
Then, use git log. Here, -L 155,155:git-web–browse.sh means “trace the evolution of lines 155 to 155 in the file named git-web–browse.sh“.
Absolutely brilliant! I used to suffer through this via an iteration of git blame and git show to the point of custom bash scripts.
“Git Workflow Basics” is yet another take on the git workflow. This subject has been covered in a variety of ways before (here, here, and here, for example), but I think it’s super important for every developer to understand, so if all the other attempts left you puzzled and confused, have a look at this one. It’s pretty straight forward.
One thing in particular that I would like to emphasize:
And hey: remember to review your own pull request before asking for reviews of your teammates. You’ll spot a lot of small things you didn’t notice (style issues, typos, etc) and will allow your colleagues to focus on what really matters.
A few days ago BitBucket announced the re-worked dashboards, which are now much more focused on the Pull Requests that you’ve created or need to review, rather than lists of repositories that you have access to. I’ve enabled the feature for my team and it looks super awesome!
If you’ve been suffering from being lost in dozens or hundreds of projects and missing out on the Pull Requests activity, check them out. You’d be surprised.
Git from the inside out – must be the best thing I’ve ever seen on how git works. Everybody knows that git is awesome. Most know that git is implemented with graphs. But not many know how exactly git stores the project history and how it is affected by different git commands.
And if you are feeling adventurous, there is this:
Which, among other things, includes “Git in six hundred words“.
Here is a cool tool to spice up your regular boring looking diffs – diff-so-fancy. Don’t get spooked by the npm installation instructions – the meat of it is all in perl/shell and you can install it as any other ~/bin/ script. Have a look at what you are missing:
Git 2.9 has been released a few days, bringing in some very useful functionality, such as showing renamed files in git diff and git log, forbidding the merge of two branches that have no common ancestors, configurable path to hooks, and more. All are welcome changes, making the life of a developer easier.
But what I found interesting is how two largest git companies – GitHub and BitBucket – reflect on it. Surely, the new release is important to both, but it’s insightful to see which features each of them looks at first. Have a look:
Garrett Holmstrom’s blog /dev/zero has a nice collection of useful git commands, especially for those people who work a lot with GitHub. Here are a few links to get you started:
Very handy stuff!
“Git rebase and the golden rule explained” – is an excellent explanation of what happens when you do rebase in git repository. If you know already, or don’t care, at least remember the golden rule:
Never, NEVER, NEVER, rebase a shared branch. By shared branch I mean a branch that exists on the distant repository and that other people on your team could pull.
Linux.com reiterates over the ways to fix and undo mistakes using Git version control software. Seasoned git users will probably know all of these already, but since I have to explain these things to git newcomers, I thought I’d have it handy somewhere here.
Here are some very nice and simple git tutorials from Atlassian (BitBucket people).