About Gitless

Gitless is an experimental version control system built on top of Git. Many people complain that Git is hard to use. We think the problem lies deeper than the user interface, in the concepts underlying Git. Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts. Because Gitless is implemented on top of Git (could be considered what Git pros call a "porcelain" of Git), you can always fall back on Git. And of course your coworkers you share a repo with need never know that you're not a Git aficionado.

Check out the documentation to get started. If you are a novice user that never used any version control system the documentation should be enough to get you started. If you are a Git pro looking to see what's different from your beloved Git you'll be able to spot the differences by glancing through the documentation.



(link will take you to the point in the guide in which the command is introduced)



Say you are in directory foo and you want turn it into a local repository. You do this with the gl init command. This will transform the current working directory into an empty Gitless's repository and you are now ready to start recording changes to files in foo.

      $ mdkir foo
      $ cd foo/
      $ gl init
      # Local repo created in '/MyFiles/foo'

In most cases, there's probably already some existing repository that you want to start working on instead of creating an empty repository (maybe you just created a GitHub repo you want to now start using). To make a local clone of a remote repository you can give the url of the repository to the same gl init command.

      $ mkdir experiment
      $ cd experiment/
      $ gl init https://github.com/spderosso/experiment.git
      # Initialized from remote
      # 'https://github.com/spderosso/experiment.git'


A file in Gitless is one of the following: a "Tracked File," an "Untracked File" or an "Ignored File."

Tracked File A tracked file is a file whose changes Gitless will automatically detect. Tracked files are automatically considered for commit if they are modified. These will appear under the "Tracked files with modifications" section of the gl status command.

Untracked File Conversely, an untracked file is a file whose changes Gitless will not automatically detect and is listed under the "Untracked files" section of the gl status command. These are not automatically considered for commit.

Ignored File An ignored file is a file that is completely ignored by Gitless. These won't even appear in the output of the gl status command.

An example output of the status command (foo.py is a tracked file with modifications, .gitignore is an unmodified tracked file, bar.py is an untracked file and foo.py~ is an ignored file):

      $ ls
      bar.py  foo.py  foo.py~ .gitignore
      $ gl status
      # On branch master, repo-directory //
      # Tracked files with modifications:
      #   (these will be automatically considered for commit)
      #   (use gl untrack <f> if you don't want to track changes
      #    to file f)
      #   (if file f was committed before, use gl checkout <f>
      #    to discard local changes)
      #     foo.py
      # Untracked files:
      #   (these won't be considered for commit)
      #   (use gl track <f> if you want to track changes to file f)
      #     bar.py

Now, how do files move between these three different disjoint states?

A file is ignored if it's matched by the ignore specification described in the .gitignore file (which is usually present in the root of the repository). In the example above, there is a .gitignore file whose content is '*~'; since foo.py~ is matched by that pattern it's therefore an ignored file.

A new file that is not matched by the ignore spec is initially an untracked file. If you want to make it a tracked file you can do so with the gl track command. A file that has a commited version in the repository is automatically a tracked file. You can stop tracking changes to a tracked file with the gl untrack command. You can always revert a file back to some previous version with the gl checkout command.

As previously said, all tracked and modified files are automatically considered for commit. Doing gl commit will commit these changes (once you provide a commit message). The commit command accepts a bunch of flags to make selecting a subset of files to commit super easy:


A branch is an independent line of development. Each branch has its own history (which you can look at with the gl history command). Any changes to existing files or new files you create on a branch will not be present on the other branch when you switch branches.

A new branch can be created with the gl branch command. Once created you will be automatically switched to that branch.

      $ gl branch my-branch
      # Created new branch my-branch
      # Switched to branch my-branch

If you want to switch to another existing branch called master you can do:

      $ gl branch master
      # Switched to branch master

So, in summary gl branch name switches to branch name and it creates that branch if it doesn't exist. To list all available branches:

      $ gl branch
      # List of branches:
      #   (do gl branch <b> to create or switch to branch b)
      #   (do gl branch -d <b> to delete branch b)
      #   (do gl branch -su <upstream> to set an upstream for
      #    the current branch)
      #   (* = current branch)
      #     * master
      #       my-branch

Eventually what will happen is that branches will end up having divergent changes. There are two ways of bringing changes from one branch onto the current branch: merge or rebase. (If you have no idea what merge or rebase mean, you can take look at Git's documentation.) (This will change in Gitless 1.0 -- which will be released sometime soon.)

For merging the changes in my-branch onto the current branch you do gl merge my-branch, for rebasing the current branch using as a base my-branch you do gl rebase my-branch.

During this process conflicts could occur. If so, the gl status command will change accordingly to indicate the files in conflict. Once you edit those files in conflict you mark them as resolved with gl resolve (passing the files to mark as input). Once all conflicts have been resolved you do gl commit to commit the merge commit in case of a merge or to continue applying any remaining commits in case of a rebase.

Of course, it is also possible to merge or rebase changes from remote branches, or branches that are in remote repositories (not in your local repository). Let's say "experiment" stands for the remote at https://github.com/spderosso/experiment.git and that master is a branch present in that remote repository. If so, doing gl merge experiment/master would merge any changes in that remote branch that are not present in your local current branch. A very common use case is to have a remote repository you always get changes from and send changes to it so that others can retrieve them. To make this more easy, a branch can have an "upstream branch". If a branch has an upstream associated with it, then gl rebase or gl merge can be used as shorthands for gl {rebase, merge} upstream_remote/upstream_branch. To set an upstream branch for the current branch use gl branch -su upstream_remote/upstream_branch.

To publish your changes to this upstream branch you can do gl publish. If the upstream branch doesn't exist in the remote, then the branch will be created in the remote after the publish.

When you create a local repository from a remote (by passing a url as input to the gl init command), all branches are automatically configured to have as upstream their remote counterpart.


You can always use the direct url to bring in changes to your local repository from a remote repository but remembering all those long urls can be annoying. So an easier way is to add that repository as a "remote" with the gl remote command. For example, let's add my GitHub experiment repository as a remote:

      $ gl remote experiment https://github.com/spderosso/experiment.git
      # Remote experiment mapping to
      # https://github.com/spderosso/experiment.git created successfully
      #   (to list existing remotes do gl remote)
      #   (to remove experiment do gl remote -d experiment)

And then you can use experiment/branch as a shorthand for referring to a branch in the experiment repository.


Questions or comments to the Gitless's community can be sent to the Gitless users mailing list on Google groups. For bug reports or feature requests you can create an issue on GitHub.

If you would like to contribute to the development of Gitless, you can read more about how you can help here.

当前网页内容, 由 大妈 ZoomQuiet 使用工具: ScrapBook :: Firefox Extension 人工从互联网中收集并分享;
若有不妥, 欢迎评注提醒:


订阅 substack 体验古早写作:

点击注册~> 获得 100$ 体验券: DigitalOcean Referral Badge

关注公众号, 持续获得相关各种嗯哼:


关于 ~ DebugUself with DAMA ;-)
公安备案号: 44049002000656 ...::