git - How Frequent Should I Get Latest Changes

Question

As a git novice, I understand basics but one thing that I feel uneasy is if my change takes days to complete.

I would start off by creating a new branch branch-A and work on it but I hear I should get latest code changes from remote on a daily basis, at least once a day to reduce chance of conflicts.

1. How often should I get the changes from remote into my branch-A while I am actually on that local branch still doing coding?
2. And if I am on my own local branch-A doing coding for days, should I do daily fetch/merge to brach-A or to my local master?

UPDATE

I guess I am not clear about what I need clarified.

Assume I use feature branch

Assume medium team size and regardless if we all work in "same" area or not, help me understand what is safe best practice.

Having said that, I do this as this is what I know (not sure what rebase is, as I said I am novice but will read, OK):

Get latest change and merge into develop

git fetch origin
git merge origin/develop

Create new branch from freshly updated develop branch

git checkout -b branch-A

Work and do staging and committing today

git add.
git commit -m "my message"

Next day, I want to make sure I get all changes from remote to reduce chance of conflicts. So, I want to do fetch/merge again but note I am on my branch-A currently

How do I do this? Do I do it like this

git fetch origin
git merge origin/branch-A

or like this

git fetch origin
git merge origin/develop

Answer 1

That question depends entirely on how many people are concurrently working on that same piece of code. If you're working a new feature (i.e., new files), then go at it for a month and merge up without ever merging down - you won't conflict anyway. If you have three coders all trying to fix two dozen different bugs in the same file, then merge down every 30 min.

Don't be anxious or "uneasy" about it. I don't see three consecutive merge conflicts as being any easier than one merge conflict three times as large. In many cases, consecutive merge conflicts end up just changing the same things over and over again and you'd waste more time merging down every day if there a bunch of trivial conflicts on the same couple for loops each day.

I definitely suggest a daily master pull. It gives you a nice visual of all of the changes that have been made, and if you see a storm of +/-'s on files you're working on, then you better merge down since it's probably a refactor. If it's a small amount of changes on your files, just leave it alone.

Answer 2

Regarding 1 - its kind of your decision + practices that work best for your team, taking into consideration the amount of people doing changes into the project concurrently and how many people are supposed to work "in the same area" that you do.

As a rule of thumb, the less you sync with the main development branch, the more the chance of conflicts that you'll have to resolve.

I can say that I do a rebase from main development branch nearly once a day, sometimes more often, but it again depends on things that I've explained above.

Technically if the branch is created out of 'master' (which is a main development branch) like this:

git checkout -b my_branch

And then you do commits:

git commit -am "some commit"
git commit -am "another commit"

Then it worth nothing to do the following:

git fetch --all
git rebase origin/master

In this case, your commits will be "last" in history (although their sha1 will change, which is not an issue since it's only your branch) and your branch will also contain latest changes from master.

Regarding 2

If you're alone / work in a very small team - then probably you can always commit directly into master and do not use branches at all, although this is not a recommended way of using git.

I can say for myself that I use a feature branch for a single feature, usually, it "lives" for 1-3 days. And then I merge it back to master via a pull-request mechanism - I open a pull request, my team members review and approve my changes and then I merge back.

This way of work has a lot of advantages, but it's beyond basic "bare" commands provided by git and is more about good practices of working in projects using git - an extremely versatile and flexible tool. So I suggest you read about pull requests and see whether you can adopt them in your team

Answer 3

Answer

Assuming you are currently on branch-A:

Easy to understand

git commit -am "Make sure you save your pending changes" git checkout develop git pull # Or fetch merge like usual into develop git checkout branch-A # git merge origin/branch-A here if other people might also be working on branch-A. # It'll let you know that it's "Out of date" if other people changed branch-A git merge develop

This is the most clear way to update your branch.

Easy to type

This only works if you haven't changed your local develop and fetch merge is a simple Fast-Forward. It'll let you know if you can't Fast-Forward.

git commit -am "Make sure you save your pending changes" git fetch origin develop:develop # Updates your local develop # git fetch origin branch-A:branch-A # If others will be working on your branch. git merge develop

Note that if you forget the git fetch origin branch-A:branch-A here, it won't let you know that you're out of date, since git fetch origin develop will only fetch develop.

Given suggestions

Suggestion 1

git fetch origin git merge origin/branch-A

This, doesn't actually do anything. origin/branch-A is likely identical to your local branch-A. If other people are also working on branch-A, you took in their updates, which is cool. But you never touched develop.

Suggestion 2

git fetch origin # Make sure to git merge origin/branch-A here if other people are touching branch-A git merge origin/develop

This will update your branch-A just fine, by using origin/develop. origin/develop will likely have been changed in your absence, so this will update your branch.

However! This is confusing, because your local develop is still out of date! You can just let it be, and then next time you checkout develop it'll let you know "Out of date", at which point you can git merge origin/develop into develop as well.

However, you might checkout another branch, and then git merge develop, thinking "Yeah I just updated". But you didn't, the local develop was out of sync. That's why this is a bad practice.