Posts about Git
Do you have a problem in your Git history where the same person appears with different usernames or emails? Check out the Git way to solve the problem.
Have you ever heard of a Foxtrot merge in Git? In this post, guest blogger Sylvie Davis describes what a foxtrot merges are and why you should avoid them.
Git LFS 1.2 is out, and I'd like to share a little tip that can improve your clone times by a factor of 10 or more!
This week I'll show you how to let Git automatically select the correct SSH keywhen you are using multiple Bitbucket accounts.
Hear Hear, the new Git 2.8.0 release is out! In the past couple of weeks, while the release candidate cycle was ongoing, I went through the commits and release notes trying the new things and scribbling down the interesting bits. To save you time here is a subjective selection of things to try out. Enjoy!
Professional teams that produce quality software often employ alightweight process to safeguard the introduction of new or updated code totheir stable branches. A code approval policy is an agreement within a singleteam or an entire organization to follow a set of rules regarding how and whencode is accepted into the main lines of a project, on the way to reach"production" and final distribution.
Recently I read about this amazing technique in an Hacker News
thread on people's solutions to
store their dotfiles. User
StreakyCobra showed his elegant
setup and ... It made so much
sense! I am in the process of switching my own system to the same technique.
The only pre-requisite is to install Git.
At Atlassian, one of our design principles is to gracefully reveal depth. As we've iterated on our UX, certain Bitbucket power user features that strayed too far from the happy path have been hidden away behind a dropdown or keyboard shortcut. There they bide their time until an adventurous user stumbles upon it through a capricious key press or mouse click (or someone reads the docs). Here's six of my favourite Bitbucket Cloud features, that you've possibly never heard of:
This week I'll discuss how you can move a full Git repository, including branches, tags, and history from one repository to another.
A quick two months after 2.6, Git 2.7 has been released with a plethora of features, fixes and performance improvements. Here's some of the new stuff we found interesting on the Bitbucket team.
Git is very good at merging code. Merges are local, fast, and flexible. Naturally every time one merges content from different branches conflicts can and will happen. Often solving a conflict is as simple as knowing and choosing the leading change. Sometimes resolving a conflict requires more work.
It's been a while since I have reviewed Git release notes but
that does not mean I haven't been eagerly reading more recent ones and
incorporating new gems in my routines. To celebrate my birthday (yay!) and the
recent release of Bitbucket Server I have collected a round of my favorite
features for the Git
2.x series (up to
2.6). Let me know if you end up
using any of these.
Many users have embraced Git for its flexibility as a distributed version control system. In particular, Git’s branching and merging model provides powerful ways to decentralize development workflows. While this flexibility works for the majority of use cases, some aren't handled so elegantly. One of these use cases is the use of Git with large, monolithic repositories, or monorepos. This article explores issues when dealing with monorepos using Git and offers tips to mitigate them.
Need to store large media files in Git? We're making major contributions to the Git LFS open source project to help make this happen! Want to know how this came about? What follows is a true story...
Let's add another arrow to our already full quiver of version control tools and techniques. Do you know that the Linux kernel you clone normally contains only a part of its entire history? If you need access to its uninterrupted evolution since the first commit you have to "graft" a few separate repositories together chronologically. In this post I'd like to show you how it works and why would you want to do that with your projects.
Follow along or just sit back and enjoy a live, hands on tutorial on the power routines of experienced git users. We'll explore with real world examples how to amend commits, do an interactive rebase - and why would you want to do one in the first place, how to solve conflicts without any merge tools, the power of less known merge strategies, how to do interactive commits, and much more.
While I prefer Sublime Text, my colleague, Nicola, prefers Vim. While we both have Macs, I sometimes work on my Windows desktop. Sharing work across these environments sometimes creates a whitespace conflict. Nicola's Vim put tabs to indent in shell script, instead of spaces. Or my Sublime Text on Windows put extra control characters at the end every line of Python. And, unless you are programming with whitespace, then you probably know how painful this can be. Fortunately, there are a couple tools you can use to avoid the most common whitespace problems.
Once a year developers from all over the world get together for Atlassian’s premier developer conference: AtlasCamp. You can learn how to customize and integrate JIRA, Confluence, Bitbucket, HipChat, Bamboo, and Stash, helping your team work even faster. And if you want to take your developer skills to the next level with Git, CI, CD, Docker and more, you should be at AtlasCamp.
Git subtree allows you to insert any repository as a sub-directory of another one. It is one of several ways Git projects can manage project dependencies. People with good memory will remember I wrote about the usage and the advantages of the command in an earlier piece on Git submodule alternatives.
AtlasCamp is right around the corner on June 9-11 in Prague, and will be like no other AtlasCamp. For the first time we have two tracks of content, starting with our usual track focused on how to customize, integrate with, and extend our products. This year we've also introduced a brand new track focused on sharing great developer content to help you build great software and services.
A few weeks ago, a "vulnerability" was discovered in a new security feature that shipped in Git 2.2.0: signed pushes. No need to panic though! It is vanishingly unlikely that anyone would be able to successfully exploit this particular problem. In fact, the issue was quietly fixed a few days ago in the 2.3.7 point release.
push --force is destructive because it unconditionally
overwrites the remote repository with whatever you have locally,
possibly overwriting any changes that a team member has pushed in the
meantime. However there is a better way; the option --force-with-lease
can help when you do need to do a forced push but still ensure you
don't overwrite other's work.
Thanks to the flawless organisation of the GitHub team, Git Merge 2015 happened last week in Paris. It hosted the Git Core Contributor Summit on the first day, one day of Git talks and the celebration of Git's 10th anniversary on the second. I felt very humbled and fortunate to participate in the first day and to witness real discussions amongst the core contributors. Here's a few notes I took during the discussions of the core team.
We have all been there. When we started bitHound I knew we would inevitably be supporting multiple platforms and different environments for analyzing code. However, with several code hosting platforms out there and limited resources available we had to grab one platform to start and do so quickly.
Deployment doesn't get any simpler than just getting the latest versions of some files up to the production server. While rsync, sftp, and scp have long been the tools of the trade for such simple deployments, these approaches have their warts. Even if it is easy to recover, an remote copy that fails in the middle may leave a web site in an incoherent state. If you are already using Git to manage the files as source code, then you may benefit from using Git's native ability to distribute versions of files. While this idea isn't all that new, there is a new feature of Git that makes this much easier than in past. Read on to learn when Git-based deployments are appropriate and how you can use Git to deploy files.
It's that time of year again! Time for Atlassian's San Francisco office to be insanely jealous of our counterparts down under. Specifically, we're jealous of the Sydney office's graduate program: the Atlassian HackHouse.
As our repositories grow large and complicated, it can seem impossible to find
when specific strings of text were introduced to the repository. While the
blame command does great for showing you the most recent modification of
the line, how do we find the earliest, especially considering that line
numbers shift as commits and merges happen?
So here's the scenario: your team works independently on a Git repository but a part of the organization still uses Perforce to manage parts of the same code base. Those teams on Perforce are not planning to migrate but your team has already transitioned to Git (for lots of good reasons). It's important that you can keep a two-way code-sharing process ongoing between the code-bases so that improvements developed in either version can be shared, hopefully without costing too much time or bogging down your team too much.
It's been an incredibly busy year here at Bitbucket! We've served more active users, made more improvements, rolled out more features, and fixed more bugs than ever before. To commemorate the year that was, I've visualized our Git log using the Gource log visualization system to give you something to look at while your code is compiling. You can read about how I made the magic happen below the video.
If you're using Git, you're probably using pull requests. They've been around in
some form or other since the dawn of DVCS. Back before Bitbucket and GitHub
built fancy web UIs, a pull request might've simply been an email from Alice
asking you to pull some changes from her repo. If that sounded like a good
idea, you could run a few commands to pull the changes into your
Back in December I did a webinar on some of the advantages of using git with your Bamboo pipeline, leveraging some of the Bamboo and Stash integrations to create a feed-back loop of quality control. The transcript for this webinar is now available below the fold...
git merge-distinct is a little tool that merges
multiple branches containing non-conflicting changes into a single head, using
octopus-merge strategy. Why would you want such a thing? Because while
it's useful to develop in the isolation of a feature branch, it can often be
useful to combine branches together for testing or deployment to a staging
The gang is reassembling again for another Dev Den Open Office Hours at the end of this month where we'll be talking all things Git again including discussion on last month's Git security incident.
One of my favorite Stash features is its plugin system. Since Stash is a git repository host, 99% of Stash users are software developers. And since developers often like to scratch their own itch, we've invested heavily in extensibility and customization to make plugins both powerful and simple to write. In this 30 minute video tutorial, I'll walk you through building, deploying and debugging a simple repository hook plugin, from scratch.
A critical vulnerability was identified in Git last week. This has been fixed in all maintained versions of Git (v220.127.116.11, v1.9.5, v2.0.5, v2.1.4, and v2.2.1) so upgrading is the best way to protect yourself. However a sensible second step is to secure your Git hosting server, so that pushes containing malicious trees are automatically rejected. This will prevent attackers from exploiting users who have yet to upgrade their local versions of Git.
The maintainers of the Git and Mercurial open source projects have identified a vulnerability in the Git and Mercurial clients for Macintosh and Windows operating systems that could allow critical files to be overwritten with unwanted files, including executables.
In our recent Dev Den Office Hours we were asked some very interesting questions. One that caught my attention and on which I elaborated a bit on was the following:
A couple of weeks ago I ran a webinar on how to enhance your Git development experience with JIRA and Stash. The half-hour allocated for Q&A wasn't quite long enough, so I'm following up on some of the unanswered questions in blog form.
When a piece of work is complete, tested and ready to be merged back into your main line of development, your team has some policy choices to make. What are your merge strategy options? In this article I'll explain the possibilities and then provide some notes on how we do it at Atlassian. Hopefully at the end you'll have the tools to decide what works best for your team.
We've just completed another round of the Getting Git Right tour, spreading the love about the hottest DVCS across ten cities in North America and Europe. To cap off the tour, the presenters are getting together for a special Google Hangout to talk about developer workflow and the latest happenings in the world of Git.
After a few short months git 2.2.0 has been declared final. This is big news, as it comes with a host of new useful features for improving your git workflow. Here's the stuff we found useful at Atlassian: