[Digikam-devel] My standard git workflow [Re: please avoid "merge" commits!!]

[Matthias Welwarsky]

Hi,

despite the warning in the manual page regarding the --rebase option, the 
standard flow when working with git should be as follows:

First check out the remote branch you want to base your work on:
 
$ git checkout -t <remote>/<branch>
 
the local branch will be called <branch> and it is set up to track the remote 
branch of the same name

Then, develop, add new files, etc.

After you have changes ready to push to the remote, commit them in your local 
branch. Either commit everything, or commit only the files you think are ready 
for publishing and "stash" the rest:

$ git commit ...
[maybe] $ git stash

I can only encourage everybody to use "git gui" to commit, you can see the 
changes you will commit and it also allows you to only commit parts of files, 
single hunks, or even single lines. This allows to create meaningful commits 
with clear to understand commit message explaining exactly what the change 
does.

Then, update from the remote branch:

$ git pull --rebase

This command will reset your local branch to the head of the remote branch 
(after fetching all updates) and then replay all the changes that you have 
commited in your local branch on top of it. If there are conflicts you need to 
fix them, just like you would with svn or cvs. This fixing of merge conflicts 
are done inside a "rebase" bracket, so the workflow is: fix conflict, "git 
add" the fixed files, then "git rebase --continue". Repeat until all you 
patches are correctly replayed. Again, use "git gui" to make your life easier.

Finally, push the changes to the remote server.

$ git push <remote> <branch>

Since you have rebased your patches on top of the remote branch before, it 
will go smoothly, unless of course somebody else has pushed something to the 
remote branch before you, in which case your push will fail again. In that 
case, go back to the "git pull --rebase" step.

Once you have successfully pushed your changes, continue to develop, add new 
files, etc.

If you have only committed part of your work and used "git stash" to stash 
away the remaining changes, you will definitely want to have these changes 
back in your workspace. Do this with the following command:

$ git stash pop

This will merge the stashed changes back into your workspace. Merge conflicts 
may happen here, because maybe a change in the remote branch has affected 
files that you changed yourself. In that case you need of course to resolve 
these conflicts, too.

As a final hint: become familiar with "git rebase". Especially with "git 
rebase -i" which is a very, very powerful tool to clean up your local changes 
before you push them to the remote branch. It allows to fix commit messages, 
reorder patches or even merge them together. A rebase also allows you to "fix" 
merge commits that you have accidentially created by forgetting the "--rebase" 
option to git pull. Just try a "git rebase -i <remote>/<branch>" before you 
push, you will understand what it does.

best regards,
matthias


On Friday 17 February 2012 23:59:33 Francesco R. wrote:
> ack, I've done a change at the same time of someone else and git refused to
> push, so I've done a `git pull -a` `git commit` `git push` cicle, the first
> pull should hve be done with --rebase right? The man page of git pull is a
> bit worrying tough [1]
> 
> while we are at it, I'm currently using the following cicle to merge the
> changes to the branch (sql/2.0) I use as a testbed, do you have better
> suggestion for this as well?
> 
> git pull -a
> git merge origin/master
> git push git at git.kde.org:digikam sql/2.0
> git pull -a
> git status
> 
> 
> [1]
>        --rebase
>            Rebase the current branch on top of the upstream branch after
> fetching. If there is a remote-tracking branch corresponding to the
>            upstream branch and the upstream branch was rebased since last
> fetched, the rebase uses that information to avoid rebasing
>            non-local changes.
> 
>            See branch.<name>.rebase and branch.autosetuprebase in git-
> config(1) if you want to make git pull always use --rebase instead of
>            merging.
> 
>                Note
>                This is a potentially dangerous mode of operation. It
> rewrites history, which does not bode well when you published that
>                history already. Do not use this option unless you have read
> git-rebase(1) carefully.