渡辺 あすか

渡辺 あすか

1658178000

git-storyを使用してGitコミット履歴をアニメーション化する

多くの場合、開発者はコードプロジェクトの側面を視覚化すると便利です。これは、チームのワークフローを理解することが不可欠なGitのようなバージョン管理システムに特に当てはまります。

Gitでこれにアプローチする1つの方法は、上記のようなグラフを描くことです。

Gitの使い方を学ぶときに、このような画像に出くわしたことがあるでしょう。

このグラフは、Gitリポジトリのサンプルコミット履歴を示しています。

Gitでは、コミット履歴はDAG、つまりネットワークグラフの一種である有向非巡回グラフとして表されます。各コミットは円で表示され、コミットは矢印を使用してチェーンされます。各矢印は、子コミットからその直接の親を指しています。

ほとんどの場合、これらのグラフの1つが必要な場合は、自分で（手動またはデジタルで）描画する必要があります。これには時間と労力がかかります。また、これらのグラフは静的であり、特定の場合には、ビデオ形式でコミットの進行をアニメーション化する方が魅力的です。

これらの理由から、Git Storyを作成しました。これにより、Gitコミット履歴のレイアウトと進行状況を示すmp4ビデオを、すべて1つのコマンドを使用して簡単に生成できますgit-story。

Gitの改訂履歴を視覚化する方法

Gitでは、コミットはリビジョンとも呼ばれ、特定の時点で特定の人によって行われた一連のコンテンツ変更を表します。

Gitの履歴を視覚的に理解するのに役立つ追加のコンポーネントがいくつかあります。

コミットプロパティ

Gitにコミットするときは、人間の読みやすさが重要です。したがって、変更を説明する明確なコミットメッセージを残すことをお勧めします。これは、コミット履歴を表示している他の開発者が各リビジョンの目的を理解するのに役立ちます。

コミットIDは、各コミットのコンテンツから特別に生成された、各コミットの一意の識別子です。Gitユーザーとして、多くのGitコマンドが引数として完全または部分的なコミットIDを受け入れることをおそらくご存知でしょう。そのため、GitビジュアライゼーションでコミットIDを使用できるようにしておくと非常に便利です。

参照：ブランチ、HEAD、およびタグ

Gitの履歴を視覚化するときは、自分がどこにいるかを知ることも役立ちます。Git refs（参照の略）は、Gitリポジトリでコミットがどのように編成されているかを理解するのに役立ちます。

参照は、Gitが特定のコミットに添付するラベルです。ブランチ名、Git HEAD、タグはすべてGitの参照の例です。refは、特定のコミットを指す人間が読める名前と考えることができます。

Gitストーリービデオ出力

Git Storyは、コミット、関係、参照など、このすべての情報を解析し、.mp4ビデオとしてアニメーション化します。最良の部分は、ターミナルでプロジェクトを参照してコマンドを実行するだけgit-storyです。

以下は、GitStoryによって生成されたビデオアニメーションの例です。

Gitストーリーの例の.mp4ビデオ出力

 

PythonでGitストーリーを書いた理由

このプロジェクトを強化する2つの非常に便利なライブラリがあるため、PythonでGitStoryを作成することにしました。

GitPython

1つ目はGitPythonと呼ばれます。GitPythonは、便利な一連のメソッドを介してGitリポジトリからのデータへのアクセスを提供するPythonパッケージです。これは、GitStoryがアニメーション化するためにローカルGitリポジトリからのデータにアクセスする方法です。

import git

repo = git.Repo(search_parent_directories=True)

これにより、Pythonプログラムのメモリ内にリポジトリオブジェクトが作成され、基になるGitオブジェクトとそのプロパティにアクセスできるようになります。コミットのリストには、次のようにアクセスできます。

commits = list(repo.iter_commits(REF))

# This pulls a list of commits working backwards from REF
# REF can be a branch name, tag, HEAD, or commit ID

コミットのリストを反復処理すると、アニメーションを生成するための次のステップで使用される各コミットのプロパティにアクセスできます。

私に

2番目の依存関係はManimと呼ばれ、PythonAPIを使用してアニメーション化された数学ビデオを生成するために使用されます。Manimを使用すると、線、形状、テキスト、方程式を表すPythonオブジェクトを簡単に作成し、それらのオブジェクトをアニメーションシーンに配置できます。

Git Storyは、Manimを使用して、GitPythonを使用して取得したGit履歴の一部を表す円、矢印、テキスト、Gitブランチ名、および参照を描画します。

PythonコードがManimを使用して、コミットごとに赤い円を作成する方法は次のとおりです。

circle = Circle(stroke_color=commitFill, fill_color=commitFill, fill_opacity=0.25)

そして、これがManimを使用してコミット間の矢印を作成する方法です。

arrow = Arrow(start=RIGHT, end=LEFT, color=self.fontColor).next_to(circle, LEFT, buff=0)

最後に、これらのオブジェクトをアニメーションシーンに追加する方法は次のとおりです。

self.play(Create(circle), Create(arrow))

Gitストーリーをインストールする方法

  1. OSのmanimとmanimの依存関係をインストールします
  2. GitPythonをインストールします。$ pip3 install gitpython
  3. git-storyをインストールします：$ pip3 install git-story

Gitストーリーの使用方法

  1. コマンドラインターミナルを開く
  2. を使用してGitプロジェクトのルートフォルダーに移動しますcd
  3. 次のコマンドを実行します。git-story

このコマンドを実行すると、Gitリポジトリ内の最新の8つのコミットからmp4ビデオアニメーションが生成されます。ビデオファイルは、現在のディレクトリ内のパスに配置されます./git-story_media/videos。

Gitストーリーの出力をカスタマイズする方法

Git Storyには、出力ビデオでのGitリポジトリの表現方法を変更するさまざまな方法が含まれています。これは、コマンドラインオプションとフラグを使用して行います。

アニメーション化するコミットの数を指定するには、オプションを使用します--commits=X。ここで、Xは表示するコミットの数です。

以外の特定のコミットからアニメーションを開始することもできHEADます。このオプションを使用して、--commit-id=ref逆方向に作業を開始するコミットを選択できます。の代わりにref、完全または部分的なコミットID、ブランチ名、またはGitタグに置き換えることができます。

フラグを使用して、コミットを新しいものから古いものへとアニメーション化できます。これは、 Gitログ出力--reverseとより厳密に一致するように時系列の逆順です。

フラグを試して、--low-qualityテスト中のアニメーション生成時間を短縮してください。アニメーションの外観に満足したら、フラグを削除し、コマンドを再度実行して、最終的な最高品質のバージョンを取得します。

--light-modeデフォルトの暗い配色ではなく明るい配色を使用する場合は、フラグを指定できます。

プレゼンテーションの目的で、アニメーションにイントロタイトル、ロゴ、およびエンディングを追加することをお勧めします。これは、次のオプションで実行できます。

$ git-story --show-intro --title "My Git Repo" --show-outro --outro-top-text "My Git Repo" --outro-bottom-text "Thanks for watching!" --logo path/to/logo.png

このオプションを使用して--media-dir=path/to/output、ビデオの出力パスを設定します。これは、プロジェクト内に余分なファイルを作成したくない場合に便利です。

最後に、--invert-branchesGitコミット履歴に複数のブランチがある場合は、フラグをテストすることをお勧めします。このフラグは、ブランチが解析される順序を反転し、出力ビデオのブランチの向きを変更します。このフラグを設定すると見栄えが良くなるアニメーションもあれば、そうでないアニメーションもあります。

入力コミット範囲に複数のブランチが存在する場合に生成されるビデオがどのように見えるかを示す最後の例を次に示します。

複数のブランチを持つGitストーリーの例.mp4のビデオ出力

 

概要

Git Storyは、Gitコミット履歴のビデオアニメーションを簡単に作成できるようにするためにPythonで作成したコマンドラインツールです。依存関係には、ManimとGitPythonが含まれます。

HEAD出力ビデオには、ブランチ名、コミット、およびタグとともに、必要なコミットのセットとそれらの関係が表示されます。

Git Storyには、アニメーションをカスタマイズできるさまざまなコマンドラインフラグとオプションがあります。git-story -h使用可能なオプションの完全なセットに対してコマンドを実行します。

読んでくれてありがとう、そして幸せなコーディング！

ソース：https ：//www.freecodecamp.org/news/animate-your-git-repo-with-git-story/

#git 

What is GEEK

Buddha Community

git-storyを使用してGitコミット履歴をアニメーション化する
Madyson Reilly

Madyson Reilly

1604109000

Best Practices for Using Git

Git has become ubiquitous as the preferred version control system (VCS) used by developers. Using Git adds immense value especially for engineering teams where several developers work together since it becomes critical to have a system of integrating everyone’s code reliably.

But with every powerful tool, especially one that involves collaboration with others, it is better to establish conventions to follow lest we shoot ourselves in the foot.

At DeepSource, we’ve put together some guiding principles for our own team that make working with a VCS like Git easier. Here are 5 simple rules you can follow:

1. Make Clean, Single-Purpose Commits

Oftentimes programmers working on something get sidetracked into doing too many things when working on one particular thing — like when you are trying to fix one particular bug and you spot another one, and you can’t resist the urge to fix that as well. And another one. Soon, it snowballs and you end up with so many changes all going together in one commit.

This is problematic, and it is better to keep commits as small and focused as possible for many reasons, including:

  • It makes it easier for other people in the team to look at your change, making code reviews more efficient.
  • If the commit has to be rolled back completely, it’s far easier to do so.
  • It’s straightforward to track these changes with your ticketing system.

Additionally, it helps you mentally parse changes you’ve made using git log.

#open source #git #git basics #git tools #git best practices #git tutorials #git commit

Andreanne Kassulke

Andreanne Kassulke

1597916460

7 Best Practices in GIT for Your Code Quality

There is no doubt that Git plays a significant role in software development. It allows developers to work on the same code base at the same time. Still, developers struggle for code quality. Why? They fail to follow git best practices. In this post, I will explain seven core best practices of Git and a Bonus Section.

1. Atomic Commit

Committing something to Git means that you have changed your code and want to save these changes as a new trusted version.

Version control systems will not limit you in how you commit your code.

  • You can commit 1000 changes in one single commit.
  • Commit all the dll and other dependencies
  • Or you can check in broken code to your repository.

But is it good? Not quite.

Because you are compromising code quality, and it will take more time to review code. So overall, team productivity will be reduced. The best practice is to make an atomic commit.

When you do an atomic commit, you’re committing only one change. It might be across multiple files, but it’s one single change.

2. Clarity About What You Can (& Can’t) Commit

Many developers make some changes, then commit, then push. And I have seen many repositories with unwanted files like dll, pdf, etc.

You can ask two questions to yourself, before check-in your code into the repository

  1. Are you suppose to check-in all these files?
  2. Are they part of your source code?

You can simply use the .gitignore file to avoid unwanted files in the repository. If you are working on more then one repo, it’s easy to use a global .gitignore file (without adding or pushing). And .gitignore file adds clarity and helps you to keep your code clean. What you can commit, and it will automatically ignore the unwanted files like autogenerated files like .dll and .class, etc.

#git basics #git command #git ignore #git best practices #git tutorial for beginners #git tutorials

Loma Baumbach

Loma Baumbach

1601157360

Mirroring Git Changes From One Server to Another Server

Introduction

Hello all, nowadays most of the development teams using GIT version control, some of you may have a requirement of mirroring your team’s git changes from one server to another Git server. This article will help you to achieve the Git mirroring between one server to another server.

Business Case

I got one assignment wherein there will be 2 Git Servers, development will happen in one Git server and the changes should be synchronized to another Git server at regular intervals. But in my case, the complexity is both the servers are in different restricted network. So I have done the small experiment and it worked. And I am sharing the steps to you all in this article.

The Experiment Performed Using Below 2 GIT Servers

Main GIT Server: Let’s take our main git server is located in our office and can be accessed only in-office network.

**Mirror GIT Server: **The mirror server is located at the vendor/client-side, which can be accessible in a normal internet connection but not with our office network. Since the office proxy will block the outside URL’s.

#devops #git #git and github #git best practices #git cloning #git server

Rupert Beatty

Rupert Beatty

1617875220

Git Commands You Can Use To Dig Through Your Git History

In this short article, we’ll be exploring some quick  git commands that can help us in digging through our repositories’ history of commits. We’ll look at

  1. git log
  2. git shortlog
  3. git show
  4. git rev-list

#git #git-log #git-commands #git-history #aws

Andreanne Kassulke

Andreanne Kassulke

1591518708

Git Rebase Tutorial and Comparison with Git Merge

There are many ways of working with git, if they’re clean, and don’t do damages, probably most of them are good.

But same as space vs. tab, in the IT world is a war between fans of rebase, and fans of git merge.

There are tons of arguments about:

-Which way is better?

-Which one is cleaner?

-Which is more comfortable?

-Which one gives a cleaner git graph?

-Why it’s important, and which one is more dangerous?

#quick help #tutorials #git #git branch #git commit #git interactive rebase