0

I am moving from SVN to GIT. Usually while deploying the package, the working directory is updated to a particular revision <= HEAD but always greater than the current revision of the working copy. so in SVN it is simple, just updating to a specific revision

Suppose current revision of working directory - 34500 and HEAD is at 34600, and packagae needs to be deployed for 34576. So, in SVN simply

svn update -r34576

and when a new package needs to be created for a higher revision, we simply move to a higher revision, like

svn update -r34589

Now, trying to do the same in GIT. Package needs to created from master. But not necessary uptil the HEAD. Is this what I am suposed to do:

git checkout 3ef0d...

or 

 git pull --rebase origin master
 git checkout 3ef0d...

And similarly when I want it for a higher commit id/revison

adnan kamili
  • 8,967
  • 7
  • 65
  • 125

2 Answers2

1

Sounds correct. You checkout to a version and then build your package from that. If you don't want artifcats, I can also recommend using the archive command to export the source tree as of commit 3ef0d and then building the package from there.

Noufal Ibrahim
  • 71,383
  • 13
  • 135
  • 169
  • Do I need to pull or is checkout enough. Is there any difference between two - checkout only and pull + checkout? – adnan kamili Nov 26 '14 at 06:35
  • Pull fetches from a remote repository. checkout checkouts from the local repository into your working copy. I get the feeling that your basic git understanding is not very strong. I'd recommend that you spend a while going through the git book before seriously using it. It's not exactly the most intuitive of applications. – Noufal Ibrahim Nov 26 '14 at 07:42
1

Let's say - hypothetically - that this is the output you get from git log --graph --oneline.

* de65bbf < HEAD
* 189ca83
* 40c918c
*   5497694
|\  
| * 5295fe4
* | 7879de1
|/  
* 61f5fcb

Let's say, hypothetically, that work in commit 5295fe4 was done on a separate branch, then merged into master. The resultant merge commit at 5497694 is what you want to release into production.

Once you pull down the repository with git pull, Git will include all of the work from that commit and a few others, which is to be expected - HEAD is a reference to the tip of your commit graph. I'd avoid the use of the rebase flag here if you can; rebasing is powerful, but if this is done on a branch where many people can see it, it could lead to some heartache.

If you really do know what you're doing with rebase, then more power to you. I'd recommend holding off until you feel fully comfortable with the nuances between Subversion and Git.

If you want to check out just that commit, then git checkout 5497694 will suffice. However, you're in a detached HEAD state - commits done here will create commit entries that aren't referenced by a branch, which makes it difficult to track. You can create a branch off of that commit and make changes to it there, of course.

If you want to formally declare this particular commit as releasable, then tagging it would be a better idea - run git tag version-number 5497694 instead, and that will create an easier reference to this specific commit.

Ultimately, though, you want to just pull down the changes with git pull. If your work depends on a specific check-in being present, git pull will sort you out.

As an aside, to answer an earlier question about pull vs checkout: pull will update your local branch(es) with the changes from the remote server; checkout is generally used for creating branches.

Makoto
  • 104,088
  • 27
  • 192
  • 230
  • Thanks for a detailed reply. I won't be committing in the master branch - only merging, so I suppose I don't need to do a git pull, simply git checkout will update my local repo to the required revison. If thats so, then how git checkout HEAD is different from git pull – adnan kamili Nov 26 '14 at 06:57
  • So now I've got a bit more info - you're trying to rebase your work on top of master. You shouldn't need to do anything at all, actually - when you're done with your work, merge it into master and deal with any conflicts that may arise. As for your confusion - I'd encourage you to read [Git SCM](http://www.git-scm.com), which has a treasure trove of documentation, and a free ebook on Git. – Makoto Nov 26 '14 at 07:05