4

We use Git for version control. I am working on a big project which might drastically change the current codebase. The general idea is to breakdown the project into smaller pieces, and commit them to Git locally. So it's easier to trace what's updated by small pieces.

However, the problem I have is some of the fundamental elements are not finalized yet, it's may change due to the integration with legacy system. One the fundamental element changes (e.g. the API interface, naming), all the dependancies need to be changed too. This makes me not able to commit any code. Since the checked-in commits might need to change again due to the fundamental element changes. So I am keeping everything uncommitted, and will commit them piece by piece once the fundamental element is really finalized.

I don't feel this is a good practice. I would like to commit the small pieces along when I'm done with modifying each piece. Not wait until the big project is almost completed, and commit at that time. How should I improve the development process?

Stan
  • 37,207
  • 50
  • 124
  • 185
  • If you change the API, you need to change all the code using that API, and that is sometimes a large change... – Basile Starynkevitch Aug 05 '15 at 08:08
  • 2
    Why can't you just create a separate branch? – Nadine Aug 05 '15 at 08:09
  • 2
    You may be interested in this : http://nvie.com/posts/a-successful-git-branching-model/ ; and rebase is your friend. :) – Mathias Dolidon Aug 05 '15 at 08:14
  • @MathiasDolidon, you got the point! Rebase seems to be a great idea. I can make 1st, 2nd, 3rd commits. Whenever I need to go back to make change to 1st commit, then rebase 2nd, 3rd commits. Same as mentioned in this SO: http://stackoverflow.com/questions/1186535/how-to-modify-a-specified-commit-in-git – Stan Aug 05 '15 at 09:15
  • 1
    @Stan If you've decided to use rebase instead of merge, I would recommend you read the paragraphs under "The Golden Rule of Rebasing" in this article: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview You can really mess things up with rebase if you aren't careful – Nadine Aug 05 '15 at 12:30

1 Answers1

3

I recommend creating a new branch for your work. You can follow these steps. 

git branch

The above command will give you a list of your current branches, similar to this:

production
* master  
testing

The one with a star next to it is the current branch you are using. Make note of it.

Now create a new branch (here I called it "development", you can name it anything):

git branch development
git checkout development

Anything you commit or push from now on will go onto the branch called development. On a regular basis, you should do this command to make sure you stay in sync with the branch everyone else is using (replace master with the name you wrote down before):

git merge master

When you are done with everything, and want to add your code to the shared branch, do this:

git checkout master
git merge development

Now you are on the original branch again and it contains all the new code. You may get merge conflicts that you will need to resolve at this point. Alternatively, you can all continue to use the development branch forever instead of merging back to master.

Nadine
  • 1,620
  • 2
  • 15
  • 27
  • I am more like asking how to use rebase to clean up my local development branch. As some of the fundamental changes might need to rebase into earlier commits. – Stan Aug 06 '15 at 03:35