GitXplorerGitXplorer
r

eetoul

public
2 stars
0 forks
4 issues

Commits

List of commits on branch master.
Unverified
20ba8f408a3004a7cbb6d8c08e11b22f46ed35a7

some updates

rramonsnir committed 9 years ago
Unverified
1157edcb66ed7f4d6db3a3fe93ac48b534806a51

changing `RepoUtils.commit`

rramonsnir committed 9 years ago
Unverified
8244d2abfc982f765697a1b7ae626c4b0152bb3e

rcr strategies

rramonsnir committed 9 years ago
Unverified
568507276608486030ef41c71d7eb0282e309551

archive/unarchive rcr too

rramonsnir committed 9 years ago
Unverified
585c87994ca155b21dad6a7cf5d552cbaafa9c22

Elixir 1.3

rramonsnir committed 9 years ago
Unverified
1187b459d73eb327246037c467493caa88b9e24d

politeness

rramonsnir committed 9 years ago

README

The README file for this repository.

Eetoul

Ramon Snir (c) 2016 [MIT License]

A declarative tool for creating integration branches in git

Why?

I found that during development of a version, people wish to test if their code works with other team members' changes. My team members often had issues with the integration branches, merging the integration branches into their feature branches (and then forcing us to start slowly rebasing the feature branches, to take out commits that were meant for a future version but still needed testing).

This solution fits only very specific development teams. Think twice before you choose this development flow.

How?

(further explanation will come in the future, and of course with new features)

Create your release specification branch:

eetoul init
eetoul create release-february master

Release specifications are placed in the eetoul-spec branch and are named by the file name of the specification file. Let's say we have the following content for the committed release-february file in eetoul-spec:

checkout master
take-merge Task-1
take-merge Task-3
take Task-4 add dropdowns support

Then we could test that it can be built without conflicts:

$ eetoul test release-february
Checking out 'master'...
Taking 'Task-1-improve-buttons'...
Taking 'Task-2-fix-tables'...
Taking 'Task-3-add-dropdowns' (squashed)...
Integration branch succesfully created.

This means the branch is good, and we can then push our changes to eetoul-spec to our remote repository and redeploy the release.

To actually make the branch (to test it or to use it), we can run eetoul make release-february.

If your deployment procedured isn't configured to make the latest eetoul branch, then you can make it and push it in a single command (eetoul push release-february) and then deploy the branch release-february.

Conflict Resolution Recording

Based on git's own rerere feature, eetoul comes with its own (hopefully) superior conflict resolution mechanism. In its naïve form, it keeps along the commit tree of the branch eetoul-recorded-conflict-resolutions commits that assist it in reapplying resolutions of previously seen conflicts.