0

... or do they only manage full "commits"? (by full commits, I mean to say only the working/final files for a given snapshot.)

I am needing to learn some kind of VCS as I venture into application frameworks (such as Druapl). Since I'm not CS-grad, my idea of VC was someone telling me to update this page or fix that bug :) As my projects become more complicated I need to track program updates as well as my own customizations. Since Druapl uses GIT, it would be great if I could use only one system.

At the end of the day I may have several different versions of one page which I need to test (various browsers or some other bug or issue) but only one version will pass to be added to the working project snapshot.

Is there a command or workflow in git to manage this situation?

2 Answers 2

1

Git tracks the changes for each file in a commit. For instance, this is a rather small diff for a recent commit to the Kate editor. In fact, git typically only stores the changes to each file internally and uses that to build complete files in your working directory.

If you need to track only small incremental changes, just commit for every little change you want to be tracked. Since git doesn't have to talk to a server to commit, it's quick and easy. Many editors and IDEs come with git integration so it may even just require you to push a button. Git's index also permits you to only check in the files you want, so you can split up your commits by file if you'd like.

Git's powerful branching will take care of your other need. To create and switch to a new branch just for your work just run git checkout -b work. You can branch off that or the original master branch as many times as you need. Since git only stores the incremental changes, branches are cheap and easy. Once you have something that's ready to go, merge it back in to your primary working branch. You can even track little changes in one branch, and merge it into another as one big commit, so you can keep track of little changes when you need to but not have a ridiculously long history in your primary working branch.

Another feature of git that might be useful to you is cherry picking. This allows you to select specific commits from one branch and merge them into another branch. So if you did some work in one branch that you need in another, but don't need it all, bringing it over is easy.

I strongly recommend spending some time learning about all the various features of git so you'll be able to use them easily when you need to. Our friends over at Stack Overflow have compiled a list of excellent resources.

1
  • Those are excellent examples and your explanation is very readable.
    – xtian
    Aug 14, 2011 at 16:07
0

Git, Mercurial, and all other distributed version control systems I am aware of track at the commit level. You do not commit individual files, but rather the state of the entire working copy at a point in time, and you choose explicitly when to perform this commit.

If you are tracking sets of unrelated changes with Git, one workflow to make this easy would be to use one branch per change. You would have the following branches:

  • master (pulled from origin)
  • xtian-master (your "master" branch)
  • Additional branches per feature

As Drupal updates their master branch, you would pull the changes then merge them into your xtian-master branch. This way your final changes would be applied onto newer versions of Drupal.

As you want to change a page, you would create a branch for that change, make as many changes and commits on that branch that you want, then either merge into xtian-master or delete the branch (if you decide to scrap your changes). You can have multiple branches as you're working on the new feature, then finally merge the winning branch into xtian-master.

2
  • Let me see if I understand. I've read GIT rewrites the files in the repository to match the currently selected "head". Without GIT, if I want to have three versions of the same file, I make three differently named files. Using GIT, I would develop a workflow of alternatively, 1) creating a new branch, 2) checking out the file, 3) making changes, 4) commit the changes, 5) repeat for each alternate file. When I need to test any given version, I'm switching the head and opening the same file in the repository?
    – xtian
    Aug 14, 2011 at 16:11
  • Correct. If you have "testA" and "testB" branches, you can make different changes and commit in each branch. When you checkout each branch, you will get the changes made in that branch only. When you decide one of them is ready, you merge it back into your master branch. Aug 14, 2011 at 20:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .