Last week, we hosted a webinar on git, focusing on workflows and practices you can adopt when you move to git. We discussed two of the more popular branching models used internally at Atlassian in depth, and gave practical examples on how git can allow you to reduce friction and increase the efficiency of your team.
Watch the recording, share it with your team
If you’re evaluating the move to git and you want to get familiar with distributed version control concepts, then this webinar will help you get started.
https://www.youtube.com/watch?v=B78AdLNZBQQ
And for those who are interested in the slides:
Questions from the webinar…answered
As testament to how big a topic git is and the need for this kind of training material, more than a hundred questions were asked by our audience during the webinar. Many were worth answering, but we thought we’d answer some here so everyone could benefit. Here we go!
Q: What’s the difference between using a centralized server in git vs subversion ?
The difference is huge and comes down to the new capabilities and concepts inherent with distributed version control. Let me name a few things that you gain by using git even if you stick with a centralized collaboration model:
- Even if you have a central server, every git clone has access to the entire history of the project locally. This is a great boost of productivity for every developer in general. All operations but push and pull are local. This means the speed of operations like searching for commits, content inside commits, committing changes is incredibly fast, almost instant for most codebases.
- git gives you very powerful branching capabilities: creating a branch is instant, merges happen locally and are very fast too. Merges in git have also the added benefit to generate less conflicts because they are first class citizens of the architecture and git knows about ancestry relation between branches.
- git allows for a very powerful way of developing software: feature branch development workflow.
- Using git and a repository management solution like Stash or Bitbucket, opens up a new low friction code review and quality process popularly known as Pull Request. The Pull Request is an innovation that came with git.
Q: Are push and pull similar to commit and update in Subversion ?
Yes, that’s correct at a high level! But there are obviously differences. To clarify:
- A git push is indeed similar to a svn commit, but keep in mind a few things:
- A git commit is a local operation.
- When you perform a push you will upload all the commits that the remote repository does not have yet, not necessarily a single commit.
- With git you can push code to any remote branch you like while in Subversion your checked out branch and the server one will always match.
- In git, a pull is equivalent to firing two separate commands:
- A fetch where the latest changes from the remote repository are stored in the the local repository (not the working directory).
- A merge of those incoming changes to the branch checked out at that moment.
Q: How can you use git to manage code reviews while using a centralized model?
A great low friction way to manage code reviews when you move to git is to adopt Pull Requests, which are first class citizens of tools like Stash and Bitbucket.
Q: You mentioned that a merge can happen only after a pull request is approved, is that correct? Can you merge locally and then push to the server without creating a Pull Request?
I understand the confusion since in the webinar I mentioned that the Stash team requires that merges only to happen after Pull Requests have been reviewed and approved, but let me clarify a few things:
- In general, a git merge is a local operation you can execute it any time you like. And unless you put in place some specific hooks that prevent it, you can push those merges to the server without restriction. Having said that though:
- For teams that adopt code reviews in their development process, it’s nice to enforce that merges happen only after a Pull Request has been reviewed and approved. This is not mandatory, but we found that it really helps keep your code base in check! If you use Stash, you can customise and tailor the checks performed during the Pull Request. For example, you can require that the feature branches have at least two green builds before the Pull Request is approved and the merge can happen.
Q: We – as IT Department – want to move to git, but there are many concerns about moving to git from our developers: how “difficult” is it really to learn?
It is true that git has a non-negligible learning curve, but with the right planning and access to the right documentation material the transition can be relatively fast and smooth. There are a huge number of resources online nowadays to speed up the knowledge acquisition of the team. Let me name a few that might come in handy:
- Basic information and tutorials at Atlassian Git Microsite.
- Some great tips on the human side of the migration to git.
Q: At what point in the software development do you delete a branch?
- In git, once a feature branch has been merged all the information about that piece of development is preserved into the target branch: the merge commit records when the merge happened and all the individual change-sets of the body of work. Because of this, there is little value in keeping old feature branches around once they have been merged. If you use Stash, we actually provide a useful checkbox together with the merge button that will delete the feature branch once it is merged.
Q: Any recommendation on handling Products that require multiple git repositories for one product?
- Stash allows each project to have multiple repositories. The Stash project itself has several dozen repositories.
- If your technology stack is uniform, you can manage, link and create the dependency tree of your application using your tech of choice (maven in Java, pip for Python, gems or bundler for Ruby, etc). If the repositories are heterogeneous, you can still manage them with git either using submodules, subtrees, or other tools like google’s repo.
Want more Git tips?
Want to learn even more tips and tricks on git? Sign up for the Git Insiders Email to stay in the loop.
Ready to try Stash?
Get up and running in a matter of minutes with a free 30-day Stash trial.
Anyone can be good, but awesome takes teamwork.
Find tools to help your team work better together in our Git Essentials solution.