Thoughtbot git commands

Workflow Git
1

I was browsing the Thoughtbot dotfiles,specifically your .gitconfig source and came across 4 aliases: create-branch, delete-branch, merge-branch, rebase-origin.

Is this kinda of the workflow this was meant for…

[1] So every time you create a new branch you will run:
git create-branch newbranchname
(e.g. git create-branch auth-feature-gz)

  • work on that feature, tests, etc. and when all is good…
  • git add .
  • git commit -m"my changes"
  • git push

[2] then run:
git merge-branch
… ±

[3] next:
git rebase-origin

[4] finally:
git delete-branch newbranchname
(e.g. git delete-branch auth-feature-gz)

meaning, you will do this pretty much everytime? I understand their could be exceptions, but for the most part, when merging, you’ll merge this way, when deleting, you’ll delete this way… thanks in advance.

might be typos… didn’t proof read…

1 Like
2

Exactly. Our current flow, if using those aliases, would look like this:

Write a Feature

Create a local feature branch based off master.

git checkout master
git pull
git create-branch <branch-name>

Prefix the branch name with your initials.

Rebase frequently to incorporate upstream changes.

git fetch origin
git rebase origin/master

Resolve conflicts. When feature is complete and tests pass, stage the changes.

git add --all

When you’ve staged the changes, commit them.

git status
git commit --verbose

Write a good commit message. Example format:

Present-tense summary under 50 characters

* More information about commit (under 72 characters).
* More information about commit (under 72 characters).

http:://project.management-system.com/ticket/123

If you’ve created more than one commit, use a rebase to squash them into
cohesive commits with good messages:

git rebase -i origin/master

Share your branch.

git push origin <branch-name>

Submit a GitHub pull request.

Ask for a code review in the project’s chat room.

Review Code

A team member other than the author reviews the pull request. They follow

Code Review guidelines to avoid
miscommunication.

They make comments and ask questions directly on lines of code in the GitHub
web interface or in the project’s chat room.

For changes which they can make themselves, they check out the branch.

git checkout <branch-name>
./bin/setup
git diff staging/master..HEAD

They make small changes right in the branch, test the feature on their machine,
run tests, commit, and push.

When satisfied, they comment on the pull request Ready to merge.

Merge

Rebase interactively. Squash commits like “Fix whitespace” into one or a
small number of valuable commit(s). Edit commit messages to reveal intent. Run
tests.

git fetch origin
git rebase -i origin/master

Force push your branch. This allows GitHub to automatically close your pull
request and mark it as merged when your commit(s) are pushed to master. It also
makes it possible to find the pull request that brought in your changes.

git push --force origin <branch-name>

View a list of new commits. View changed files. Merge branch into master.

git log origin/master..<branch-name>
git diff --stat origin/master
git merge-branch
git push

Delete your remote and local feature branches.

git delete-branch
2 Likes
3

Thanks Dan for the clarification. I did see your guides, it just when I viewed the aliases which incorporated multiple git commands I was thinking wow do they run these all the time… but then again working with a team as opposed to by yourself is quite different… but I would like to incorporate these best practices now so they become a habit.

— side note —
I really like how your team has really thought things out (no pun intended) , and when looking at your dotfiles and source code you all have really refined the process and made it very efficient. Just switching to vim and tmux, slowed me down for a while but as I learn new commands I can see the benefits and it’s exciting. thanks for all your help…

4

Awesome! Really glad to hear it.

Those commands look like a lot when they include the descriptions with them, but they become second nature after not too long. Lots of little aliases and tab-completion keeps things fast.

Good luck!