How to work on many changes at once in git?

Question

I am used to Rational Team Concert. I might be working on 5 or 6 unrelated code changes. In RTC I just make changes, check them into different change sets to keep the changes separate, but at any given time my work space has the cumulative changes from all change sets. (Unless of course I suspend one/some of them, but I rarely do that)

In git, my understanding is that for each unrelated change I should have a separate branch to make the changes there. They get merged back to master or some other main branch eventually. But my question is if I have 5 active changes going at once, and so 5 branches, and I want to run the cumulative changes in eclipse to debug, then as far as I can tell I have to make a new branch and merge all the separate feature branches to it. Then if I make more changes to 3 of of the 5 feature branches, I must remember to merge all those into the "cumulative" branch again in order to have a cumulative working set of files with all the latest changes.

Compared to my workflow in RTC this seems VERY cumbersome.... Perhaps I am going about this all wrong though... or perhaps there is a feature that makes this a bit less of a manual process? (i.e. some command to select a bunch of branches and with a single action merge them all into a new (or selected) branch.... and/or have the cumulative branch somehow know that it's supposed to be synced/merged from the 5 feature branches and so I could just tell it to basically go fetch all those changes and merge in one command)

Does anyone have any advice? Should I be going about this a different way? Is there a command/set up I just need to know about?

Thanks!

Answer 1

I suggest not trying to use another tool's workflow with git, but learn how you can use git in its own way.

I often do what you say as well with git, and quite easily! It's true that in git, you can't prematurely mark some uncommitted change as belonging to different future commits. You can only do so (with git add) for one commit. But as it turns out, there is rarely any need to build multiple commits at the same time.

As a matter of fact, you don't need to separate your changes into uncommitted-commits (git's term is to stage the change) until the moment you actually want to commit them. At that point, you can happily use git add (especially with the extremely useful --patch option (-p for short)) to separate the changes into meaningful commits.

With RTC, you are assigning a set of files to each change set (and possibly move them around later), but while they are not "committed", you really just have a bunch of dirty files you are working with. With git, that's exactly what you do. You make a bunch of files dirty, and only at the time of commit decide what changes belong together.

As an example, here are two situations I often find myself in and how I deal with them:

Situation 1: Interrupted Work

• Work on feature A
• Realize you need to fix bug B

Given that you are still in the middle of feature A, you may want to fix B without A muddling the code. In that case:

$ git stash
# work on B, test it
$ git add <files>
$ git commit
$ git stash pop

Alternatively, you may want to fix B while A is half-working. In that case:

# work on B
$ git add -p    # select changes related to B to be committed
$ git commit
# continue working on A

Situation 2: Multiple Features

Normally, when working on multiple features, you use a branch for each. This lets you (1) commit work for each feature often, (2) have the commits of each feature together and (3) be able to send a pull request for each feature separately. You don't test multiple half-written features together.

However, on occasion you may actually be working on multiple simple things at the same time (each of which require just one commit), or even more often, you may be working on multiple changes for the sake of one feature, but you may want to separate them into multiple commits for clarity. In my case, I almost always have debug logs and such that I don't want to commit, so I want to separate the changes-to-be-committed from the debug logs.

In all these case, the solution is simple: git add --patch.

# work on multiple things
$ git add -p
$ git commit    # first logical change
$ git add -p
$ git commit    # second logical change
$ git add -p
$ git commit    # third logical change
# you are left with what shouldn't be committed yet

---

In summary, until you are actually ready to commit something, you don't need to separate changes into "change sets". More often than not, you may find yourself touching the same file for multiple reasons, so you couldn't have really put that in any specific change set anyway. Imagine if feature A touches files X and Y, and feature B touches files Y and Z. What do you do with Y in RTC?

So with git, what you do is to extract what needs to be committed (with git add --patch, you can take specific changes from a file, possibly committing only parts of it) at the time you want to make that commit.

As always with git, commit often and make each commit as simple as possible (each commit should mark one coherent change). This would prevent you from going insane trying to separate 20 features coded over 1 month without committing anything.

Answer 2

Yes, the way you deal with on git is correct. But it’s not cumbersome after you adapt to git’s behavior—it just makes every change traceable.

If you make more changes to 3 of 5 feature branches, so you need to merge them into cumulative branch. There have some graphical stuffs that you will find which branches need to merge obviously, any one of below works:

gitk --all

git log --oneline --decorate --graph --all