Hi Tony,
On 01/17/14 12:19, Tony M wrote:
Hi All,
I have a personal branch of the master branch and work in my
personal branch. Once I have a feature ready in my branch, I pull the
latest from the master branch(which is updated by other users as well),
and then merge the latest to my branch then push my branch to master (I
know it is confusing. Let me explain step by step).
1) I make multiple changes on Local branch, which has multiple changes
spanning over multiple days.
2) Once I feel the feature I work on is ready to be pushed to master, I
decide to push it to master.
3) Update my local branch of master (git pull). This will have changes
pushed by other users to the master
4) Merge the master to my local branch (git merge master )
5) Push my local branch to repository.
6) Merge local branch to local master (git merge localBranch)
7) Push local master to repository.
Now the problem, I have is in the master branch,
all the commits from my local branch are spread out in a chronological
order (in between changes others have made). So after few days, if I
want to trace the change I made, it is quite hard. Is it possible to
have the merge to the master as a single commit, so that I can just look
at the single commit which has all the commits in my local branch (and
also see all the files I changed in that merge). I read the description
of git merge --no-commit. But am not sure whether that is what I am
looking for.
The commands you are looking for are "git pull --rebase" and "git rebase
-i".
Let's say that your local development branch is tracking the remote
origin/master branch and that you have made 3 commits on your dev
branch. (You may mentally replace [dev] with [master] in the examples
below.)
o--o [origin/master]
\
\--o--o--o [dev]
Doing "git pull --rebase" will pick each commit you made in turn, and
apply each to the tip of the origin/master branch. If there are
conflicts, edit the corresponding files, run "git add " for each
file, and finally "git rebase --continue". When the rebase is complete,
you dev branch pointer will be pointing to the last commit:
o--o [origin/master]
\ \--o--o--o [dev]
\--o--o--o
Note that the old commits still exists in the repo, but are now orphaned.
Now you want to "squash" the three commits on [dev] into one commit by
running "git rebase -i" and setting two of the lines in the message to
"squash" or "s". Look at "git help rebase" for details. After this you
will have:
o--o [origin/master]
\ \\--o [dev]
\ \--o--o--o
\--o--o--o
The orphaned commits will be cleaned up by the garbage collector after
about a month, IIRC. It is executed by some of the git commands, so I
usually don't worry about it.
You could run the above commands in any order you like.
I always create development branches and never work on local master.
That way I can easily identify what each change is for. It is also a
recommended way of working i the git community as far as I can tell:
git checkout -b new-feature origin/master
This set up "new-feature" branch to track the remote origin/master
branch, just like "master".
Another good feature is "git commit --amend" which you can use to avoid
multiple commits when working on a feature, just keep in mind that you
will lose some history, or, rather, not create any. It is more or less
required when working with Gerrit.
I recommend setting up two dummy repos and walk through the process once
or twice, making sure to get conflicts, to better understand the rebase
process.
BR
Gunnar
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
