git-town / git-town Goto Github PK

Syncs all local feature branches. Ends up on the same branch as started. Good for keeping the whole workspace up to date.

• merge --squash or merge
• store in config file

Look more in depth at abort/continue scripts. If aborting is always the right option, just rollback the changes without an abort script. Otherwise be sure we have abort and continue scripts.

Kills a branch, even when there are uncommitted changes

If possible

Don't push a branch if it is already up to date

The checks for abort and continue scripts can be merged into one step

I frequently use git checkout - to switch to a previous branch.

Scenario:

• Currently on feature branch A
• Checkout another feature branch: git checkout B
• git ship
• After shipping, current branch will be <main_branch_name>
• I'd expect git checkout - to take me to A at this point. In actuality, git is trying to take me to the true previous branch, which is B (which has just been shipped and deleted).

Since git ship feels like an atomic operation, I'm frequently wanting to go back to the original branch I was on before shipping. Does this issue make sense?

https://help.github.com/articles/syncing-a-fork
https://help.github.com/articles/configuring-a-remote-for-a-fork

naming the remote something aside from upstream could be a configuration option
could even setup upstream for you by querying the github api

I've needed this lately so think it would be awesome. Happy to implement.

Looks like git-town supports MacOS. Does it support linux and dare i say, Windows?

• abort the rebase if it's currently ongoing
• pop the stashed changes

Revert to the latest Git version, i.e. throws all local changes away.

• changed files
• deleted files
• new files
• not checked in files

When updating 2 branches, right now it makes 2 requests to Github. Maybe we can bring them down to 1?

Accidentally shipped a branch that was not any commits ahead of main. Would have likes an error.

$ git ship -m 'feature done'
git checkout dev
Switched to branch 'dev'
Your branch is up-to-date with 'origin/dev'.

git fetch --prune

git rebase origin/dev
Current branch dev is up to date.

git checkout feature
Switched to branch 'feature'
Your branch is up-to-date with 'origin/feature'.

git merge origin/feature
Already up-to-date.

git merge dev
Updating 0d375c1..d407d0f
Fast-forward
  ...

git checkout dev
Switched to branch 'dev'
Your branch is up-to-date with 'origin/dev'.

git merge --squash feature
 (nothing to squash)Already up-to-date.

git commit -a -m "feature done"
On branch dev
Your branch is up-to-date with 'origin/dev'.

nothing to commit, working directory clean

git push
Everything up-to-date

git checkout feature
Switched to branch 'feature'
Your branch is ahead of 'origin/feature' by 2 commits.
  (use "git push" to publish your local commits)

git push origin :feature
...

git checkout dev
Switched to branch 'dev'
Your branch is up-to-date with 'origin/dev'.

git branch -D feature
Deleted branch feature (was d407d0f).

$

--verbose flag will show the git commands actually being run

Github automatically closes and references PRs when adding Closes #[Some PR] to a commit. Having git ship automatically append this to the squashed merge commit would help automate the entire feature branch processes.

Would be nice to easily extract the last commit or last n commits

git town or git town help to show the commands would be useful

Summarize the test results at the end of a test run

I just shipped a slightly outdated feature branch that contained changes which conflict with master. This aborted git-ship in the middle of the squash-merge and left me with open conflicts on the master branch. I had to do a bunch of development to resolve them directly on the master branch. There should be no development on master.

Also, since the command didn't finish properly, I had to delete the feature branch manually from both the local and remote repo. This was a poor user experience.

A better way to ship seems to have git-ship merge the master branch into the shipping feature branch one more time as part of shipping. This then fails on the feature branch with the merge conflicts, gives the developer the proper space to resolve any merge conflicts on the feature branch. The following squash-merge of the up-to-date feature branch into master will then be much more straightforward and less risky.

What do you think about this change?

• create a branch "foo"
• create an open file
• run "git hack foo"

expected: I am on the "foo" branch and see my open file
actual: I am on the "foo" branch, but the stash wasn't popped

Was on the plane the other day and was unable to use the commands as had no network connection. (git hack and git extract can be used nicely without a network connection). Maybe add a --local flag which skips all pulls and pushes.

• deletes the current branch from both the local and remote repository
• asks for confirmation if the branch contains unmerged commits
• never deletes the main branch

In addition to commits, git sync should also push tags that don't exist in the remote by running git push --tags if necessary.

• save in a configuration setting whether the current workflow is merge or rebase based
• the different tools perform different things according to this configuration setting

git ship --message "commit message"

Does the squash merge using the provided message (thus you don't need to use the editor)

• undo the merge squash

Kevin pleasing to help for installing of git-town

• create a new git repo in a tmp directory
• call scripts there and verify the results
• branch names = "main_$timestamp" and "feature1_$timestamp", can be pushed to Github
• assert: http://tldp.org/LDP/abs/html/debugging.html#ASSERT

On some projects we have branches that are not the main nor feature branches.
I'm thinking about branches that are more stable main branches or used for deployments.
It would be nice if it would not allow me to git sync these branches or at least require that I use -f or some other option on them.

Does not work on main branch.

Did some work on master (working on a fork) and when it came time to push up wanted to move it all over to a different branch. However git extract errors if you are not on a feature branch.

I see no real problem with being able to extract from the main branch. What are your thoughts?

Explain what to do to finish the process when something goes wrong.

using the https://github.com/cucumber/aruba gem

Shouldn't it put this into .git-town-rc instead of its own file?
Also what does rc in .git-town-rc stand for?

http://stackoverflow.com/questions/18935539/authenticate-with-github-using-token?rq=1

Please include a license file.

Although I like this idea, I think the README on master should just be the features currently supported and have another branch that has the features you are thinking of supporting. (These could also just be in issues as quite a few things are currently).

http://stackoverflow.com/questions/3745135/push-git-commits-tags-simultaneously

These two scenarios often result in different code paths, and must be tested separately.

To make sure we leave no side effects on the git stash

Prune all local branches that have been merged into master.
Not needed if using git ship but otherwise would help.
Quick google search gives some answers, but need to have it take the main branch into account

The script is there but it is not tested nor documented in the README

Just looking at a few other projects

• Changelog.txt (sinon)
• ReleaseNotes.md (chai)
• Changelog.md (rspec-expectations)

Brought up by your TODO. What do we do when there are local changes on the main branch that have not been pushed to the repo?

I favor just erroring out and telling the user they have unsynced changes on the main branch they need to deal with first.

• abort any ongoing cherry-picks
• go back to the old feature branch
• kill the unfinished feature branch

In order for multiple users to use a feature branch
we must merge updates from main into it instead of rebasing it
so that we don't rewrite shared history