The hub subcommand for git, allows you to perform many of the operations made available by GitHub's v3 REST API, from the git commandline command.
You can fork, create, delete and modify repositories. You can get information about users, repositories and issues. You can star, watch and follow things, and find out who else is doing the same. The API is quite extensive. With this command you can do many of your day to day GitHub actions without needing a web browser.
Supposedly, git-svn can also be used to convert a Subversion repo to Git. Unfortunately, after reading the git-svn docs carefully and several useful resources (like the slightly-obscure Git FAQ, the Git Community Book, Paul Dowman’s blog and Alexis Midon’s blog), it became apparent that all the resources are piecemeal and nothing gives you the BIG HONKIN’ PICTURE. So here it is, ponies and all…
blogs.perl.org/users/ovid/2014/07/making-git-bisect-more-useful.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+PerlWeekly+%28Perl+Weekly+newsletter%29, posted 2014 by peter in automation git perl testing versioncontrol
If you've ever used git bisect, you know what an incredibly useful tool this is. It allows you to do a binary search through commits to find out which commit caused a particular error. Many people seem unaware of git bisect run ... which automates this even further, but it has a limitation: it won't let you find a particular error, it detects success or failure, that's all. So I decided to do something about that.
blogs.atlassian.com/2013/12/git-svn-tips-and-tricks/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+AllAtlassianBlogs+%28Atlassian+-+All+Blogs%29, posted 2013 by peter in development howto reference versioncontrol
The list below contains all the tricks and tips I had to research and integrate in my workflow to keep using Git joyfully in conjunction with SVN. Enjoy!
The first obstacle we reached when we were setting up our continuous delivery pipeline was figuring out which branch to continuously deliver. We changed our minds a few times before settling on a pipeline that would run all the code from the development branch. Except production, that is, which would deploy from master. This was always a bit confusing and didn't make a whole lot of sense. The idea with git flow is that master always represents production while develop represents the current state of development. The idea of continuous delivery, though, is to reduce the time between what master represents and what develop represents. In the ideal case, develop and master would converge. These worldviews clash quite spectacularly when tried to use in conjunction.
In this post I present the development model that I’ve introduced for all of my projects (both at work and private) about a year ago, and which has turned out to be very successful. I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management.
If you’re fighting Git’s defaults, ask why.
Treat public history as immutable, atomic, and easy to follow. Treat private history as disposable and malleable.
The intended workflow is:
1. Create a private branch off a public branch. 2. Regularly commit your work to this private branch. 3. Once your code is perfect, clean up its history. 4. Merge the cleaned-up branch back into the public branch.
In Git, there are two main ways to integrate changes from one branch into another: the merge and the rebase. In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it.
SVN Access Manager is a powerful tool for managing access to subversion repositories. The tool provides user and group management and access rights (read /write) to dedicated paths in a repository as well.
SVN Access Manager uses projects to give users the rights to manage their own modules in a repository. Project is used substitutionary for a toplevel directory.
The basic idea of story branching (sometimes referred to as “issue-driven development”) is that you create a development branch for each and every JIRA issue you implement.
Bug fixes, user stories, spikes… they all get their own branch.
Madness, you say!
And I would agree with you if we were still using a centralized version control system like SVN.
But branching in Git is very lightweight and merges don’t lock up the entire repository, making this crazy idea quite practical.