Gitless

Gitless is a Git-compatible model management system, that’s
simple to study and use:

• Easy commit workflow
  Observe or untrack recordsdata to manage
  what modifications to commit. Adjustments to tracked recordsdata are
  dedicated by default, however you possibly can simply customise the set of recordsdata to
  commit utilizing flags
• Impartial branches
  Branches in Gitless embrace your working modifications, so that you
  can swap between branches with out having to fret about conflicting
  uncommitted modifications
• Pleasant command-line interface
  Gitless instructions gives you good suggestions and assist you determine
  what to do subsequent
• Appropriate with Git
  As a result of Gitless is applied on prime of Git, you possibly can at all times fall again
  on Git. And your coworkers you share a repo with want by no means
  know that you just’re not a Git aficionado. Furthermore, you should utilize Gitless
  with GitHub or with any Git internet hosting service

• gl init
  – create an empty repo or create one from an current distant
  repo
• gl status
  – present standing of the repo
• gl track
  – begin monitoring modifications to recordsdata
• gl untrack
  – cease monitoring modifications to recordsdata
• gl diff
  – present modifications to recordsdata
• gl commit
  – document modifications within the native repo
• gl checkout
  – checkout dedicated variations of recordsdata
• gl history
  – present commit historical past
• gl branch
  – checklist, create, edit or delete branches
• gl switch
  – swap branches
• gl tag
  – checklist, create, or delete tags
• gl merge
  – merge the divergent modifications of 1 department onto one other
• gl fuse
  – fuse the divergent modifications of 1 department onto one other
• gl resolve
  – mark recordsdata with conflicts as resolved
• gl publish
  – publish commits upstream
• gl remote
  – checklist, create, edit or delete remotes

Information

creating a repository |
saving changes |
branching |
tagging |
working with remote repositories

Say you’re in listing foo and also you need flip it right into a
repository. You do that with the
gl init command. This transforms
the present working listing into an empty repository and also you
are actually prepared to begin saving modifications to recordsdata in foo:

$ mkdir foo
$ cd foo/
$ gl init
✔ Native repo created in /MyFiles/foo

Generally, as an alternative of beginning with an empty repository, there’s already
some current distant repository you wish to work on. To clone a distant repository,
you go the URL of the repository to the identical gl init command, as
proven under (notice that you will have
to switch https://github.com/gitless-vcs/try-gitless with
the URL of your repo):

$ mkdir try-gitless
$ cd try-gitless/
$ gl init https://github.com/gitless-vcs/try-gitless
✔ Native repo created in /MyFiles/try-gitless
✔ Initialized from distant https://github.com/gitless-vcs/try-gitless

If you do not have a distant repository but, you possibly can comply with
these instructions to create one on
GitHub.

Now that you’ve your native repository, it is time to begin saving
modifications to recordsdata. A file in Gitless will be tracked,
untracked or ignored.
A tracked file is a file whose modifications Gitless will detect.
Tracked recordsdata are routinely thought of for commit if they’re
modified and seem listed beneath the “Tracked recordsdata with modifications”
part of standing.
Conversely, an untracked file is a file whose modifications Gitless
is not going to detect. These aren’t routinely thought of for commit and
seem listed beneath the “Untracked recordsdata” part of
standing.
Lastly, an ignored file is a file that’s utterly ignored by
Gitless and it will not even seem within the output of standing.

An instance output of the gl standing
command
(foo.py and bar.py are tracked recordsdata
with modifications, .gitignore is an unmodified tracked file,
baz.py is an untracked file and foo.pyc is an
ignored file):

$ ls
bar.py  baz.py  foo.py  foo.pyc .gitignore
$ gl standing
On department grasp, repo-directory //

Tracked recordsdata with modifications:
  ➜ these can be routinely thought of for commit
  ➜ use gl untrack <f> should you do not wish to observe modifications to file f
  ➜ if file f was dedicated earlier than, use gl checkout <f> to discard native modifications

    foo.py
    bar.py

Untracked recordsdata:
  ➜ these will not be thought of for commit)
  ➜ use gl observe <f> if you wish to observe modifications to file f

    baz.py

Now, how do recordsdata transfer between these three totally different disjoint
states?

A file is ignored if it is matched by the ignore specification described in
a .gitignore file.
Within the instance above,
there’s a .gitignore file whose content material is ‘*.pyc’; since
foo.pyc is matched by that sample it is subsequently an
ignored file.

A brand new file that isn’t matched by the ignore spec is initially an untracked
file. If you wish to observe it you are able to do so with the
gl observe command. You’ll be able to cease monitoring
modifications to a tracked file
with the gl untrack command.
You’ll be able to at all times revert a file again to some earlier model with the
gl checkout command.

$ gl observe baz.py
✔ File baz.py is now a tracked file
$ gl observe baz.py
✘ File baz.py is already a tracked file
$ gl untrack baz.py
✔ File baz.py is now an untracked file
$ gl checkout foo.py
You've gotten uncommitted modifications in foo.py that might be
overwritten by checkout. Do you want to proceed? (y/N)
> y
✔ File foo.py checked out efficiently to its state at HEAD

To save lots of modifications to recordsdata you utilize
gl commit.
By default, all tracked modified recordsdata are thought of
for commit, however the set of recordsdata to commit will be personalized by itemizing
the recordsdata to be dedicated solely, or utilizing the e/exclude and i/embrace
flags:

$ gl commit -m "foo and bar"
$ gl commit -m "solely foo" foo.py
$ gl commit -m "solely foo and baz" foo.py baz.py
$ gl commit -m "solely foo" -e bar.py
$ gl commit -m "solely foo and baz" -e bar.py -i baz.py
$ gl commit -m "foo, bar and baz" -i baz.py

There’s additionally a p/partial flag that permits you to
interactively choose segments of recordsdata to commit.

The gl diff command can be utilized to see the
distinction between the working and dedicated variations of recordsdata. Like
commit, the default set of recordsdata to diff is
the set of all tracked modified recordsdata however it may be personalized by
itemizing recordsdata, or utilizing the e/exclude and i/embrace
flags.

To take away recordsdata merely do it such as you would in
your working system (e.g., utilizing Unix’s rm command). Gitless
will detect the change if the file was tracked, and it’ll seem as eliminated
in standing. Gitless at present would not detect renames. If you happen to rename a file,
Gitless will interpret this as a file with the previous identify being eliminated and a brand new one
(with the brand new identify and content material) being created. If you would like the renamed file to be tracked
once more it is advisable to observe it with gl observe.

A department is an impartial line of growth. You’re at all times working
on some department. Every department has its personal historical past (which you’ll take a look at
with the gl historical past command). Any modifications to
current recordsdata or new recordsdata you create on a department is not going to be current on
the opposite department whenever you swap branches.

To create a brand new department you utilize the
gl department
command. To change to a different department you utilize the
gl swap command:

$ gl department -c develop
✔ Created new department develop
$ gl swap develop
✔ Switched to department develop

To checklist all branches:

$ gl department
Record of branches:
  ➜ do gl department <b> to create department b
  ➜ do gl department -d <b> to delete department b
  ➜ do gl swap <b> to modify to department b
  ➜ * = present department

    * grasp
      develop

Every department has a head, which is the final commit finished on the department.
By default, the pinnacle of a brand new department goes to be equal to the
head of the present department. If you would like a distinct decide to be the
head of the brand new department you possibly can present one with the
dp/divergent-point flag.

To specify a commit you should utilize its id, or you possibly can specify it by way of an ancestry
reference with ~: HEAD~n refers to
the nth commit earlier than head.

To vary the pinnacle of the present department you utilize the sh/set-head flag.
The sh flag is beneficial to, for instance, amend the final commit:
to take action, run gl department -sh HEAD~1.
Altering the pinnacle of the present department will not contact your working listing, should you
moreover wish to reset your working listing to match the brand new head
you utilize gl checkout.

Finally branches will find yourself having divergent
modifications. There are two methods to convey modifications from one department onto the
present department: merge and fuse.

Merging branches.
For merging the modifications in develop onto the present department
you do gl merge develop. This creates
a brand new merge commit that features the modifications in develop in
addition to these modifications within the present department:

Fusing branches. Fusing branches provides you extra management than
merging. Once you fuse modifications from some department onto the
present department you possibly can specify the commits to fuse and the insertion
level. By default, all divergent commits are fused and the insertion
level is the divergent level (the purpose the place the supply department diverged
from the present).
For instance, the next determine depicts a scenario during which there are
two branches: grasp (the present department) and
develop. The final commit these two branches have in widespread is
A. This commit is the “divergent level” (as a result of
it’s the level at which grasp and develop
diverged).
After doing gl fuse develop, the commits
in develop are inserted in grasp after the
divergent level:

To decide on different insertion factors you utilize the
ip/insertion-point flag. You can provide a commit id as enter,
head or dp/divergent-point:

The o/solely and e/exclude flags can be utilized to
customise the set of commits to be fused:

Throughout this course of conflicts may happen. If that’s the case, the gl standing command will change
accordingly to point the recordsdata in battle. When you edit these recordsdata in
battle you mark them as resolved with
gl resolve (passing the recordsdata to mark as enter). As soon as all
conflicts have been resolved
you do gl commit to decide to proceed with the fuse or
merge.

A department can have an “upstream department.” If a department has an upstream
related to it, then gl fuse or gl merge can
be used as shorthands for gl {fuse, merge} upstream_branch.
To set an upstream department for the present department use
gl department -su upstream_branch.

You utilize tags to indicate a commit is particular not directly. For instance, you
can use gl tag to create a tag with identify
“v1.0” and make it level to the commit that represents launch v1.0:

$ gl tag -c v1.0
✔ Created new tag v1.0

On this case, the tag will level to the pinnacle of the present department, however
you possibly can tag different commits with the ci/commit flag.

To checklist all tags:

$ gl tag
Record of tags:
  ➜ do gl tag <t> to create tag t
  ➜ do gl tag -d <t> to delete tag t

    v1.0 ➜  tags 311bf7c Able to launch

To discuss with a distant repository you can at all times use its URL, however an
simpler various is so as to add the repository as a “distant” with the
gl distant command:

See Also

Inform HN: Enterprises spend 10x extra to construct no-code options than coded ones

$ gl distant -c try-gitless https://github.com/gitless-vcs/try-gitless
✔ Distant try-gitless mapping to https://github.com/gitless-vcs/try-gitless created
efficiently
  ➜ to checklist current remotes do gl distant
  ➜ to take away try-gitless do gl distant -d try-gitless

Now you should utilize try-gitless to discuss with this distant repository
and use try-gitless/some-branch to discuss with the department of identify
some-branch that lives in try-gitless.

Downloading Adjustments.
It’s also doable to fuse or merge modifications from distant
branches. For instance, doing gl merge try-gitless/grasp
would merge modifications in that distant department that aren’t current in your
native present department. You may also use gl fuse.

Importing Adjustments.
To ship modifications upstream you utilize
gl publish. The publish command will
default to updating the upstream department of the present department if none is
given as enter.

Creating, Deleting, or Itemizing Distant Branches.
To create, delete, or checklist distant branches you utilize the identical gl department
command that you just use for native branches. If you happen to do
gl department -c try-gitless/develop this may create a department
develop that lives within the distant try-gitless.
Recall that, by default, the pinnacle of this new department can be equal to the pinnacle of
the present department, so all commits that aren’t current within the distant
can be uploaded. To checklist distant branches use the
r/distant flag of gl department.

Creating, Deleting, or Itemizing Distant Tags.
To create or delete distant tags you utilize the gl tag command.
If you happen to do
gl tag -c try-gitless/v1.0 this may create a brand new tag
v1.0 that lives within the distant try-gitless. You may also checklist
distant tags with the r/distant flag of gl tag.

Once you create an area repository from a distant (by passing a URL as
enter to the gl init command), an area department is created
for every distant department, and every native department is routinely configured
to have as upstream its distant counterpart.