Category: java

[Title might be misleading because you need to make somewhere that merge but let it your github/stash/bitbucket etc. do it for you]

Problem: When starting your adventure with git did you feel like not knowing what is going on and ending with deleting the repo and cloning once again? I wish to help you and show how to work with git without removal&clone again.

The idea comes from Advance Git video. If you want TL;DR carry on with reading.

Once upon a time my dear friend told me how to work with git. Since then I’m happy git user and then I saw above video confirming that way of work. Before that I was blandly merging, pushing, forcing and always left in conflict state. There are some rules worth remembering in this workflow style.
1. rebase only
2. always work on a branch, even if your projects doesn’t require it

That’s it. Have a pleasant life!

The first one keeps your history clean – one straight line, because while rebasing to any branch you “plug out” your commits, rewrite new commits (from branch you rebase against) and apply your commits on top of that!

 

My typical work flow with git:

1. git clone [repo]
2. git checkout -b dev – always work on a branch, let it be dev
3. git add . & git commit -m "whatever" – commit changes, I prefer `git cola` for previewing and commiting my changes
4. git push origin dev – if you want to make an pull request you need to push your changes to remote repo
5. git checkout master – switch to master
6. git pull --rebase – pull new commits to master, let your local master branch be always a copy of that remote
7. git checkout dev – switch to dev
8. git rebase master – apply changes from master to your branch, conflicts may appear here, but after resolving you are synchronized with current master
9. git push origin dev:master – this pushes your commits from your local branch dev to remote master, instead of merge, or when working with PR let it github do merge
10. git branch -D dev – delete branch, repeat the process

By “resolving conflicts” I mean edit that conflicted files manually and applying with `git add` them and git rebase –continue. After 8 step you can push your changes to remote repo and it will be easily merged into master, or locally you can switch to master and merge your dev branch as well.

Shortcut for steps 5-8:

1. git fetch origin
2. git rebase origin master – being on dev branch

Useful tools:

1. for moving commits between branches use git cherry-pick

Squashing

I like squashing because it makes feature come in one commit, but this is quite controversial, most prefer to make a lot of smaller commits claiming that it will be easier to revert or spot a bug.

1. after a few hours of work you’ve got 2 commits, go and squash them
   git rebase -i HEAD~2
2. manage two steps
   1. you’ve been shown a history in reversed order so you mark `pick` first commit and mark `s` or `squash` the rest, save & quit
   2. on second screen you delete or comment out commit messages and leave just one
3. you could refresh your master branch by pulling changes like in step 2., after that please get back to git checkout MyDevPolygon
4. rebase your changes to master by git rebase -i master
5. you will be shown your squashed commit ready for commits, if git tells you about any conflicts, you will have to resolve them but only once!

Sometimes people are working on branches to which they merge changes from master (acquiring new design)… in the end they go back with their work to master.

In this common case you might need to apply one of following scenarios:

1. BEST: always keeping your changes on top – rebasing to master while working on feature branch
2. when you messed smth up and git asks you to resolve same conflicts over and over go and use
   git rerere
3. at the end squash your changes two one clean commit

I love this article git team workflow merge or rebase