1

I thought you had to use fetch to get the latest version of a branch from the remote repository. If you do this as the person who wrote the article, don't you create a new feature branch from the "develop" branch that you had stored locally, in other words from a possibly outdated branch?

I have the same question for when he merges his local feature branch to the "develop" branch and pushes it back. He uses checkout here, why not fetch?

link to the article: https://nvie.com/posts/a-successful-git-branching-model/

enter image description here

Jens
  • 141
  • 10
  • 1
    That is correct. If the person is not fetching, then they are working on a possibly outdated branch. Do they work by themselves? They know that `develop` has not received updates? The person is the **keeper** of develop branch? Those are all possibilities to consider. – eftshift0 Dec 01 '22 at 10:14
  • 1
    _"don't you create a new feature branch from the "develop" branch that you had stored locally, in other words from a possibly outdated branch?"_ - yes. To keep things simple, the article assumes you start up-to-date. But also checkout and fetch are two different things, you can just replace checkout with fetch in those commands. – jonrsharpe Dec 01 '22 at 10:14
  • You mean "why don't they run fetch _before_ checkout", right? Not fetch instead of checkout? – Useless Dec 01 '22 at 10:29
  • Ah, yes of course first you fetch and then checkout. (Right?) – Jens Dec 01 '22 at 10:30
  • @jonrsharpe *checkout and fetch are two different things, you can just replace checkout with fetch* did you mean to write *cannot* instead of *can*? It would make a lot more sense. – j6t Dec 01 '22 at 10:32
  • I would raise the point of `why do they use a local copy of a shared remote branch in the first place?` but that is waaaay out of the scope of the question :-D – eftshift0 Dec 01 '22 at 10:33
  • Working on possibly outdated branch is a usual thing. Moreover, if project is being actively developed then "develop" branch will almost guaranteed to become outdated at some point of time. So you need to be prepared to deal with it in the future by rebasing your branch or merging new changes from parent. @eftshift0 Well, using local copy of a shared remote branch is the essence of git, isn't it? – user7860670 Dec 01 '22 at 10:33
  • @user7860670, "Working on possibly outdated branch is a usual thing." I understand, but you still need to fetch before you checkout right? Otherwise it seems like you would always be starting from the develop branch node someone made 3 years ago. – Jens Dec 01 '22 at 10:41
  • @j6t yes, should have been can't/cannot. – jonrsharpe Dec 01 '22 at 10:47
  • 1
    If you haven't touched this repo for 3 years then yes, it would certainly be a great idea to fetch all the new stuff prior to starting working. But if you just clonned the repo or use it often then performing a mandatory fetch prior to starting a new branch does not make much sense. If repo is very active then your local copy of the branch may become outdated after you fetched the changes but prior to creation of new local branch. So it really depends on the pace. – user7860670 Dec 01 '22 at 10:57

3 Answers3

1

You are mixing commands meaning. Check git docs.

git-fetch - Download objects and refs from another repository

And article's author creates branch.

git-checkout - Switch branches or restore working tree files

git checkout -b|-B [] Specifying -b causes a new branch to be created as if git-branch1 were called and then checked out.

But also, if you suggest that before creating branch author had to have the latest branch - git-fetch is not enough. It just downloads changes, but you need to integrate those changes into your branch. So then you have to use git-pull which fetches, and integrates changes to the branch.

git-pull - Fetch from and integrate with another repository or a local branch

kosist
  • 2,868
  • 2
  • 17
  • 30
  • This is great thanks! I was indeed mixing things up. This page made for a great refresher of commands as well. (posting it for anyone who might have some use in it as well) https://learn.microsoft.com/en-us/azure/devops/repos/git/gitquickstart?view=azure-devops&tabs=visual-studio-2022 – Jens Dec 01 '22 at 12:15
0

You're right that the local name could be outdated. Note, however, that there is a race here, no matter how clever you are with "grab the latest from some other repository, then use the latest we grabbed" because some time elapses between "grab" and "use". No matter how small you make that interval, someone else could sneak in between those two moments.1

In the end, then, the attempt to be "up to date" is simply a best effort at avoiding major issues. That's still a good idea, of course.

While kosist's answer is fine, you need not actually use git pull, which just runs git fetch followed by a second command (generally git merge or git rebase). You can do the equivalent manually, and that's what I usually prefer for personal reasons. Now that git pull has a built in "merge-with---ff-only" option, I might eventually start using git pull more, but several decades worth of habits can be hard to break.

One other note applies here: since Git 2.23 came out, I recommend using git switch rather than git checkout for the purpose of changing or creating branch names like this. Switching to git switch is equally hard in terms of habit-breaking but I find it has been pretty valuable. The checkout command is too all-in-one, bundling most of git restore into itself as well, and it's too easy to accidentally invoke the wrong behavior (via a simple typo).

1Assuming, that is, that either there's no smallest unit of time in the universe, or that in terms of this fundamental "graininess" of time, the elapsed time between "grab" and "use" is greater than one "grain". However, we don't really need that kind of assumption since in practice, the work happens on human timescales (many seconds, minutes, hours, etc.) while the computers operate in nanosecond timescales, so there are always multiple billions of "computer grains".

torek
  • 448,244
  • 59
  • 642
  • 775
0

I would not recommend this 12 years old "successful Git branching model", but rather gitworkflow, which merges feature branches first to dev, then to main (instead of merging dev itself to main).

In that workflow, I would first

  • refresh the target branch with a simple git pull, making sure to set first:
git config --global pull.rebase true
git config --global rebase.autoStash true

That way, if any local commits were done directly on dev, a git switch dev + git pull would rebase said local commits on top of the refreshed (fetched) origin/dev.

  • Then I would rebase my feature branch on top of the target branch, making sure to compile/test the result (in the context of the rebased feature branch)
git switch feature
git rebase dev
# resolve conflicts, test
# assuming I am the only one working on feature:
git push --force
  • Then I can merge feature to dev (trivial, since all feature commits were rebased on top of dev)
git switch dev
git merge feature
git push

Or, make a pull request from feature to dev, using the remote repository hosting service (GitHub/GitLab, ...), which allows for a final code review before a trivial merge.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250