• Getting started with Git and GitHub is easier than ever with GitHub Desktop 2.2



      Anyone who uses Git knows that it has a steep learning curve. We’ve learned from developers that most people tend to learn from a buddy, whether that’s a coworker, a professor, a friend, or even a YouTube video. In GitHub Desktop 2.2, we’re releasing the first version of an interactive Git and GitHub tutorial that can be your buddy and help you get started. If you’re new to Desktop, you can download and try out the tutorial at desktop.github.com.
      Read more →
    • Family tree inside Git

      • Translation

      Happy programmer's day! I wish you more bright commits, merged pull requests, less merge conflicts, and that your life branches remain relevant as long as possible. As a conceptual gift, I propose the implementation of a family tree by means of the Git version control system. Well… sounds like a plan!



      For those who have immediately understood everything, I give links to the source code: GenealogyTreeInGit and family trees: mine and US presidents.


      In addition, I implemented a simple social graph. It displays not only the degree of kinship, but also the status of relations between descendants, events such as wedding, divorce, childbirth, as well as contributions to the relations.

      More about implementation, details, and pictures
    • GitHub Package Registry will support Swift packages

        On May 10, we announced the limited beta of GitHub Package Registry, a package management service that makes it easy to publish public or private packages next to your source code. It currently supports familiar package management tools: JavaScript (npm), Java (Maven), Ruby (RubyGems), .NET (NuGet), and Docker images, with more to come.

        Today we’re excited to announce that we’ll be adding support for Swift packages to GitHub Package Registry. Swift packages make it easy to share your libraries and source code across your projects and with the Swift community.

        Read more →
      • C# or Java? TypeScript or JavaScript? Machine learning based classification of programming languages

          GitHub hosts over 300 programming languages—from commonly used languages such as Python, Java, and Javascript to esoteric languages such as Befunge, only known to very small communities.


          Figure 1: Top 10 programming languages hosted by GitHub by repository count 

          One of the necessary challenges that GitHub faces is to be able to recognize these different languages. When some code is pushed to a repository, it’s important to recognize the type of code that was added for the purposes of search, security vulnerability alerting, and syntax highlighting—and to show the repository’s content distribution to users.

          Linguist is the tool we currently use to detect coding languages at GitHub. Linguist a Ruby-based application that uses various strategies for language detection, leveraging naming conventions and file extensions and also taking into account Vim or Emacs modelines, as well as the content at the top of the file (shebang). Linguist handles language disambiguation via heuristics and, failing that, via a Naive Bayes classifier trained on a small sample of data. 

          Although Linguist does a good job making file-level language predictions (84% accuracy), its performance declines considerably when files use unexpected naming conventions and, crucially, when a file extension is not provided. This renders Linguist unsuitable for content such as GitHub Gists or code snippets within README’s, issues, and pull requests.

          In order to make language detection more robust and maintainable in the long run, we developed a machine learning classifier named OctoLingua based on an Artificial Neural Network (ANN) architecture which can handle language predictions in tricky scenarios. The current version of the model is able to make predictions for the top 50 languages hosted by GitHub and surpasses Linguist in accuracy and performance.
          Read more →
        • New feature in Git 3: closures

          • Translation

          Git is a popular version control system. In Git, an atomic change of one or several files is called a commit, and several consecutive commits are combined into a branch. Branches are used to implement new ideas (features).



          It happens that the idea is a dead end and the developer has turned the wrong way, so he needs to roll back to the original version. He should forget about the new branch, switch to the main dev or master branch and continue working. In this case, the "scion" will hang forever, as well as the desire to remove it. But how to remove the part of the history? This branch shows the efforts of the hard-working programmer, even if in vain. So it will be easier to report to the boss, because an unsuccessful result is also a result!


          I hasten to rejoice that Git developers are going to introduce a new command to close such "homeless" branches in the third version. The current version is 2.21.0.


          How to use this command, what benefits does it give and what do IT companies think? The article answers these and other questions.

          Read more →
        • How to vendor a git into another git

            Discovering git vendor extension.


            Cross-post from my medium blog: https://medium.com/opsops/git-vendor-295db4bcec3a


            I would like to introduce the proper way to handle vendoring of git repositories.


            What is is ‘vendoring’?


            Vendoring is a way to integrate other’s work into your own. It’s the opposite of ‘linking’ against third-party library. Instead of having that library as a dependency, application uses this library as a part of own source code and keep that code ‘inside’ itself.


            Normally, vendoring is done by language tooling: bundler, cargo, pip, etc. But sometimes you need to vendor something not covered by any existing toolset, or something multi-language, that it’s impossible to find the ‘core’ language tool for that.


            The solution for this situation is vendoring on a git level. You have your own git repository (I call it ‘destination repo’), and you want to incorporate some other repository (I call it ‘source repo’) as a directory into your (destination repo).


            The things you expect from a well-designed vendoring system (regardless of Git it is or not):


            • Visibility. You want to know that some code is vendored, means it wasn’t written by committer.
            Read more →