Rebasing is a topic that comes up all the time when using Git. Many times, rebasing results in having to do a force push, which makes some people wary of rebasing. No need to worry! Once you understand why a force push is necessary, and how to rebase responsibly, you’ll feel more comfortable.
So, what is rebasing, and how do you rebase in Git? Rebasing is simply taking changes that have been made somewhere else, incorporating them into your branch, and then replaying all of your changes on top of that new base.
You’re in fact, changing the commit history, which Doc taught us could have disastrous consequences. (Especially if you run into your future self.)
So, let’s throw on some Huey Lewis, listen to The Power of Love on repeat, and dive into an example featuring Back to the Future. And if you’re even considering using the CLI… Where we’re going, we don’t need the command line!
The Timeline
I made a new repo in GitKraken, a cross-platform Git GUI, featuring some main plot points from Back to the Future. First, Marty is sent back to 1985. You’ll see I created a new timeline branch that has a couple of commits representing the events that follow. Then, I pushed the timeline branch up to GitHub.
Marty is sent back in time where he encounters some highs and lows.
This timeline branch ultimately leads Marty successfully back to the future, and ends happily with Biff the bully waxing Marty’s dad’s BMW; plus Marty has a brand new Toyota 4×4. Yay! Everyone loves a happy ending!
However, back on master, there’s another change made where the Grays Sports Almanac has been added to the picture. (Uh oh….Biff is going to change the world into a very ugly place…)
If I rebase the timeline on top of master, (by dragging the timeline label on the left, on top of the master label, and selecting rebase timeline into master) GitKraken will replay all of my commits, on top of the last commit on master, in the same order.
As you’re probably aware, this action affects the future, and Biff becomes a philandering, billionaire casino owner and marries Marty’s mom. (Any resemblance to current presidential candidates is purely coincidental, but I digress.)
Biff has the opportunity to take over the world… and does.
Back on my remote timeline branch, you’ll see that I still have everything happening in the happy timeline, but locally we have a different commit history.
Therefore, GitKraken is not going to allow a simple push. Git only allows pushing new commits and can’t insert other commits into the Git history, which is why I have to do a force push. The force push literally replaces the remote branch with what we have locally.
Now, this is where some of the trouble comes in. If I replace my remote branch with what I have locally, this has the ability to overwrite other changes, and it’s exactly why a lot of people are reluctant to use rebasing.
‘Mom hydrates a pizza!’ is added.
Let’s say that other changes were made to my remote branch that I haven’t pulled in locally. So, on the remote timeline branch, Doc made another commit called ‘Mom Hydrates a Pizza!’, which doesn’t exist on my local timeline branch.
Now if I do a force push, whatever commits are not on the local branch will be lost, and we don’t get the hydrated pizza. In this case, I can cherry pick any new commits into my local timeline, and then do the force push.
I know, I know, this lands us with the dystopian timeline and ruins Marty’s happily ever after…
The Golden Rule of Rebasing
The Golden Rule of Rebasing reads: “Never rebase while you’re on a public branch.” This way, no one else will be pushing other changes, and no commits that aren’t in your local repo will exist on the remote branch. So then when you push, there’s no possibility of deleting data.
If my calculations are correct, when this baby hits 88 miles an hour, you’re gonna see some serious Git!!
Have you ever wondered exactly how an SSH key works? What’s it for anyway? Look no further! Let’s get to the bottom of this, shall we?
Do you remember getting the keys to your first apartment or house and thought “Yes! All mine! Peace, quiet and freedom at last!” Well, SSH is kind of like that. It’s freedom from the burden of knowing information that you simply don’t want to handle. Because really, who needs more drama in their lives? You don’t.
So here is a breakdown of what an SSH key is and how it can make you feel as free as a baby cheetah running alone in the savanna.
SSH stands for Secure Shell. No, not secure hell. That’s something different. It’s a program that allows you or your app to log into another computer over a network, complete some commands on that computer and then come back your computer with those files.
Simple, right? It’s just like a little messenger that goes back and forth between your server and the remote server.
Public and Private
When an SSH key is generated, it is composed of two sections: public and private, which is exactly what it sounds like.
The public component of the key can be put up anywhere; in fact, it is important that other people know about it. The private component is how you prove to the remote server that you are authorized to perform an action on the remote server.
If it’s not obvious, the private section of the key should never leave your machine—especially if there’s any doubt that it could be compromised in any way. And don’t forget that you’ll need a password on that key.
The Exchange of Info
In order to exchange the info, your app will send a request to a remote server with a list of all the public keys it has access to. The server will find the public key to give permission back to the user. Therefore, you can think of a public key as a lock template that can only be unlocked by the corresponding private key.
The server will generate one of these locks, and send a request with the lock back to the client. The client, assuming it has the private key, will send it back up to the server. This tells the server that the client is allowed to perform actions on the server.
Using a (Secret) Agent
An agent is a program that runs on the client so the app doesn’t need to know how any of the process described above works. The secure communication between the server and the app is handled by the agent, rather than by the app itself.
A major benefit of this is that only the agent needs to know how to talk to the server. Your app has no time for this information or drama. It’s like your very mature friend who walks away when the gossip starts flying.
So…the app itself doesn’t have to know the encryption of the keys or even where the keys are! Your app can stay busy minding its own business. You add a key once to the agent, and any app can communicate with that agent on the client; it already has access to all those keys, and you don’t have to add them individually.
Rejoice! Now you know all about SSH. So save your drama for your mama…or your agent.
P.S. GitKraken is a Git GUI client that can generate an SSH key for you automatically. It can even add it to your GitHub account if you give it permission. Since GitKraken uses its own bundled copy of an SSH library, nothing needs to be configured outside of the app. Now that’s really something to rejoice about!
Looking for a fantastic explanation about Scrum and Agile, but don’t want to wade through a bunch of whitepapers, convoluted diagrams and confusing explanations with words you’ve never used before?
Well, look no further! Here, you’ll find the answers to questions like, “what is Agile project management?” And, you’ll learn how you can implement Scrum to help your team.
1. VDD stands for Value Driven Development
Do you know what the business expects from your current development? Do you have any idea about the most important features for the success of your project? You need a vision that describes who needs the product, why they need it and expected benefits. This vision is shared by stakeholders and the Scrum team.
Throughout the project, functionalities at the top of the product backlog are the ones with the highest business value. They are refined and discussed with the team.
2. No more tunnel vision thanks to short iterations
Do you really believe a client is always able to express exactly what they need at the beginning of a project? Maybe the solution they are thinking about in order to solve their problem is far from ideal. But how can you help them discover what they really need before the project is finished and its too late? Agility introduces the idea of iterative development, and Scrum is implementing it with the concept of short iterations of time (2 to 4 weeks) called a sprint.
At the end of each sprint, the team presents the client with what has been done. This means showing real working software, not just some slides or talking about a concept. Practitioners of Scrum believe it is the best way to share a common understanding to get the valuable feedback that is needed.
Every day, Scrum teams ask themselves: “Is this project going in the right direction or do we need to adapt?”
3. Command and control no more: empower the people!
Scrum will make you reconsider the role of management. In fact, a manager will turn into a servant leader!
A manager’s job is to make sure that the people within the team possess the skills required to complete the project, as well as a good work environment. Then they need to step back and trust that their team is doing their best to reach their objectives and continuously improve.
But, managers in a Scrum world cannot disappear completely. They still need to help remove the obstacles the entire team might face, in order to progress.
4. Dedicated and cross-functional team
Are you always involved with the same kind of technical tasks? (For example, only front-end development, only back-end development, only database, etc.) What about working on multiple projects at the same time? Do you sometimes lose focus and have to switch context in order to integrate your work with people who are working in other teams?
In a Scrum team, there is no more of that! No more multi-project and horizontal development: the team is collocated and dedicated to a single product backlog. Developers are full stack developers, who own a feature in a sprint from top to bottom, developing it as a vertical slice.
A good Scrum team is built for the long run; the product backlog may change after a project is finished, but the team will stay stable and move on to the next project.
5. A sustainable pace. No overtime!
Is your team often putting in overtime? And if yes, why? Well, the answer is probably because there are fixed deadlines that need to be met! But is this really a proper way to work? (Hint: it isn’t.) Scrum follows the Agile Manifesto principle about sustainable pace: Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely. The idea behind this principle is not that Agile people are lazy. The point is to provide visibility in the mid- to long-term.
The only solution is to maintain a sustainable pace through time. If people put in overtime to meet a deadline in one sprint, then they should be able to compensate in the next.
6. Introspection: The art of getting better
Agile and Scrum embrace failure as an opportunity to learn. Whether you fail because of something technical or because of a problem in your process, there is nothing wrong with that.
The real problem is when you fail, time and again, without searching for “why,” and without taking actions to prevent it.
Scrum has a dedicated ceremony to discover what went wrong during an iteration and to look for potential improvements: the retrospective. The Scrum Master is responsible for creating a welcoming, blameless environment where team members can exchange opinions. This meeting is crucial for the team and requires the most groundwork from the Scrum Master.
The Scrum Master should bring two things to a retrospective: a plan and a toolbox. Depending on what the team expresses during this meeting, the Scrum Master might have to adapt his/her plan.
As a beginner, you will often follow the 5-step retrospective from Esther Derby, picking innovative activities found online. Don’t worry, though, with time and experience you will create your own activities, and you’ll do what is right for your team.
7. Communication
Speak a common language for transparency’s sake, and put the focus on face-to-face communication for efficient exchanges.
A ubiquitous language about the business and the process must be shared by the Scrum team and the stakeholders in order to better understand all the visual tools and the sprint outcome.
Promote enriched and clear conversations about quality expectations. This way specifications, designs, and architecture are able to emerge easily from the Scrum team.
8. Say goodbye to over-engineering: YAGNI!
“Why are there so many questions to create a new user?! I just want to sign up!” It’s a legitimate question when the form in front of you contains too many fields.
This is where YAGNI comes in, which stands for “You Ain’t Gonna Need It”. Combine the VDD and short iterations to develop the minimal version of your features with a pragmatic code design.
ProductOwners: challenge your business!
Developers: challenge your product owner!
You can then use feedback from your users to efficiently build features that fulfill your needs.
9. Scrum is about people
“Individuals and interactions over processes and tools.”
This quote is actually the first statement and first value of the Manifesto for Agile Software Development. If anything, Scrum is about people and the way they work together. It focuses on the team members and their interactions, both within the team and within the rest of the organization.
Scrum also favors experimentation and knowledge sharing. Don’t hesitate to share your successes and your failures. And remember that you are not alone. There are a lot of Agile and Scrum communities with experienced practitioners who are ready to help.
10. Scrum is based on the Agile values
We just mentioned above, the first value of the Agile Manifesto, but there are three more. Scrum reinforces these values.
1. Working software over comprehensive documentation
In the Sprint review meeting, the team shows the concrete result of their work to the stakeholders by giving a demo of the working software. This is aligned with the second value. The product produced at the end of the iteration should always be potentially shippable, which means it could go into production.
2. Customer collaboration over contract negotiation
In a Scrum team, developers are encouraged to speak face-to-face with stakeholders and users. They collaborate with them on a daily basis. The product owner is particularly involved in this collaboration and paves the way for the team to better understand what the users need.
3. Responding to change over following a plan
Scrum embraces uncertainty and treats it as an opportunity. Planning short iterations allows the team to refocus its work on a regular basis. Your business just changed because a new competitor entered the market? Well, ok, no problem; a Scrum team can adapt quickly.
This piece is brought to you by Agile Partner, a Luxembourg-based IT service provider that strongly believes in the Agile methodology and provides software development and training.
If you want to learn Git, we recommend starting with the basic concepts and downloading a luxurious Git GUI client that can help make performing commands more intuitive.
In this Git tutorial video, Kyle, Axosoft software developer, gives a brief overview of how version control works and explains what a Git repository is. Watch this video now, and stay tuned for more videos that will help you learn Git!
My Rodese is a bit rusty, but I’m fairly certain that the headline translates to: “GitKraken has a really cool feature called soloing, and you’re gonna absolutely love it!” Or maybe it means “Going somewhere, Solo?” Who can really say, right?
Soloing is something special. When you want to hide all branches and tags, and need to see and work on specific branches and tags that are pertinent to you at the moment, you use the strength of soloing (it’s almost like The Force). So, for example, if you only care about one of your coworker’s remotes, you can hide everything else. It’s laser light focusing power.
What’s more, if you’re not working with a Git GUI client, and still work in the CLI only, in order to solo, you’ll have to install yet another command line tool.
You can check out the other benefits of using GitKraken instead of the CLI, in this helpful cheat sheet. Because we agree with Yoda, “Always pass on what you have learned.”
Going somewhere, Solo?
Simply put, “soloing” a branch, remote, or tag in GitKraken, focuses the commit graph to only show the commit in that ref’s history. It’s invaluable when you’re working with one or two branches at a time and want to ignore everything else (for example, if you want to check the progress on a release branch without having to filter out the rest of the graph).
Give in to the Graph (Not the Dark Side)
So, I can hear you asking, “how does this work?” Let’s start with an explanation of how the graph works. Imagine all your branches (both local and remote), tags, and stashes in one big list; for each of them, trace the commit history from their heads to the beginning of time. Then, merge those lines together into a graph, and presto: you’ve earned your degree in GitKraken graphing!
When you choose a ref to solo, GitKraken ignores that big list we were talking about and just focuses on what you told it to. If you decide to solo another ref, GitKraken will add that ref’s history to the graph, and so on and so on ad infinitum (or at least until you decide you’ve soloed everything you need). BONUS: you can solo a remote, which will solo all its refs!
In this example, you’ll have to imagine a galaxy far, far away, where our heroes, Luke Skywalker, Leia Organa, and Han Solo, act out this storyline. When the whole graph is viewed at once, the branches interrupt each other chronologically:
However, say we’re just interested in Han Solo: we can solo Solo (sorry, couldn’t resist) to see the following:
Or, maybe we want to analyze The Force’s influence on Luke and Leia as they lived out their destinies on opposite sides of the galaxies. If we had even more characters to worry about (say, Chewbacca and Obi-Wan), you could imagine that trying to sort through the entire graph would become difficult; this is when soloing comes to the rescue! First, let’s solo Leia:
Now that Leia’s soloed, notice the solo buttons that are now present next to all of the refs in the left panel:
Next, let’s solo Luke as well:
The Dev Side
Soloing is a GitKraken-specific feature, and because it was uncharted territory, we needed to solve various design and architectural problems. For example:
How should soloing interact with the ref hiding functionality?
How should the data be cached?
Also, soloing affects the repo’s internal representation, not just how it’s visually displayed in the graph, so we had to lock down what actions are available when something is soloed.
Solving and working through these challenges gave us an opportunity to learn new things and help us understand various new ways in which the app can expand.
One of the things we learned is that soloing, although simple, is a pretty powerful concept. So, start looking for ways that soloing can make you more productive in your day-to-day development using Git.
Every day we explore strange new worlds. Dev teams take lines of code—mixtures of phrases, words, numbers—and create new landscapes to examine; build advanced features to make life easier; and design original solutions to the world’s oldest problems.
For those who dare to go, “where no man [or woman] has gone before,” we offer you, GitKraken v1.9: now with GitHub Enterprise support.
Let’s walk through three main features of this new release, with some trivia about Star Trek’s own Starship Enterprise. Because, who knows, maybe these facts will win you a prize at pub trivia one night.
Self-Destruct Code was Used in the Episode entitled “Let that be your last battlefield.”
If you hear the code, you know it’s time to run, and run fast. But now, you should stay and find out about GitHub Enterprise support and why it’s important.
Tons of people (as you probably know) use GitHub.com to host repos. However, some companies prefer to have an in-house install of GitHub—a replica of GitHub.com that is established locally.
In the not-too-distant past, GitKraken was able to work with repos that were hosted in a GitHub install, but unfortunately, it was lacking the tight integration that GitKraken has with GitHub.com; where you can easily do pull requests, get a list of repos to clone, or add a remote.
Well, here’s the good news for those with GitHub Enterprise! With v1.9, users will be able to use GitKraken, and you won’t even recognize a difference between your local install and GitHub.com. Search no more: GitKraken will be your last battlefield.
Congrats! You’ve successfully connected to GitHub Enterprise server.
The Enterprise is Designed to Break into Two Pieces in an Emergency Situation
Not too many people know this, but “saucer separation” is a last-resort move to escape a particularly and unexpected aggressive situation. Yup, the Enterprise can jettison the back half and move on to find greener (and safer) pastures while the stardrive section stayed on to fight.
Well, you don’t have to tear yourself apart anymore when you’re in GitKraken searching for tags. Just like the update in v1.8 with branch folders, tags that have slashes in their names are now organized into coordinated folders!
Stay Vulcan-cool when you’re searching for tags that you’ve named in accordance to what they stand for. So, for example, take release/1.8.1. Now, you’ll be able to see all your releases that are completed or in progress. It’s logical, Captain.
When you use slashes to prefix your tags, they’ll turn themselves into folders. For example, if you have one tag that is 1.0 and another tag that is 2.0, GitKraken will serve up the most recent SemVer at the top.
Tag filters as seen in GitKraken.
Previously to this release, the releases were sorted alphabetically. So that would mean the one you were looking for could be all the way at the bottom (womp womp). Well, we fixed it, so cheer up. However, if a tag name isn’t a valid SemVer, it will sort that alphabetically. (Moral of the story: don’t ever be too happy.)
The Enterprise Eventually Became a Training Vessel for New Recruits
Think back to the beginning of The Wrath of Khan: The USS Enterprise is out of service, Capt. Kirk feels obsolete, and the only thing left to do is sail away into oblivion. But no! That’s not what happens. No spoilers here if you haven’t watched it.
This training vessel idea wasn’t exactly embraced by everyone. Spock had no problem saying it was a waste of time, but personally, I don’t believe that and neither do the GitKraken devs. One of the huge advantages of GitKraken is that it has the power to teach you Git, simply because of its strong visual component.
So, this final feature in v1.9 actually teaches you how the search in GitKraken works! Let’s turn our attention again to that powerful left panel; when you perform a search, GitKraken will now highlight the matching portions of the results.
For example: if you type the word “ref” in the search box, the search will match words in a subsequent way, and will look for “ref”, “re”, “f” or “release from”. The highlighting gives you insight into why you are seeing something based on your search.
Look at those highlights in action!
The benefits of this are twofold:
You are not sitting there wasting your brain power and wondering why certain words are showing up.
GitKraken is actually teaching you how the search works! And now that you know that, you’ll probably develop your own type of shorthand, allowing you to find things even quicker!
So, there you have it; now, you can check out the release notes to find out what else was fixed and improved!
For those die-hard Trekkies out there, feel free to read this in Klingon. Tweets kindly accepted for words I have translated incorrectly.
Whether you’re new to Git or a veteran who just wants to do things faster, check out GitKraken. This cross-platform Git GUI client can help you understand and execute with ease because of the intuitive interface.
In this video, Jordan, Axosoft software developer, talks about saving all your changes in Git and learning how to revert to a previous state if something goes awry. Watch the video below and make sure you stay tuned for more videos like this that will help you learn Git!
You asked for it, so we made GitHub Enterprise support a reality in GitKraken v1.9! That means with GitKraken Pro, all the cool GitHub.com integrations you’ve come to know and love in GitKraken, are now at your disposal for your GitHub Enterprise repositories as well.
Want to know more about what went into making our GitHub Enterprise support possible? Then read on! You can also check out all of the other cool features you get when you upgrade to GitKraken Pro.
Options
One of the things that made GitHub Enterprise a different beast than our GitHub.com integration, is the fact that we wouldn’t be able to rely on GitKraken’s API server to act as a mediator between the client and the service with which GitKraken is trying to interface.
GitKraken uses OAuth to communicate with GitHub.com, meaning the app asks the user, on GitKraken’s behalf, for permission to do a subset of actions for the user in the service. This all works because GitKraken can prove to the service that it is truly the one requesting those permissions for the user, through the use of a “secret” key, kept on the API server, and not shared with the app itself.
This logic falls apart, somewhat, in the case of GitHub Enterprise because the API server can’t really know all of the possible GitHub Enterprise servers it would potentially need to authenticate for. Even if it could, a “secret” key would have to be generated on each individual GitHub Enterprise instance.
The GitKraken dev team went through a litany of potential solutions for the new problems posed by the potential GitHub Enterprise integration and came up with a couple feasible solutions:
1. Release a standalone API server.
One thought was to deploy a standalone API server that could be set up for each GitHub Enterprise instance, presumably by the GitHub Enterprise owner’s IT department or whoever is in charge of maintaining that GitHub Enterprise instance. The drawback here is that there’s a significant amount of work required on the user’s end (or at least their IT department) to set something like that up.
Each user’s GitKraken instance would also need to know where that API server is, in addition to already needing to know where the GitHub Enterprise instance is. We’d also have to build the aforementioned standalone API server, test it, and make documentation for it. Basically, it’d be a lot of work for everyone. Highly illogical if you ask me.
2. Let GitKraken act as the API server, and allow a config file on the user’s system to handle required configuration.
This idea had some really interesting components to it. This would work by allowing a JSON configuration file to be placed on the user’s system (presumably by their IT department) that would contain the necessary information to allow the user’s GitKraken app to act as the API server. It actually probably sounds a lot simpler than it truly is.
One of the neat things about OAuth is that it allows the user to give an app permission to do things on their behalf, without sharing their password with the app. This only actually works if the user isn’t forced to enter their credentials somewhere that’s fully controlled by the app (defeating the purpose of OAuth almost entirely). That means GitKraken needs to hand off the authentication process to an external app that the user can trust (usually their web browser). The interesting part comes in at this point: How can the browser hand information back to the app when the user completes the authentication process?
Well, there’s a bunch of ways to do that, but the most elegant and interesting way (in my humble opinion) is to use a custom protocol handler. We’d essentially tell the user’s system that if a URL with a specified protocol was accessed (like gitkraken://), GitKraken should be used to handle that action.
This would allow the browser to hand the code generated by the authentication process back to GitKraken, so the OAuth process could be completed within the app.
The process for this flow would simply be: the user (or on a larger scale, the user’s IT department) would add a single configuration file within the GitKraken settings directory, and then click a connect button in-app, in a fashion very similar to the current GitHub.com integration. This idea works best on a large scale where there’s an IT department willing and able to automate the process for the user.
3. Use Personal Access Tokens.
GitHub (and lots of other services, actually) allow you to generate a token that can be given the same subsets of permissions as OAuth tokens and can be used in much the same way. Once we have one of those tokens, it can be used in place of an OAuth token that we’d get by performing the authentication process through GitKraken’s API server.
It requires some extra configuration on the user’s part, but given that we need to know where the GitHub Enterprise server is located, some extra configuration is necessary, and there are ways to make that configuration quite painless.
Decisions
The IT-facilitated configuration route (2) and personal access tokens (3) were the two options that were considered most heavily. We eventually settled on personal access tokens as a great starting point for the feature.
This is because of not only the relative ease of implementation but also because it isn’t predicated on the assumption that all GitHub Enterprise users will have an IT department capable of automating the process for them, by creating the configuration file and injecting it into the user’s GitKraken settings.
Personal access tokens also don’t preclude the use of the config file, so it’s something we can expand on in the future for much larger teams if there is significant demand for a slightly more streamlined process.
Another important part of making personal access tokens as simple as possible is making sure that it requires as little user interaction as possible. Unfortunately, we have to direct users to a page with a somewhat overwhelming number of options:
It would be great to try to simplify the process by filling this form out for the user, and not making them have to go back and forth to make sure they have all of the necessary scopes.
We couldn’t find any documentation to support the theory that there might be a way to automatically check those boxes, but if working with GitHub APIs has taught us anything, it’s that they’re really good about making a lot of things dead simple to figure out, even in the absence of documentation.
After a tiny bit of fiddling, we discovered that you can check those boxes and specify a description default, by simply passing a couple of query string parameters. Thanks, GitHub!
Execution
Once personal access tokens were in place, GitHub Enterprise was almost literally a drop-in replacement for GitHub.com at the API level. Seriously, the package that we use to handle fetching and updating user info, repositories, pull requests and SSH Keys, just worked when pointed at a GitHub Enterprise server, instead of GitHub.com, and when given a personal access token instead of an OAuth token. Which is awesome! It means most future integration points we add to GitHub.com will likely automatically work in GitHub Enterprise for free.
I’ll keep this short and sweet. Here are the 10 most recent tips we’ve shared on Twitter!
And if Twitter just isn’t your thing, we’ve started producing quite a few tutorial videos for learning Git and leveraging GitKraken to become a more productive Git user. So, subscribe to our YouTube channel to keep up with those series!
GitKraken Tips
Use the Pull dropdown menu to run different fetch/pull operations and set the default button action.
Labels for the main toolbar buttons can be turned on/off in Preferences > UI Preferences.
Stashed changes appear in the left Stash panel, where any stash can be applied, popped or deleted.
Click the + next to Remote to quickly search for and add a GitHub remote, without ever leaving GitKraken.
Repo actions (stage, fetch, branch, etc.) can also be done from the Command Palette using cmd/ctrl + shift + p
Initialize a repo using the GitHub integration, to quickly create a new repo on GitHub and clone it to your machine.
In the left panel, graph, and also between the two, you can drag-and-drop branches to quickly merge or rebase.
Use search to find a commit you’re looking for. Press Enter to cycle through results in the graph and Esc to clear.
Hover over label icons in the graph to see remote names and info about PRs on a branch.
Type a commit message in the graph, then cmd/ctrl + enter to commit staged files, or cmd/ctrl + shift + enter to stage all files and commit.
There may be some misconceptions floating around out there about what actually happens in a dev room. Walk down the corridor and poke your head through the door. That lush smell of freshly laundered clothes and lavender; the bright, tidy decor refreshingly lit by natural sunlight.
Now head next door to the dev room. It’s dark in there. They need to work, and that means pure, dark, focus without the distractions of the outside world. There’s a certain allure of a dark room filled with enormous monitors (BTW, you’re not a true dev unless at least one monitor is in portrait) and the constant click-clack of the keyboard.
Coding is hard. And the golden rule is keep your code as clean as possible. So, what then do devs do to chill out for a second? Are there more to devs than cliches of Cheetos, Mountain Dew and stray ‘dev hairs?’ (don’t ask)
Here are 5 insights into the complicated and sometimes-terrifying minds of our devs, and possibly yours.
1. Naming Conventions
Contrary to popular belief, devs do not typically name their files silly words or throw inside jokes into their code just for kicks. If you do this and think you’re super clever, just stop.
It might be funny in the moment, but then you’ll revisit that file in a month and find it’s just silly, distracting nonsense, and EVERYONE WILL HATE YOU.
However, there’s always a time and a place. If you’re testing your code, go ahead and use mock-yet-functional values where is doesn’t matter. Perhaps you want to use all the classifications of nuts: Pine, Hazelnut, Kola. Macadamia is a favorite here at Axosoft. Just remember, this practice is only kosher if you’re testing; in which case, go “nuts.”
If you want to use your creativity in naming conventions, feel free to name new features. Enter: Rickscroll, the Slidy Panel, Loadyspin, A Spinny Bob, and the famed, NSFW.
2. Slack Channels
We are happy users of Slack here at Axosoft. We have channels for everything that helps us be more productive! But, if you dig far enough, you’ll find the “Dark Slack,” an underground network of channels that are full of sordid nonsense and alternative methods of discourse.
For example, some devs have been known to get kicked out of a Slack channel and held hostage, only to watch gifs scroll by that are directed at them.
Witness all the crazy gifs directed to a certain dev, and note, that dev was not invited to the channel.
#Random became so random that it broke through the channel, and resulted in an additional degree of random: the dreaded #chaos channel.
These channels serve as welcome distractions when you come up for air from coding, and a random bit of light-hearted nonsense is sitting there waiting for you.
3. The Easter Egg that Tastes a lot like a Burrito
If you’ve been using GitKraken, our Git GUI, you may have noticed a “Chipotle button” on a random Thursday afternoon. Your eyes have not deceived you. We added this button out of pure necessity.
Every Thursday Axosoft employees go online, order Chipotle, and then a volunteer picks up the large order and brings it back to our office. Shout out to Jonathan, our most dedicated Chipotle runner! This Thursday tradition has been going on literally for years.
As you know, there are multiple Chipotle locations, and if you don’t carefully save your order history, you might end up ordering from the wrong one. Or worse, if you’re in the middle of coding and don’t place your order before the deadline, you might not even get Chipotle at all!
Enter, the Chipotle Button. It was created by an innovative (and hungry) dev who needed an easier way to get this process done. Initially, the button was only part of our internal dev version of GitKraken. Then we thought, ‘wouldn’t every dev love to enjoy our tradition of Chipotle Thursday?!’ And just like that, we pushed the button live.
@GitKraken a chipotle button? I love chipotle and gitkraken, but ads disguised as UI is sleazy. If this is a joke, it’s not funny.
So to answer all you inquisitive Tweeters, the answer is ‘no, we are not advertising for Chipotle’. We just really like it, okay?
4. Pranks
Devs are a tight group. So, the fast track to being accepted and then, eventually, trusted, is through the tried and true prank. After all, what says “I love you and I’ve got your back” better than premeditated suffering and inconvenience?
Have you tried taking the tiniest little strip of tape and sticking it to the bottom of someone’s mouse? It’s a classic because it works. Nothing like being geared up for a big day of coding and not being able to move your mouse. Listen with quiet anticipation, for frustrated and confused grunts. Fiddle with your Bluetooth settings all you want, pal, ain’t gonna work!
Another favorite is using a wireless keyboard to connect to someone’s desktop. Torture them intermittently by typing random keystrokes that they are seeing, but not creating. Delight remotely, but together, by creating a private Slack channel that the victim isn’t invited to. Public humiliation is really the best, amiright?
If you’re really lucky, a dev or two will go on vacation for at least a week, giving you enough time to wrap their entire desk set-up in cling wrap and suspend it from the ceiling.
Own that prank like the true astronaut that you are.
You may even come out of work one day to find that your car has been PlastiDipped Pink.
Plasti Dip a car pink? Sure, why not.
Watch out, because you could fall victim to finding your keyboard encased in Jello after you ask, “why aren’t there any creative pranks here?” So, good luck and don’t ask questions.
5. Celebrating Releases
After a release, it’s time to celebrate. What’s more fun than taking a shot (yes, just one) at the foot of the almighty Squidpope (the dev that has been designated to answer product questions throughout the week.)
Cheers to you, our fellow devs! Keep doing what you gotta do to get the job done.
Ready to learn something new or brush up on your Git knowledge and skills?
In the short video below, Chris, a software developer at Axosoft, breaks down the mysteries of the SSH key. You’ll finally get answers to questions like, “what is an SSH key?” and “how does SSH work?” This is great info to know when you need to authenticate your app to a remote service.
Stay tuned for more helpful videos for learning Git!
Often times, high caliber tools can be cost prohibitive for students. That’s why GitHub—home to the largest open source community in the world—is collaborating with partners like Axosoft, to solve this problem.
We are super excited to announce that GitKraken Pro, our luxurious Git GUI client, is now available free of charge for students as part of the GitHub Student Developer Pack. GitKraken joins the ranks of notable development tools such as Atom, Microsoft, Stripe and Unreal Engine, to name a few.
At Axosoft (the creators of GitKraken) we have always been strong proponents of education in the tech space. In addition to providing educational resources for students, Axosoft has continuously worked hard to provide free tools aspiring students need to advance their development skills.
If you’re already using GitHub to host your repositories, you’ll be glad to know that GitKraken integrates with GitHub. This means you can work collaboratively on a GitHub-based remote repo without switching back and forth between your Git client and your web browser! And when you’re working in GitKraken, you can create pull requests from within the app.
Students also get access to GitKraken’s built-in merge tool with syntax highlighting, and because you’re getting Pro features, you have access to the merge tool editor. This robust output editor enables you to fine-tune your code without ever leaving the app.
So, stop switching between tools; now you can seamlessly use GitHub with GitKraken to concentrate on the task at hand and not have to worry about pulling yet another all-nighter to meet your deadline!
Hey, Git users! Welcome to another lesson in our Git tutorial series. In this video, Justin, an Axosoft designer, will walk you through the basics of remote repositories. By the end, you’ll be able to answer the following questions:
As part of a project I’m working on here at Axosoft, I’ve been producing tiny SVG animations. I use Sketch to produce SVGs that I then bring into my HTML and animate with CSS.
SVGs are essentially XML documents; they can be presented as inline code and then referenced in the DOM, just like any other element. Although there are some restrictions here and there, you can go to town manipulating SVGs with CSS and/or JavaScript to create self-contained animations that can look good on pretty much any device.
I’m going to share my process, with examples, so you can follow along to create your own animations without too much math-headache.
Let’s get started!
Step 1: Building out your SVG in Sketch
For the sake of brevity in this guide, I’m going to assume that you have created your image in Sketch already. However, there are a number of things to double-check for good measure prior to exporting your SVG:
Ensure that you have uniquely named the layers or objects that you intend to animate. This will make things much easier for you, as you’ll be able to quickly find those elements in the SVG code and easily reference them in the CSS. It’ll also ensure that they don’t get merged into one path by the SVG optimizer we’ll use later.
We are not going to work with hiding/showing elements of the SVG in this article but remember that Sketch will not export hidden layers, so even if you intend to hide a layer at the outset, you’ll need to have it visible in the export and hide it with CSS later.
Group all your layers into one wrapper layer. This is the layer we’ll export.
Now, you’re ready to export your SVG! Select the layer into which you just grouped your items. In the bottom-right corner, click Make Exportable and select SVG as your format. Click Export and Save.
Step 2: Optimize the SVG
Sketch writes pretty nice SVG code, but it is possible to optimize the code a little to save some valuable KBs. As we all know, less KBs will help with faster page rendering.
There are several options for SVG optimization. The SVGO GitHub page is home to a Nodejs-based optimizer but also lists several variants for other needs, including a web app version, SVGOMG, which we’ll be using here.
Go to SVGOMG and upload your image. Once uploaded, you can change your optimization settings and it’ll rerun in real-time. I have selected most of these options, including the Multipass option, but I have left the Clean IDs option deselected (that’s important!), as well as the Prefer viewBox to width/height and Shapes to (smaller) paths.
A Quick Note on Sketch and Transforms
When exporting SVGs, Sketch positions elements using the transform attribute, which is accessible by CSS3’s transform property. This is pretty cool; it means you can manipulate your objects in Sketch, reference their new transform properties and use that in your CSS code. This is why the Shapes option above is not selected, as it would remove those attributes.
If you would prefer to work with relative transformations (e.g. the initial translate coordinates of each object would essentially be 0,0) you can select that option, but bear in mind you’d also need to ensure that all your layers in Sketch have been flattened (go to Layer Paths Flatten) for that to work as expected in SVGOMG. (Shout out to Rutger Laurman for his Sketch tip tweet!)
Back to our SVGOMG cleanup, and there’s a download button in the bottom-right of the UI that also shows how much smaller the file size has become through its stripping down of the code. In my example, it’s saved a decent 36.6% – nice! You can download your new, leaner SVG file, but for this example, it’s easier to copy the code straight to the clipboard by clicking the button directly above the download button.
Step 3: Using the SVG Code
You can now paste the SVG code into a code editor, or open it (if you downloaded the file). In my example, I’m pasting this code into CodePen. You can see our first Pen here:
In this example, I’ve added a little CSS to tidy things up, but apart from that, nothing is affecting the inline SVG code directly at this point.
In the image below, I’ve highlighting the bounding box of the groups/objects I want to animate.
We’ll animate the bounding boxes of the elements
Step 4: Let’s Transform!
Now it’s time to actually animate some of the SVG elements. We’re going to have the sprint card move down the conveyer belt, and the ribbons are going to flick just a little for a more realistic effect.
Going back to our Sketch document, we can see that the card is situated at 485, 99 (x, y). Moving it down to our desired finishing position puts it at 6, 383. If Sketch has not exported these values as a transform attribute (which it doesn’t always do), we can treat them as 0, 0.
The transform coordinates of the moved card
We can now go to our Pen and add a simple bit of CSS to see how easily this transformation translates into CSS.
There are two ways we can animate our SVG elements. The first is to use only CSS and no JavaScript, with animation and @keyframes controlling our animations on page load. For brevity, we’re going to use just a little vanilla JavaScript to attach a class to the SVG that triggers the animation. Note that we could also apply the animation to a :hover state over the SVG, and this would also require no JavaScript.
First, we grab the element’s ID from the DOM:
var animElement = document.getElementById(‘Sprint_Card’);
Now we can add our class to the element:
animElement.setAttribute(‘class’, ‘active’);
Next, we modify our CSS to apply the transformation to the sprint card element, only when it has an active class.
Time to rotate those ribbons! We can now repeat the approach we took above. However, this time, Sketch has not carried over the translate values. This sometimes happens, but it’s not a total bummer. We’re just going to apply some arbitrary transformations in our Pen to eyeball the results.
Gah! That’s not right! It’s pulled itself out of the machine! That’s because we haven’t set a transform-origin property to our element, so it’s spinning from the center of the object by default. We’ll apply a new origin to both ribbon elements at once:
#Ribbon_1,
#Ribbon_2 {
transform-origin: right top;
}
This plots our rotation at the upper-right corner of each element.
I like how the rotation looks on #Ribbon_1, so I’m going to double up on that style and do it for #Ribbon_2 as well, and then consolidate:
#Ribbon_1,
#Ribbon_2 {
transform-origin: right top;
transform: rotate(5deg);
}
Now we can finish up by applying a similar process as before. Again, we could use animation with @keyframes and transition delays, but we’re going to use JavaScript to add, then remove, an active class to which we’ll apply transform. We can also more explicitly control the quick move and return animations this way.
In the final, finished example, we’ve added a transition property to the elements, moved the transform to the active class of those elements, and used JavaScript timers to add, then quickly remove the class to give the effect of a quick ribbon movement.
That’s it! Hopefully, this shows how straightforward it is to create self-contained, lean animations with Sketch and a little CSS and JavaScript. Next, you could try doing this again without the JS!
Hey, Git users! Welcome to another lesson in our Git tutorial series. In this video, John, an Axosoft developer, will teach you about squashing commits. Tune in to find out:
Depending on who you ask, 2016 kind of sucked. Some high profile deaths like David Bowie, Alan Rickman – even Prince, for goodness sake – have left us pretty bummed out. It’s against this calamitous backdrop that I introduce 4 tech products that also left us, perhaps too early?
Samsung Galaxy Note 7
In August, Samsung released the mother of all phablets, the Galaxy Note 7. With excellent specs, a dreamy blue color variant and an improved S Pen, it looked like the hottest phone on the market, until it literally became the hottest, most explodey phone on the market!
Users started reporting that their phones were exploding. Samsung introduced a global recall, at great expense, and hurried out a ‘safe’ replacement.
You know where this is going… They failed to tackle the whole ‘exploding’ part. So, more phones burned up, and faster than you could say “wait, I’m sure we had a billion dollars more than this,” the Note 7 was banned on flights and finally discontinued permanently. Some people (not Samsung) saw the funny side and even made a GTA V mod where they replaced bombs with Note 7s (there are some extremely violent demos on YouTube if you’re interested).
Samsung was not amused by this GTA mod
The debacle was actually a real shame. Aside from the fact that these phones were explosives waiting to detonate without warning—possibly right next to you as you slept in bed—the Note 7 was an excellent phone, with a design to rival Apple’s best efforts. It was the kind of contender in the market that pushes others to innovate. It was a smoking phone. It blew the others out of the water. RIP Samsung Galaxy Note 7.
Note: Things got even worse for Samsung in November after a number of their washing machines started exploding too. That’s right: yet another device you won’t be able to take on an airplane. Fantastic.
Vine
Twitter’s six-second, looped, video clip service was one of the ultimate creative constraints. Vine became the source of many strange, useless and hilarious videos, often made funnier by their short looping. In October this year, Twitter stopped allowing new Vines to be uploaded to the service.
It’s such frustrating irony that a six-second Vine would probably prove the perfect medium through which to express the sorrow at Vine’s demise.
Here are some fun memories, best enjoyed with sound:
The Headphone Jack
In a divisive move, Apple released the new iPhone 7s in September, sans headphone jack. Apple’s Phil Schiller sounded more than a little like a Silicon Valley character when he attributed the axing of the jack to having “[the] courage to move on and do something new that betters all of us.”
Apple has a history of getting rid of technologies it deems out of date, and to their credit, the company often makes the right call, helping to push the market forward (anyone still using a floppy disk or optical drive in their machine?). Only time will tell on this one, but the pricey and delayed Airpods haven’t helped many people warm up to the idea, yet.
Function Keys
Drunk on courage, the Apple team then went on to banish the function keys on most of the new MacBook Pros to the annuls of history. Now, the new Touch Bar provides an OLED touch screen to offer contextual touch keys.
The MacBook Pro touch bar
This isn’t a deal-breaker for most people, but some people may find themselves lamenting over the lack of a physical Esc key (here’s a decent tip for getting around that) and the reassuring clickety-clack of the function keys. However, designers (and potentially coders, when support for the bar catches up) might find the contextual touch keys a real time-saver when flicking between tools or performing repeated tasks.
I’ve played with this, and it’s actually a really practical hardware revision. Still in its infancy, it needs more active third-party support, but it already has the Apple stock apps covered. Plus, third party developers are starting to jump on board. This useful post rounds up currently supported apps!
Sure, the Touch Bar presents another piece of software that could crash, but, that also means it’s another piece of software that can be hacked:
Hey there, Git users! It’s time for another episode in our Git tutorial series. In this video, Brett, an Axosoft developer, will explain what submodules are and when you should use them.
One of the great things about GitKraken is that it is available on all three major computing platforms, and it looks the same on all those platforms. This is a real boon to those devs working across locations, machines and/or operating systems, as they can launch that same familiar UI no matter which system they’re using.
Building Cross-Platform
This cross-platform consistency is all thanks to GitKraken being built on Electron. The underlying Node.js code is mostly platform independent, but what we do with that code to build the app is very different depending on the target operating system.
We need to build the application three different times, on three different platforms, and we need to build it often, frequently, and continuously. We are an agile company, so we position ourselves to always be shipping new code. Be it a new feature, or a nasty bug fix, it needs to go out quickly and with confidence.
Continuous Integration
When we build, the key to success is our continuous integration (CI) pipeline, and the beautiful world of automation.
There are numerous companies that offer automated build systems as a service. We currently utilize the CI SaaS services from both TravisCI and AppVeyor. These solutions allow us to have faster setup times and almost zero hardware or administrative costs. TravisCI builds both our MacOS and Linux builds, while AppVeyor handles the Windows side of things.
SaaS vs On-Premises
Of course, there are advantages and disadvantages to choosing SaaS over an ‘on-premises’ solution. Giving up absolute control of our builds can be a daunting prospect, and customization is a lot harder when we no longer own everything. With a custom setup, we can ensure reliability by architecting something that is as complex (and expensive) as we choose. With services, we need to put our faith in that provider.
There is also the flip side to zero sunken costs: Recurring monthly invoices. Regular costs, spreading out to infinity like a beautiful college loan debt. But, as any good therapist will tell you, compromise is the name of the game, and for our current needs, CI SaaS is the way to go.
Source Control
For CI to work well, we need to keep our code repository as the one source of truth. Source control is an amazing thing.
We keep all build steps in the repo. Every single strange configuration setting that is required for a successful build lives right next to every strange workaround our code needs to complete a task. Version control keeps everyone on the same page and, to get technical for just a second, keeps the crazy away. What happens when Philip the Build Engineer decides he wants to travel around with a circus in the Rust Belt? Nothing. Because all of the tribal knowledge and its history is right there in the repo.
I know what you are thinking: “We don’t store secrets in the repo!” That’s a good mantra. It’s the one exception to keeping everything in the repo. Our secrets are… well… secret. There are two approaches we follow when dealing with the hushed whispers.
Our first approach is to encrypt the secret and store it in the repo. (Remember, we love the repo!) Any kind of file like a signing certificate or access key can be encrypted using another secret and then safely committed. We try really hard to keep everything in version control.
The second approach is to securely transfer the secret to the SaaS platform. Variables are then inserted during build, and our software can utilize them freely to decrypt or authenticate.
Automate All The Things
The CI process can seem daunting and overwhelming at first, but don’t fret, it’s all in the repo! Any team member can hop into the source and look at the various YAML files that define exactly what will happen during the builds. And the joy of automation is that it is… automated. There is no manual interaction that needs to take place. If there is, you’re literally doing the opposite of automation. When the build fails, it’s failing due to a newly introduced code error, not because Francis forgot to set a vaguely defined, yet required, build option.
We don’t even want the pressure of telling the systems to start the build. As you may recall, these are continuous builds. Who has the time to fire them off by hand when GitHub hooks are always listening? When code is committed to our repo, the GitHub hook fires off an event to our provider and a build is triggered. Easy-peasy. Set it, and forget it.
Our mantra is that if it can be automated, it should be automated. If you are doing something manually, you better be sure it is documented inside and out. But even then, we’ve noticed that as soon as documentation is published, it’s pretty much already outdated. If it’s outdated and something breaks, your entire CI process is broken. So, automate!
If you have a manually executed step, someone needs to own it. “Don’t worry,” you say. “Paulette does that step,” you promise. But Paulette is on a cruise in the South of Italy, remember? Automate! Everything needs to be repeated. Everything needs to be repeated. Everything needs to be repeated. Automate!
An automation flowchart for you.
We may spend some extra time at the very beginning, making sure the process is solid and automatically reproducible, but that time investment pays off tremendously time and time again once that reliable process is in place.
If it’s not automated, it’s not continuous. If it’s not continuous, it’s not iterative. And if we aren’t iterating, we are stuck in time.
Out of the box, WordPress offers a pretty decent spread of editor buttons to make your posts look good and read well, thanks to its use of the TinyMCE editor. However, if your blog has multiple contributors, each with varying degrees of HTML knowledge, you’re going to need to get creative to avoid those contributors creating a mess.
This is where learning how to build shortcodes in WordPress comes in. Building a shortcode or two will allow contributors to add more complex pieces of content to your blog without the headache of formatting or–gasp!–coding.
In my role at Axosoft, I’ve needed to create some buttons that help contributors insert various repeated content types. A good example is the blockquote. Citing an author and a URL can make this a potentially messy process when different people are writing. The TinyMCE editor can be a little quirky in the wrong hands, and we want things looking consistent across our posts.
So, I’m going to show you how to create a shortcode that removes the heavy lifting of coding a blockquote with a citation and automates it for the author. Rather than using the blockquote button that comes with the TinyMCE editor by default, authors will be able to use the simple blockquote we create, to add an author, citation, and link (all optional) and be done. It will end up looking like this:
Donec rutrum congue leo eget malesuada. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Donec velit neque, auctor sit amet aliquam vel, ullamcorper sit amet ligula. Vivamus suscipit tortor eget felis porttitor volutpat.
For simplicity, I’m going to do all the work in our theme’s functions.php file. I would recommend getting granular with function files so you can keep organized. (In the Axosoft theme, we have a functions folder, with a shortcodes.php file, and we require it from our main functions file.)
WordPress’s shortcode API has the info you need for reference. We’re keeping the shortcode functionality itself pretty simple; a shortcode with attributes, but none of those attributes have defaults.
Okay, let’s learn how to create that shortcode in our WordPress theme!
We need to create two things:
A function that handles our shortcode.
A call to add_shortcode, which registers that shortcode and ties it to the function, so it’ll be parsed.
By default, we have no attributes and no content defined. However, when the shortcode is parsed, it will at least have content passing into the function.
Next, we’ll register this function by calling add_shortcode:
The function has two parameters. The first defines the shortcode in the square brackets. In our case, we are going to make shortcode simply called blockquote. The second parameter is the function we’re tying to that shortcode.
Inside the function, we’ll set up our content as the variable $output, and then return it at the end. We’ll start with opening and closing figure tags:
At the most basic level, this will work. It’ll insert the tags and place the content inside the blockquote tags. However, this is not much different from using the built-in button in WordPress. Let’s add some attributes that give authors a bit more power with their quotes.
We’re going to have 3 optional attributes:
author: the person to whom the quote is attributed.
cite: the name of the source; for example, The Verge.
link: the URL of that source.
Here’s where we need to do some planning. We want to allow our authors to add an author, OR a citation, OR both. We can safely assume that if both of these attributes are missing, we do not need to append our figure tag with any source information. So, let’s create a wrapper that takes that into account:
Simple, right? But hold on, we need to plan ahead. We might have a link but no cite defined, in which case we want to wrap the link around the author. Let’s allow for that scenario:
Next, we can work on our citation. Since we only wrapped the author in a link if there was no cite attribute defined, it’s less complicated working with the citation and links. It’s all pretty straightforward.
If there’s a citation, we open the <cite> tag, check for a link, and open the <a> tag if one exists. We add the citation wording, close the link, and close out our <cite> tag.
Bringing it all together in our function, we have the following:
And here’s how it looks (of course, you can style your output however you’d like):
Donec rutrum congue leo eget malesuada. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Donec velit neque, auctor sit amet aliquam vel, ullamcorper sit amet ligula. Vivamus suscipit tortor eget felis porttitor volutpat.
That’s it! You’ve learned how to register a new shortcode in WordPress and allow for attributes to be defined within it. This should make your various contributors only have to use a simple piece of shortcode to output code that would otherwise potentially get messy.
I’ll be following up on this post with a second post, where we will create a custom TinyMCE button that will offer a UI for the attributes and then generate this shortcode automatically!
A new year is fast approaching, and many people are setting their intentions to become a better version of themselves in 2017. The Axosoft product team has been hard at work getting Axosoft in shape to be even better too!
We’re excited to announce a fresh, new look for Axosoft! That’s right, Axosoft v17 has an updated UI and enhanced UX, which makes it easier than ever before to onboard new users and streamline your actions in-app.
Watch this quick video or keep reading to get an overview of what has changed and what’s brand new!
Organize Panel
First, we have updated the panels and the main workspace. The overall placement remains the same but you’ll notice elements have been re-styled. Also, search is now available for all panes in the Organize panel.
The menus have been replaced with a vertical ellipsis that houses all pane options. So for example, if you select a project, you can either right click to edit or click the ellipsis to edit.
Main Workspace
The main workspace has been simplified and redone. The options for List View, Card View, Rank View, and Sort by rank, have been consolidated in one location next to the refresh icon.
The Add, Edit, and Workflow menus remain in the same area, but the Filters menu is now located in the upper left of the UI. Any active filters will be shown here, in the filters bar.
Also, the Print and item reports are now located under the Moremenu.
Details Panel
Similar to the Organize panel, use the ellipsis symbol to access more options in the Details panel.
You’ll notice that the Details panel now displays a the number of comments, related items, and attachments, instead of a dot symbol.
Kanban Card View
If you access the kanban Card View, you can now check the box in the top-left corner to select each card. Use this to multi-edit items like you do in the List View. We have also included icons with the number of comments, subitems, or attachments, in the upper-right of the card.
Tabs
Tabs have also been updated! Click the + to add a tab, and you’ll see that your tabs are now organized into several categories: built-in Axosoft tabs, your personal tabs, and public tabs that are shared with your team. The option Duplicate Current Tab was moved to the top, so you can quickly make a copy of what you see, make any additional modifications, and then save it for later.
Command Palette [New Feature]
Say hello to this new feature: the Command Palette!It’s easy to access with the keyboard shortcut shift + p. The Command Palette is your fastest way to access sub-menus inside of Axosoft. For example, if you want to add a user, search “user” in your Command Palette to jump to the Users menu.
You can always use the Tools menu too, if you need to dive into the Configurations menu.
Mobile Beta Site [New]
You can still access our old mobile site, but our new mobile beta site has has a fresh look; plus, sprint details and an activity feed. Using the beta site, you can review burndown charts for your active releases, items in your projects and releases, and get an activity feed of your most recent changes.
Note: The current mobile beta site only provides data for your Work Items and Feature item types.
Well, that about covers what’s new; for more details, check out the v17 release notes. If you have feedback about any of these updates, especially the UI, please fill out your in-app survey!
